Resposta direta: escolha uma empresa de RAG pela capacidade de provar uma cadeia de conhecimento confiável de ponta a ponta. Ela deve identificar fontes oficiais, manter conteúdo atualizado, preservar permissões, recuperar evidência relevante, medir respostas e operar falhas em produção. Uma demo que responde a cinco perguntas sobre um PDF não demonstra essa capacidade. Antes de contratar, exija um conjunto de perguntas reais, respostas esperadas, citações, testes de acesso, métricas, registros e um plano claro de atualização e suporte.
RAG, ou geração aumentada por recuperação, conecta um modelo de linguagem a informações externas. Isso pode tornar respostas mais úteis sobre políticas, produtos, contratos, atendimento e conhecimento interno. Mas RAG não transforma automaticamente documentos desorganizados em verdade. A qualidade depende de cada elo entre a fonte original e a resposta exibida. Por isso, a seleção do fornecedor deve começar pelo risco da decisão e pela governança do conhecimento, não pelo modelo ou pelo banco vetorial escolhido.
A Cadeia de Confiabilidade do Conhecimento MAKINAI
Use seis elos para comparar propostas: autoridade, atualização, permissão, recuperação, resposta e operação. A nota final não é uma média simples: o elo mais fraco limita o sistema. Para cada elo, peça evidência reproduzível no seu ambiente e aplique um teste de ruptura. Um fornecedor maduro mostra como o sistema falha com segurança quando uma fonte some, uma permissão muda, uma pergunta é ambígua ou um documento tenta manipular o modelo.
1. Autoridade: quem decide qual fonte vale?
Comece com um inventário de fontes e responsáveis. O fornecedor deve distinguir documento oficial, cópia, rascunho, mensagem, conteúdo externo e conhecimento informal. Peça regras para prioridade, vigência, jurisdição, idioma, duplicidade e conflito. O NIST recomenda documentar como sistemas generativos são adaptados, incluindo recuperação e origem dos dados. Sem essa linhagem, uma resposta pode soar segura enquanto combina versões incompatíveis de uma política.
- Evidências mínimas: catálogo de fontes; proprietário por domínio; versão e data de vigência; regra de conflito; campos obrigatórios de metadados; processo para aprovar ou retirar conteúdo. Teste de ruptura: insira duas políticas contraditórias e verifique se o sistema identifica a fonte vigente ou admite incerteza.
2. Atualização: quando o índice deixa de representar a realidade?
Pergunte como documentos entram, são transformados, divididos, indexados e removidos. A proposta deve informar frequência, latência, detecção de mudanças, tratamento de exclusão e reconciliação entre repositório e índice. Atualizar apenas adicionando novos arquivos cria conhecimento fantasma: trechos revogados continuam recuperáveis. Exija um indicador de frescor por fonte e um procedimento para atualização urgente.
O fornecedor também deve explicar o efeito de tabelas, imagens, anexos, planilhas e páginas digitalizadas. Uma pipeline que funciona com texto limpo pode perder condições, cabeçalhos ou notas críticas. Faça a prova com documentos representativos, não com uma amostra preparada pelo fornecedor.
3. Permissão: a resposta respeita quem fez a pergunta?
O controle de acesso precisa acompanhar o documento, o trecho recuperado e a resposta. Pergunte se permissões são aplicadas antes da recuperação, como grupos e identidades são sincronizados e como alterações são propagadas. Um filtro aplicado somente depois da busca pode expor títulos, trechos ou existência de documentos restritos. Inclua testes entre áreas, níveis hierárquicos, clientes e países.
- Evidências: modelo de identidade; herança de permissões; isolamento entre tenants; logs de consulta; política de retenção; teste de acesso negativo; procedimento para desligamento de usuário. Teste de ruptura: retire o acesso a um documento e meça quanto tempo leva até ele deixar de influenciar qualquer resposta.
4. Recuperação: o sistema encontra a evidência certa?
Microsoft descreve RAG como uma pipeline em que a pergunta passa por busca, montagem de contexto e geração. Cada etapa precisa ser avaliada. Peça métricas de recuperação como cobertura de documentos relevantes e precisão dos trechos retornados, segmentadas por tema, idioma e tipo de consulta. Compare busca lexical, vetorial e híbrida quando fizer sentido. Não aceite uma única taxa agregada que esconda áreas fracas.
O fornecedor deve testar siglas, nomes parecidos, perguntas longas, datas, negações, tabelas, consultas multilíngues e perguntas sem resposta. Se houver RAG agêntico, avalie também seleção de ferramentas, quantidade de chamadas, latência e limites de autonomia. Complexidade adicional só é justificável quando melhora uma tarefa medida.
5. Resposta: a conclusão está sustentada e sabe parar?
Avalie correção, relevância, completude, uso do contexto e groundedness, dimensões destacadas pela orientação de avaliação da Microsoft. Cada afirmação importante deve apontar para uma citação que o usuário autorizado consiga abrir. Defina quando o sistema deve responder, pedir esclarecimento, apresentar alternativas ou recusar. Uma taxa alta de respostas pode ser pior do que uma recusa calibrada em contextos jurídicos, financeiros, clínicos ou operacionais.
Monte um dataset de avaliação com perguntas reais, respostas esperadas, fontes aceitas, perguntas impossíveis e casos adversariais. Separe um conjunto que o fornecedor não usa durante o desenvolvimento. Registre modelo, prompt, índice e configuração em cada execução, porque respostas são não determinísticas e mudanças pequenas podem alterar resultados.
6. Operação: quem detecta degradação depois do lançamento?
A arquitetura de referência do Google Cloud mostra que uma aplicação RAG de produção envolve ingestão, armazenamento, recuperação, modelo e infraestrutura. Na prática, alguém precisa monitorar cada parte: atraso de atualização, falha de conector, queda de qualidade, custo, latência, acesso indevido e mudança de comportamento do modelo. Exija dashboards, alertas, responsáveis, severidades, SLAs, rollback e cadência de reavaliação.
Segurança também precisa chegar aos documentos recuperados. A OWASP descreve prompt injection indireta quando conteúdo malicioso em um repositório influencia a saída do modelo. O fornecedor deve tratar fontes como dados não confiáveis, separar instruções de conteúdo, limitar ferramentas, filtrar entradas e saídas e testar documentos adversariais. RAG reduz alguns erros factuais, mas cria uma superfície de ataque própria.
Como pontuar fornecedores: seis notas e um teste de ruptura
Atribua de zero a quatro pontos por elo: zero, ausente; um, promessa; dois, processo descrito; três, evidência em piloto; quatro, capacidade reproduzível em produção. Exija no mínimo três em Autoridade, Permissão, Resposta e Operação. Depois aplique um teste de ruptura por elo. Não compense uma permissão fraca com boa interface nem uma avaliação fraca com arquitetura sofisticada. A proposta vencedora deve reduzir risco verificável e não apenas acelerar a primeira demonstração.
Como estruturar um piloto que ajude a decidir
Escolha um domínio com fontes identificáveis, responsáveis disponíveis e valor observável. Prepare cinquenta a cem perguntas representativas, incluindo casos sem resposta e de acesso restrito. Defina critérios antes de executar: qualidade de recuperação, sustentação por fonte, recusa, latência, custo e tempo de atualização. Rode com usuários reais, documente falhas e estime o esforço operacional. O piloto termina com uma decisão sobre escopo, controles, custo e propriedade — não com um vídeo de demonstração.
- Entregáveis mínimos: inventário de conhecimento; arquitetura; mapa de identidade; pipeline de atualização; dataset de avaliação; relatório por segmento; registro de riscos; modelo de suporte; custos unitários; documentação e plano de transferência.
Sinais de alerta e próximo passo
- O fornecedor começa pelo modelo e não pelas fontes; promete eliminar alucinações; não testa perguntas sem resposta; permissões são deixadas para depois; citações não abrem a fonte; não existe dataset de avaliação; o índice não remove conteúdo revogado; segurança cobre apenas login; custos são estimados sem volume; operação depende de trabalho manual não declarado.
Use esta cadeia para comparar propostas e combine-a com o scorecard geral em https://makinai.co/insights/pt/como-escolher-empresa-implementar-ia-brasil-scorecard-30-pontos. Para formalizar requisitos, consulte https://makinai.co/insights/pt/como-criar-rfp-servicos-ia. Se o desafio exige organizar dados, conteúdo e inteligência em um sistema operável, conheça https://makinai.co/services/pt/dados-conteudo-inteligencia-artificial.