Ganhos:
- Projetando os componentes e o fluxo de dados de um assistente RAG empresarial de ponta a ponta
- Combinando dados de múltiplas fontes (wiki, ticket, PDF, banco de dados) em um único assistente
- Tome decisões arquitetônicas para escalabilidade, cache e latência
Nas unidades anteriores, aprendemos as partes uma por uma: incorporação, banco de dados vetorial, fragmentação, recuperação. Agora vamos combiná-los e construir uma arquitetura ponta a ponta de um assistente que se comunica com os dados da sua própria empresa. O objetivo é fazer com que um funcionário pergunte: “Qual é a nossa política de licenças?” Um sistema onde as pessoas podem fazer perguntas, as respostas são baseadas em documentos internos reais, citações e combinam múltiplas fontes de dados. Esta unidade processa toda a arquitetura, fluxo de dados e decisões em nível de produção.
Componentes ponta a ponta
Um assistente RAG corporativo consiste em duas linhas separadas. A linha de indexação (offline) prepara os dados; A linha de consulta (online) responde à pergunta.
Componentes da linha de indexação:
- Conectores: Conectores que extraem dados de fontes — wiki, sistema de tickets, armazenamento de arquivos, banco de dados, email.
- Normalização: Convertendo diferentes formatos (PDF, HTML, DOCX) em texto limpo; limpeza de cabeçalho/rodapé.
- Chunking + metadados: Chunking e marcação (fonte, data, autoridade).
- Incorporação + carregamento: Gravação de vetores e metadados no banco de dados de vetores.
Componentes do pipeline de consulta:
- Pré-processamento de consultas: Reescrita, descentralização.
- Recuperação: Pesquisa híbrida + filtro de metadados + reclassificação.
- Criação de prompt: Colocação de contexto + pergunta + instruções no modelo.
- Geração: Resposta fundamentada (contextual) do modelo + fontes.
- Pós-processamento: formatação de citações, verificação de segurança, registro.
Dica: Separe fisicamente a linha de indexação da linha de consulta. A indexação é lenta e periódica (é executada em lotes durante a noite); A linha de investigação deve ser leve e imediata. A mistura das duas linhas força um processamento pesado enquanto o usuário espera.
Visualizando Fluxo de Dados
[INDEXAÇÃO - offline]Recursos → Normalizar → Pedaço+Metadados → Incorporar → Banco de dados vetorial (wiki, ticket, PDF, DB)[QUERY - online]Pergunta do usuário → Pré-processamento → Recuperação (híbrido+filtro+reclassificação) → Prompt (contexto+pergunta+instrução) → Modelo → Resposta+Fonte → Usuário
Combinando dados de múltiplas fontes
Nas empresas reais, a resposta não para no mesmo lugar. “Como emitir um reembolso para um cliente?” A resposta à pergunta pode ser encontrada tanto no artigo de ajuda (procedimento), no histórico do ticket (exemplos reais) quanto no PDF da política (regras). O assistente deve pesquisar todos eles em um pool.
Ponto crítico: ao combinar recursos em um único armazenamento de vetores, cada shard deve conter os metadados `source_tour`. Assim você pode pesquisar todos e filtrá-los se necessário, como “trazer apenas políticas oficiais”. Além disso, diferentes fontes têm diferentes níveis de confiabilidade: política oficial > artigo de ajuda > nota de ticket de um funcionário. Você pode especificar essa prioridade na reclassificação ou no prompt.
Fonte
Tipo de conteúdo
confiança
Frequência de atualização
PDF da política
regra oficial
alto
mensalmente
Artigo de ajuda
Procedimento
médio-alto
semanalmente
Histórico de ingressos
amostra real
médio
Contínuo
wiki
Nota mista/atual
Variável
Contínuo
Escalabilidade, cache e latência
Três questões se destacam na produção. Latência: A experiência piora quando o usuário espera mais de 2 segundos. Solução: exiba a resposta em formato de streaming – ela é exibida na tela enquanto o modelo escreve. Cache: Para perguntas frequentes e contextos repetitivos, o cache aumenta a velocidade e reduz custos. Escala: À medida que o usuário aumenta, é necessário poder escalar a recuperação e modelar chamadas horizontalmente.
Regra geral do lado dos custos: a etapa mais cara geralmente é o número de tokens que vão para o modelo maior. Portanto, reduzir o contexto para 4 partes boas através da reclassificação melhora a qualidade e o custo. Um design comum é usar um modelo menor/mais rápido para classificação ou roteamento simples e um modelo mais poderoso para a resposta final (por exemplo, claude-opus-4-8).
Cuidado: Não configure a indexação como “faça uma vez, esqueça”. Os documentos são alterados, excluídos, adicionados. Estabeleça uma estratégia de reindexação: detecte documentos alterados e reprocesse apenas eles. O índice obsoleto produz uma resposta que parece atual, mas está errada.
Arquitetura Fraca/Arquitetura Forte
Fraco (script único, tudo misturado):
Quando o usuário perguntar: leia os documentos naquele momento, fragmente-os, incorpore-os, pesquise-os, responda-os.# Problema: toda a indexação é repetida para cada questão; segundos de atraso, # sem separação de fonte, sem filtro, sem atualização.
Poderoso (pipes divididos + metadados + cache + streaming):
Indexação: execução em lote à noite, atualizando documentos alterados. Consulta: linha leve - pré-processamento → recuperação híbrida + filtro → reclassificação → prompt → modelo (streaming) → citação → log. As perguntas frequentes e a fonte são armazenadas em cache.
Três Mini Estojos
Caso 1 — Linha confusa, grande atraso. Uma startup escreveu um script que reprocessa PDFs com cada pergunta; Cada resposta levou em média 11 segundos. Quando a linha de indexação foi separada e os dados foram previamente transferidos para o armazenamento vetorial, o tempo de consulta diminuiu para 1,3 segundos e com o streaming a “primeira palavra” apareceu em 400 ms.
Caso 2 — Muitos recursos, prioridade errada. Um assistente de suporte deu peso igual ao PDF da política e às notas de tickets antigos; O modelo às vezes apresentava a avaliação incorreta de um funcionário de dois anos atrás como regra oficial. Quando os metadados source_tour e a instrução "considerar a política oficial em caso de conflito" foram adicionados ao prompt, os erros de falsa prioridade foram reduzidos em 89%.
Caso 3 — Índice obsoleto. Um assistente de RH trabalhava com um índice que não era atualizado há 3 meses; A política de licenças mudou, mas o assistente estava falando dos velhos tempos. Quando foi instalada a atualização diária, que detecta arquivos alterados, a taxa de resposta atual aumentou de 70% para 99%.
Erros comuns
- Misturando linhas de indexação e de consulta: O processamento pesado é feito enquanto o usuário espera; o atraso explode.
- Não colocar o tipo de origem nos metadados: Sem priorização e filtragem; A fonte não confiável parece ser oficial.
- Não estabelecer uma estratégia de atualização: o índice fica obsoleto; São produzidas respostas erradas que parecem atuais.
- Ignorar streaming: usuário olha para uma tela em branco; O atraso percebido torna-se alto.
- Usando o maior modelo em cada etapa: O custo aumenta desnecessariamente; Deixe a direção para o modelo menor.
Em resumo
- O assistente RAG corporativo consiste em duas linhas distintas: indexação offline e consulta online; separá-los fisicamente.
- Indexação = conector + normalizar + bloco/metadados + incorporar/carregar; consulta = pré-processo + recuperação + prompt + geração + pós-processo.
- Os dados de múltiplas fontes são combinados em um único repositório, mas os metadados source_type e a prioridade de confiança são preservados.
- Streaming e cache para latência, otimização de contexto e seleção de modelo para custo são essenciais.
- Sem reindexação, o índice fica obsoleto; Reprocesse documentos alterados regularmente.
Tarefa de aplicativo
Desenhe um diagrama arquitetônico de um assistente para sua equipe. (1) Identifique pelo menos três fontes de dados reais e anote a necessidade do conector, a frequência de atualização e o nível de confiança para cada uma. (2) Desenhe as linhas de indexação e de consulta separadamente com um diagrama de caixa-seta. (3) “Onde posso reduzir a latência e o custo neste assistente?” Escreva pelo menos duas decisões concretas para a questão. (4) Descreva sua estratégia de atualização em uma frase: qual recurso será reindexado e com que frequência?
lista de verificação
- [] Posso desenhar as linhas de indexação e consulta separadamente e com os componentes corretos.
- [] Posso combinar dados de várias fontes com source_type e prioridade de confiança.
- [] Posso tomar decisões de streaming/cache para latência e seleção de modelo para custo.
- [ ] Eu sei porque uma estratégia de reindexação é essencial.
- [ ] Tenho em mente que a etapa mais cara da minha arquitetura geralmente é o token que vai para o modelo maior.