Relatório de campo · nossa própria execução
O reranker parecia uma melhoria. A evidência não conseguia dizer.
Rodamos o Oloproof contra um assistente de documentação com geração aumentada por recuperação, em produção e que não operamos: seu próprio recuperador e índice, geração real, um juiz LLM e o painel de referência de 58 perguntas dos seus responsáveis, sem alterações. Nenhum cliente está envolvido. Esta é a nossa execução, relatada como a auditamos.
- 58
- perguntas no painel de referência dos responsáveis
- 0 de 76
- comparações de feature flags resolvidas
- 1 em cada 9
- casos que mudam de veredito entre execuções idênticas
- 15 de 23
- respostas com falha recuperadas com o trecho correto
Com reranking contra sem reranking, 22 de setembro de 2026
| Métrica | Com reranking | Sem reranking | Diferença pareada, com menos sem |
|---|---|---|---|
| Página certa na posição 1 | 0.745 [0.519, 0.875] · 51 de 58 | 0.618 [0.449, 0.760] · 55 de 58 | +6.2 pontos [−36.3, +45.5] · 48 pareadas |
| Página certa entre as 3 primeiras | 0.742 [0.270, 0.939] · 31 de 58 | 0.683 [0.350, 0.875] · 41 de 58 | +3.7 pontos [−73.9, +76.2] · 27 pareadas |
| Resposta correta (juiz LLM) | 0.760 [0.519, 0.888] · 50 de 58 | 0.685 [0.501, 0.819] · 54 de 58 | +6.5 pontos [−39.4, +48.4] · 46 pareadas |
Antes
O assistente já tinha um bom harness de testes: um painel de referência, um juiz LLM e um gate de lançamento. O gate comparava uma estimativa pontual com uma meta, em qualquer tamanho de painel. Lido assim, o reranker acrescentava 12,7 pontos de página certa na posição 1 e teria sido lançado. E na pontuação de fidelidade que decidia os lançamentos, uma resposta que o juiz não conseguia avaliar contava como falha total.
Depois
O Oloproof pareou os dois braços nas perguntas que ambos tinham respondido, registrou 4 erros de servidor e 2 veredictos ilegíveis como ausentes e alargou cada intervalo para cobri-los. As três diferenças cruzam o zero, e com folga: este painel não consegue dizer se o reranker ajuda ou atrapalha.
Executar de novo as 23 respostas com falha usando o trecho correto no lugar do recuperado recuperou 15, ao lado de um controle que as executou de novo sem alterações. O diagnóstico rotulou 5 falhas de recuperação e 7 falhas de geração, deixou 11 sem resolução e apontou a profundidade de recuperação e a configuração do índice como os próximos experimentos.
Medido três vezes, cerca de um caso em cada nove mudou de veredito sem que nada mudasse, e 13,8% das chamadas retornaram um erro de servidor. Declarar esses erros como transitórios recuperou 18 de 22 casos ausentes e estreitou o intervalo em 39%. Uma varredura das dezenove feature flags do assistente deu então 76 comparações pareadas, nenhuma resolvida, e cerca de 40 perguntas a mais resolveriam as três mais promissoras.
“Uma suíte de 58 casos, em que um em cada nove responde diferente a cada vez que é perguntado, não tem quatro casas decimais de resolução.”
Em resumo
- Executado porOloproof, por iniciativa própria
- Sistema avaliadoUm assistente de documentação RAG em produção que não operamos
- Painel58 perguntas, as dos próprios responsáveis, sem alterações
- JuizUm juiz LLM, ainda não verificado contra rótulos humanos
- Executado em22 e 23 de setembro de 2026
- Execuções de acompanhamento19 feature flags; 24 conversas
O que ele não mostra
Um sistema, um corpus e um painel pequeno demais para resolver a própria pergunta. O juiz por trás de cada pontuação de resposta não foi validado contra pessoas, e o diagnóstico diz isso. O painel é de turno único: uma execução de acompanhamento com 24 conversas encontrou duas falhas reproduzíveis que painéis de turno único não conseguem produzir, entre elas um assistente negando o que tinha dito um turno antes. Não é um benchmark, e não é um cliente.