20 de agosto de 2026. Estou a testar se a VALESKA consegue encontrar a evidência de que uma pessoa realmente precisa, e não se consigo produzir uma demonstração de pesquisa atraente. A VALESKA é o sistema de documentos e memória organizacional que estou a construir. Antes de um assistente de IA responder a partir dessa memória, a recuperação tem de trazer o material certo. Uma resposta fluente não consegue reparar a evidência que nunca lhe chegou.
Ontem acrescentei um avaliador de recuperação. Hoje torno-o utilizável através de diferentes clientes e anoto 33 perguntas sobre a coleção documental da Guiana. Estabeleço os documentos esperados lendo a coleção, não aceitando o que a pesquisa devolve. Caso contrário, estaria a deixar o sistema escrever a sua própria chave de respostas. São resultados de investigação interna, não um certificado de aceitação por um cliente.
O que os números perguntam
A precisão em um pergunta se o primeiro resultado é relevante. A cobertura em vinte pergunta se a evidência esperada aparece nos primeiros vinte resultados. A média dos inversos das posições, ou MRR, recompensa encontrá-la mais acima e atribui zero a uma pesquisa falhada. A latência mede a espera. Para uma empresa que decide se um assistente é útil, estas medidas descrevem custos distintos: verificar o primeiro documento errado, percorrer uma lista, perder completamente a evidência e esperar.
Também corrijo o próprio avaliador. Tinha calculado a média dos inversos das posições apenas sobre consultas bem-sucedidas, pelo que recuperar uma resposta antes ausente numa posição baixa podia piorar a média. Agora inclui todas as perguntas anotadas. Os valores anteriores de MRR não são comparáveis. Preciso de uma aritmética correta antes de usar a pontuação para escolher uma alteração de engenharia.
Mais evidência, mais espera
A medição inicial encontra o primeiro resultado certo para 22 de 33 perguntas e a evidência esperada entre vinte resultados para 29 de 33. Alargar o conjunto de candidatos da pesquisa aproximada melhora este último valor para 32 de 33. A pontuação do primeiro resultado mantém-se em 22 de 33. O MRR passa de 0,727 para 0,741. A latência mediana sobe de 151 para 291 milissegundos; o percentil 95 sobe de 186 para 546 milissegundos. É uma melhoria de cobertura com um custo de espera, não uma vitória em todas as frentes.
Esta manhã a alteração já está aplicada, e tanto os testes diretos como os realizados através do serviço reproduzem 32 de 33. Resta uma pergunta sem resposta. A pesquisa ainda pode omitir evidência relevante em coleções pequenas. Um resultado vazio não demonstra, portanto, que a resposta não existe. A pesquisa mais ampla atenua este defeito; não resolve o problema de conceção subjacente.
Uma correção independente do relógio
O trabalho de ontem sobre o modelo de custos revela outra falha de medição, desta vez na classificação documental e não na recuperação. Os tempos anteriores de 345 e 397 segundos por documento estavam contaminados pelos meus próprios trabalhos em segundo plano, que competiam pelo processador gráfico. A medição limpa registada é de 8,2 segundos por documento, com uma primeira chamada muito mais lenta. O repositório regista a discrepância como aproximadamente 48 vezes. Isto elimina um erro de avaliação; não é uma aceleração do modelo acabada de conseguir.
Mantenho essa correção junto dos resultados de recuperação porque ambas afetam uma decisão empresarial. Uma cronometragem errada pode distorcer uma estimativa de capacidade; citar seletivamente uma pontuação de pesquisa pode esconder o trabalho de revisão que fica para os funcionários. Nenhuma das experiências estabelece o rendimento em produção, o desempenho com documentos de outra empresa ou o isolamento completo de permissões.
Do que preciso a seguir
Preciso de testar uma correção do problema de filtragem por coleção com as mesmas perguntas, mantendo no relatório as falhas e os valores de latência. Também preciso de tempos de classificação reproduzíveis que explicitem a disputa por recursos e os arranques a frio. A evidência de hoje basta para rejeitar um resumo lisonjeiro. Não basta para declarar a recuperação aceite.
Base histórica: commits da VALESKA fc2f77c, eaa00c1, 45c1449, 1643d91, 6607d62, 19-20 de agosto de 2026 (hora do Pacífico).