Quem já trabalhou com TOTVS Protheus conhece o problema: o dicionário de campos (a tabela SX3) tem milhares de entradas com nomes curtos e pouco intuitivos, tipo C7_ITEMCTA ou E2_VENCREA. A documentação oficial existe, mas está espalhada, e cada empresa customiza campos próprios por cima. Na prática, a forma mais comum de descobrir o que um campo significa é perguntar pra alguém mais experiente. Isso não escala. Resolvi tentar resolver isso com um assistente baseado em RAG (Retrieval-Augmented Generation) como projeto pessoal.
A ideia
RAG, resumindo, é buscar os trechos de texto mais relevantes pra uma pergunta e dar isso como contexto pra um modelo de linguagem responder, em vez de depender só do que o modelo "sabe" de treino. Montei um índice com três fontes:
- Extração da
SX3(nome do campo, descrição, tabela, tipo, tamanho) - Estrutura de relacionamento entre as tabelas mais usadas (SC7, SD1, SE1, SE2, SB2)
- Algumas anotações próprias de integração, tipo "esse campo só é preenchido quando a filial é X"
Cada campo virou um "documento" pequeno, com nome, tabela, descrição e observações. Gerei os embeddings e coloquei num índice vetorial simples.
O que funcionou bem
Perguntas diretas, do tipo "o que é o campo C7_ITEMCTA" ou "em qual tabela fica o vencimento de um título a pagar", tiveram respostas rápidas e corretas. Isso já economiza um bom tempo de ir atrás de alguém ou vasculhar documentação antiga. Também funcionou bem pra perguntas do tipo "quais campos eu preciso pra montar um relatório de X", desde que a resposta estivesse contida em um único "documento" indexado.
Onde o RAG simples não foi suficiente
O problema apareceu em perguntas que exigem juntar informação de mais de uma tabela, tipo "como eu ligo um pedido de compra ao centro de custo dele". A resposta certa depende de saber que SC7 se relaciona com CTT010 através do campo C7_CC, uma informação que não estava explícita em nenhum texto isolado, só implícita na estrutura relacional. RAG puro (busca por similaridade de texto) devolvia trechos soltos sobre cada tabela separadamente, sem conectar os pontos, e o modelo às vezes inventava uma relação plausível, mas errada.
RAG funciona bem quando a resposta cabe em um documento. Quando a resposta depende de raciocínio sobre estrutura (joins, hierarquia, regra condicional), busca por similaridade de texto não é suficiente, é preciso uma camada estruturada por cima (um grafo de relacionamento entre tabelas, por exemplo) que o modelo consulte antes de responder.
Próximo passo
A ideia que quero testar agora é dar ao assistente acesso de leitura direto ao schema do banco (introspection), em vez de depender só de documentação estática que fica desatualizada. Se funcionar, o assistente deixa de responder "o que sei sobre esse campo" pra responder "o que existe de fato nesse banco agora", o que resolve boa parte do problema de documentação defasada.