Krok mostra como construiu um assistente RAG interno para dados corporativos

A Krok contou como construiu um assistente RAG interno para trabalhar com conhecimento corporativo em ambiente fechado. Em vez de um "chat por chat", a empresa criou uma ferramenta que reduz o tempo gasto para encontrar os trechos certos em documentos, wikis e portais internos.

Por que escolheram RAG

A equipe partiu de um problema simples: a busca embutida existe, formalmente, em quase todos os grandes sistemas corporativos, mas isso não facilita a vida dos funcionários. A informação está espalhada por vários repositórios, cada um com suas próprias regras, estrutura e lógica de resultados. Com isso, as pessoas lembram do sentido de um documento, mas não da redação exata, do nome do arquivo ou de onde ele está. A busca comum se baseia na correspondência de palavras, e não no contexto, e é aí que ela começa a falhar.

O cenário direto com GPT e upload de documentos também foi testado, mas não funcionou para grandes volumes de dados. Várias limitações pesaram ao mesmo tempo: a janela de contexto, a instabilidade das respostas e o risco de levar documentos sensíveis para fora do perímetro da empresa. Por isso, a Krok escolheu a abordagem RAG: primeiro localizar trechos relevantes nas fontes internas e só depois enviá-los ao modelo de linguagem para montar a resposta.

"Não precisávamos de IA por modismo, e sim de um assistente

corporativo controlável."

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

• os documentos permanecem dentro da infraestrutura da empresa;
• o modelo recebe apenas o contexto necessário, e não todo o conjunto de dados;
• a indexação e a entrega de resultados podem ser controladas separadamente;
• o risco de alucinações é menor, porque a resposta se apoia em fontes reais.

Como o sistema foi estruturado

A solução se baseia em dois circuitos separados. O primeiro cuida da criação de assistentes: pelo mensageiro corporativo ou por uma interface web piloto, o usuário adiciona arquivos, links do portal ou espaços da base de conhecimento. Em seguida, o sistema de gerenciamento de assistentes verifica as permissões de acesso, aciona os parsers necessários, prepara os dados e só então os envia ao núcleo RAG para indexação. Quando o índice fica pronto, o funcionário recebe uma notificação e pode iniciar a conversa.

O segundo circuito é o de diálogo. A solicitação do usuário passa pelo barramento corporativo de trabalho com LLMs, e o mecanismo RAG seleciona antecipadamente o contexto relevante. As permissões são verificadas não uma única vez no upload, mas a cada acesso ao assistente. Por causa da complexidade das ACLs nos diferentes sistemas, em alguns cenários a equipe abandonou os assistentes compartilhados e passou aos pessoais. É menos conveniente, mas reduz o risco de um funcionário ver dados aos quais não tem direito.

Foi preciso ainda construir conectores e pré-processamento para quase todo tipo de fonte. O portal corporativo, a base de conhecimento, os arquivos pessoais e as páginas de wiki se mostraram diferentes demais para entregar tudo "de fábrica" a um único núcleo RAG. Por isso, a limpeza, a normalização e a preparação dos dados foram movidas para serviços separados.

Como principal ponto de entrada, escolheram um mensageiro interno baseado em Express: o Telegram parecia conveniente no início, mas, para informações sensíveis, um serviço externo foi descartado de imediato.

Onde surgiram os problemas

As dificuldades mais incômodas não estavam na interface, e sim nos dados e nos processos. Wikis com marcação complexa exigiram muita limpeza manual. Tabelas e dados numéricos geravam respostas instáveis. PDFs com imagens escaneadas e gráficos quebravam o parsing básico. O modelo entendia estruturas visuais, como organogramas, pior do que texto e podia confundir as relações entre departamentos e gestores. Além disso, os usuários esperavam do RAG uma busca completa por todas as ocorrências, embora a abordagem classifique o contexto mais provável em vez de garantir uma lista completa.

O trabalho com o fornecedor deu tanta dor de cabeça quanto. A Krok testou várias plataformas com seus próprios conjuntos de documentos e perguntas típicas, e depois passou quase um ano aprimorando a solução junto com o fornecedor. O problema foram as atualizações, que podiam mudar bruscamente a qualidade das respostas: uma das versões derrubou uma métrica de 85% para 70%. Como a ligação entre o RAG e o LLM embutido era opaca, a equipe pediu uma interface separada entre eles para escolher o modelo por conta própria e controlar o processamento posterior do contexto.

Para controlar a qualidade, foram criados benchmarks, perguntas de referência, verificações regulares e até um LLM separado, que atua como juiz e compara a resposta real com a esperada.

O que isso significa

O caso da Krok mostra que a IA corporativa hoje tem menos a ver com a escolha do modelo e mais com a engenharia em torno de dados, acessos e testes. O RAG sozinho não resolve o problema sem conectores, isolamento de coleções, controle de ACL e métricas de qualidade claras. Mas, se tudo isso for reunido em um só sistema, um assistente interno pode de fato eliminar horas de busca rotineira e deixar o trabalho com o conhecimento corporativo visivelmente mais rápido.