Projete um sistema de retrieval augmented generation sobre a nossa documentação interna. Quais são as peças móveis?

Ingira e fatie os documentos com divisão consciente da estrutura, gere embeddings dos chunks e indexe num vector store junto com metadados para filtragem. No momento da query, gere o embedding da pergunta, recupere candidatos, opcionalmente reordene com um cross encoder, e monte um prompt com as passagens recuperadas e citações. Avalie recuperação e geração separadamente, e mantenha o índice atualizado conforme os documentos mudam.

No offline, eu fatio por estrutura em vez de por contagem fixa de caracteres, para que títulos e seções fiquem inteiros, com um pouco de sobreposição para que uma frase que cruza uma fronteira não se perca. Cada chunk ganha um embedding mais metadados: fonte, seção, última modificação e grupo de acesso, porque permissões precisam ser aplicadas na recuperação, não pedindo educadamente ao modelo. Isso vai para um índice vetorial com um índice de palavra chave ao lado, já que busca híbrida bate consistentemente vetor puro em documentação interna cheia de códigos de erro e nomes de produto que embeddings tratam mal. No online, eu gero o embedding da query, puxo talvez cinquenta candidatos, reordeno com um cross encoder até cinco ou seis, e aí monto o prompt com essas passagens e instruções para citá las e para dizer claramente quando o contexto não cobre a pergunta. A parte em que eu insisto é a avaliação separada. Eu monto um conjunto de perguntas reais com os documentos fonte corretos conhecidos e meço recall em k só para a recuperação. Na maioria das vezes em que uma resposta está errada, a recuperação nunca trouxe o chunk certo, e nenhuma quantidade de trabalho no prompt conserta isso.