Krok mostrou como construiu um assistente RAG interno para dados corporativos

Croc explicou como construiu um assistente RAG interno para trabalhar com conhecimento corporativo em um circuito fechado. Em vez de um 'chat pelo chat', a empresa criou uma ferramenta que reduz o tempo gasto na busca de fragmentos relevantes em documentos, wikis e portais internos.

Por que escolheram RAG

O time começou com um problema simples: embora a busca integrada exista em praticamente todos os grandes sistemas corporativos, isso não facilita a vida dos funcionários. As informações estão espalhadas por vários repositórios, cada um com suas próprias regras, estrutura e lógica de retorno de resultados. Como resultado, as pessoas lembram do significado de um documento, mas esquecem a formulação exata, o nome do arquivo ou a localização. A busca padrão se baseia em correspondência de palavras em vez de contexto, e é aqui que começa a falhar.

Eles também testaram uma abordagem direta com GPT e upload de documentos, mas não funcionou para grandes conjuntos de dados. Várias limitações entraram em jogo: tamanho da janela de contexto, instabilidade de respostas e risco de expor documentos sensíveis fora da infraestrutura da empresa. Por isso, a Croc escolheu a abordagem RAG: primeiro encontre fragmentos relevantes de fontes internas e depois passe-os para um modelo de linguagem para montar a resposta.

"Precisávamos de uma ferramenta de IA que servisse a um propósito, não IA por ser tendência—um assistente corporativo gerenciado."

RAG foi escolhido neste projeto por quatro razões práticas:

• Os documentos permanecem dentro da infraestrutura da empresa;
• Apenas o contexto necessário é passado para o modelo, não o conjunto de dados inteiro;
• A indexação e recuperação podem ser controladas separadamente;
• O risco de alucinações é menor porque a resposta é baseada em fontes reais.

Como o sistema foi organizado

A solução é baseada em dois circuitos separados. O primeiro lida com a criação de assistentes: os usuários podem adicionar arquivos, links para portais ou espaços da base de conhecimento através do mensageiro corporativo ou de uma interface web piloto. O sistema de gerenciamento de assistentes verifica direitos de acesso, executa os analisadores necessários, prepara os dados e apenas então os envia para o núcleo RAG para indexação. Depois que o índice está pronto, o funcionário recebe uma notificação e pode começar um diálogo.

O segundo circuito é o circuito de diálogo. As solicitações do usuário passam pelo barramento LLM corporativo e o mecanismo RAG pré-seleciona o contexto relevante. Os direitos de acesso são verificados não apenas uma vez durante o carregamento, mas a cada consulta do assistente. Devido à complexidade das ACLs em diferentes sistemas, a equipe decidiu se afastar de assistentes compartilhados em alguns cenários e mudou para assistentes pessoais. Isso é menos conveniente, mas reduz o risco de um funcionário ver dados aos quais não deveria ter acesso.

Eles precisavam construir conectores e pré-processamento para praticamente cada tipo de fonte de dados. O portal corporativo, base de conhecimento, arquivos pessoais e páginas wiki eram muito diferentes para passar diretamente para um único núcleo RAG pronto para usar. Então eles extraíram limpeza de dados, normalização e preparação em serviços separados. Para o ponto de entrada principal, escolheram um mensageiro interno baseado em Express: o Telegram inicialmente parecia conveniente, mas usar um serviço externo para informações sensíveis foi imediatamente descartado.

Onde surgiram os problemas

Os desafios mais dolorosos vieram não da interface, mas dos dados e processos. Wikis com marcação complexa exigiam limpeza manual extensiva. Tabelas e dados numéricos produziam respostas instáveis. PDFs com digitalizações e gráficos quebravam o parsing básico. Estruturas visuais como organogramas eram entendidas pior pelo modelo do que texto e podia confundir relacionamentos entre departamentos e gerentes.

Além disso, os usuários esperavam que RAG fornecesse uma busca abrangente em todas as correspondências, embora a abordagem em si tenda a classificar o contexto mais provável em vez de garantir uma lista completa de ocorrências. A colaboração do fornecedor foi igualmente desafiadora. A Croc testou várias plataformas em seus próprios conjuntos de documentos e consultas típicas e gastou quase um ano refinando a solução com seu fornecedor. As atualizações se tornaram um problema—elas poderiam mudar drasticamente a qualidade da resposta: uma versão caiu a métrica de 85% para 70%.

Devido à complexidade das ACLs em diferentes sistemas, a equipe decidiu se afastar de assistentes compartilhados em alguns cenários. Devido à relação opaca entre RAG e o LLM incorporado, a equipe solicitou uma interface separada entre eles para que pudessem escolher independentemente o modelo e gerenciar o processamento de contexto posterior. Para controle de qualidade, introduziram benchmarks, questões de referência, verificações regulares e até um juiz LLM separado que compara as respostas reais com as esperadas.

O que isso significa

O caso da Croc ilustra bem que a IA corporativa hoje não se trata tanto de escolher um modelo, mas de engenharia em torno de dados, acesso e testes. RAG por si só não resolve o problema se não há conectores, isolamento de coleção, controle ACL e métricas de qualidade claras. Mas quando tudo isso é reunido em um sistema, um assistente interno pode realmente eliminar horas de busca rotineira e tornar o trabalho com conhecimento corporativo significativamente mais rápido.