RAG — Retrieval-Augmented Generation para Empresas
RAG (Retrieval-Augmented Generation) é a técnica que conecta um LLM a uma base de conhecimento própria: quando o usuário pergunta, o sistema busca os trechos mais relevantes em documentos internos e injeta esses trechos no prompt, para o modelo responder com base neles e citar a fonte. RAG é o padrão para copilots corporativos porque evita 'alucinação', mantém a resposta atualizada e não exige treinar o modelo. A Gomo Hub implementa RAG end-to-end: ingestão, chunking, embeddings, vector DB, reranking, prompt e observabilidade.
Resumo
- RAG = LLM + busca em base própria + injeção no prompt + citação.
- Reduz alucinação e mantém respostas atualizadas sem retreinar.
- Stack típico: embeddings + vector DB (Pinecone/Qdrant/Supabase pgvector) + reranker + LLM.
- Ideal para: base de conhecimento, contratos, manuais, catálogos, tickets.
Quando usar RAG (Retrieval-Augmented Generation)
- Precisa responder perguntas com base em documentos internos.
- Conteúdo muda com frequência (não vale fine-tuning).
- Requer citação de fonte para auditoria ou confiança do usuário.
- Volume de documentos muito grande para caber no contexto do modelo.
Benefícios
- Menos alucinação: Modelo responde com base em trechos reais recuperados.
- Atualização barata: Basta reingerir documentos, sem retreinar.
- Citação de fonte: Cada resposta aponta os trechos usados.
- Controle de acesso: Filtros por permissão no momento da busca.
Exemplo prático — Copilot interno sobre política de RH (exemplo ilustrativo)
Problema: Colaboradores enviavam centenas de dúvidas/mês para RH sobre benefícios e políticas.
Solução: Ingestão de PDFs de políticas, chunking, embeddings, vector DB. Copilot no Slack responde com citação do documento e página, com fallback para pessoa em casos complexos.
Stack: Supabase pgvector, OpenAI embeddings + GPT-4o-mini, Reranker Cohere
Resultado: Redução expressiva das dúvidas repetitivas encaminhadas ao RH e respostas em segundos com fonte rastreável.
Gomo Hub vs Fine-tuning do LLM com os documentos
| Critério | Gomo Hub | Fine-tuning do LLM com os documentos |
|---|---|---|
| Atualização de conteúdo | Reingestão simples | Retreino a cada mudança |
| Citação de fonte | Sim, nativa | Não |
| Custo | Baixo/médio | Alto |
| Controle de acesso por documento | Sim (filtro) | Impossível |
| Melhor para | Conhecimento factual | Estilo / formato |
Perguntas frequentes
Qual vector DB vocês usam?
Depende do caso: Supabase pgvector para stacks já em Postgres, Qdrant para volumes maiores self-hosted, Pinecone para managed. Redis quando latência é crítica.
RAG resolve alucinação 100%?
Reduz muito, mas não zera. Combinamos com prompts restritivos ('responda apenas com base nos trechos'), citação obrigatória e avaliação contínua.
Como fazer o chunking?
Depende do documento. Para contratos, chunk por cláusula. Para manuais, por seção com overlap. Sempre com metadados de origem.
Precisa de reranker?
Recomendado quando a base é grande e a precisão do top-k importa. Reranker melhora relevância antes de mandar para o LLM.