Eu construí um app de RAG, depois perguntei de qual carro eu gosto. Ele não sabia.

Estou construindo uma ferramenta de chat de documentos chamada Kenning. Ela utiliza RAG (Retrieval-Augmented Generation) para permitir que os usuários façam perguntas sobre arquivos enviados.

Construí todo o pipeline do zero usando:

  • Java 21 e Spring Boot
  • Spring AI
  • PostgreSQL com pgvector
  • Ollama (executando llama3.2:3b e nomic-embed-text)
  • Docker Compose

O pipeline funciona assim: Upload de arquivo → Extração de texto → Fragmentação de texto → Conversão de fragmentos em vetores → Armazenamento no pgvector → Busca por fragmentos similares → Envio de fragmentos + pergunta para o modelo → Obtenção da resposta com fontes.

O sistema funcionou, mas encontrei duas falhas diferentes. Elas pareciam iguais, mas as causas eram distintas.

Falha 1: O modelo estava confuso. Eu perguntei: "Qual modelo de embedding este projeto utiliza?" O documento declarava explicitamente a resposta. O modelo recuperou o texto correto. No entanto, ele respondeu dizendo que não sabia, mesmo repetindo o nome correto do modelo na frase seguinte.

Minha teoria: O modelo 3B é muito pequeno. Ele recuperou os dados corretos, mas não conseguiu se comprometer com uma resposta confiante. Um modelo maior provavelmente resolveria isso.

Falha 2: O modelo não encontrou nada. Eu perguntei: "De qual marca de carro eu gosto?" O documento mencionava que eu gosto de BMW. Mas o sistema retornou zero resultados. A pontuação de similaridade foi baixa demais para ultrapassar o meu limiar.

Minha teoria: Diluição de fragmentos (chunk dilution). Meu documento de teste era curto. Ele misturava muitos tópicos, como Spring AI, OAuth2 e minha preferência por carros, em um único fragmento. O vetor desse fragmento ficou diluído entre todos esses tópicos. Uma pergunta específica sobre carros perdeu força diante de um fragmento muito abrangente. Uma melhor estratégia de fragmentação (chunking) resolveria isso.

Lições aprendidas:

  • Modelos pequenos têm limites de raciocínio.
  • O chunking ingênuo afeta a precisão da recuperação.
  • Depurar o "porquê" é mais importante do que apenas corrigir o erro.

A arquitetura se sustenta. É lenta e às vezes errada, mas o ciclo está completo.

Fonte: https://dev.to/mido-dev/i-built-a-rag-app-then-asked-it-what-car-i-like-it-didnt-know-583n

Comunidade de aprendizado opcional: https://t.me/GyaanSetuAi