Como Estruturar uma Base de Conhecimento para IA de Voz
Estruture-a como blocos (chunks) recursivos de Markdown de 512 tokens, marcados com metadados de produto, região e público, recuperados a um limiar de similaridade de 0,65 ou mais, com uma instrução de recusa explícita. Este é o padrão de quatro camadas (curadoria, divisão em blocos, escopo por metadados e recuperação com recusa por padrão) que os agentes de voz em produção em plataformas como a Retell AI usam para evitar o modo de falha do passo inventado.
O restante deste guia detalha cada camada com os valores exatos de configuração, uma estrutura de referência modelada em bibliotecas de suporte empresarial como a da Lenovo e o protocolo de testes que captura as alucinações antes que cheguem a quem liga.
Uma arquitetura de recuperação que ancora cada resposta do agente no seu conteúdo verificado, impede o modelo de inventar passos e se mantém dentro do orçamento de latência exigido para conversas telefônicas naturais.
Ao final deste tutorial, a sua base de conhecimento vai:
Arquive cada documento que esteja desatualizado, contraditório ou que não seja a única fonte da verdade para o seu tópico antes de indexar uma única página. A maior fonte de alucinações do agente de voz não é o modelo. É o conteúdo contraditório ou desatualizado no material de origem.
Se duas páginas discordam sobre o seu prazo de reembolso, o recuperador não tem como escolher a correta, e o LLM vai ler com confiança o bloco que vencer a pontuação de similaridade. Reúna todos os documentos, perguntas frequentes e artigos de ajuda que você planeja indexar. Para cada um, verifique três coisas: ele está atual neste trimestre, é a única fonte da verdade para o seu tópico, e corresponde ao que os seus representantes de suporte sênior de fato dizem nas chamadas. Se um documento não deveria ser usado para responder a perguntas de clientes, ele não deveria estar na sua base de conhecimento de forma alguma. ElevenLabs
Você deve ter agora um conjunto curado de documentos que você se sentiria confortável em enviar literalmente a um cliente.
Converta tudo para Markdown estruturado, com um H1 por documento, um H2 descritivo por pergunta resolvível do usuário e parágrafos curtos com sujeitos explícitos. Os agentes de voz recuperam blocos de texto, não páginas web renderizadas. O Markdown é o formato que sobrevive ao pipeline de divisão em blocos com a maior parte da estrutura semântica intacta.
A própria documentação da Retell recomenda o Markdown em vez do .txt porque títulos bem estruturados dão ao recuperador limites limpos para dividir. Substitua cada "clique aqui" ou "como descrito acima" pela referência concreta, porque o bloco que contém "acima" pode ser recuperado sem o bloco para o qual ele aponta. Cada bloco é lido sozinho, então cada bloco precisa fazer sentido sozinho.
Você deve ter agora uma pasta de arquivos Markdown em que cada arquivo cobre uma área de produto e cada H2 cobre uma pergunta resolvível do usuário.
Use a divisão recursiva em blocos de 512 tokens com 10 a 15% de sobreposição, dividindo primeiro nos títulos do Markdown, depois nos parágrafos e, então, nas frases. Este é o padrão validado por benchmark para conteúdo de RAG geral, e ele se sustenta bem especificamente para material de suporte por voz.
Um divisor recursivo de 512 tokens bem ajustado, com 15% de sobreposição e enriquecimento de metadados, supera uma abordagem cara de divisão semântica na maioria dos conjuntos de documentos do mundo real. Blocos longos enchem a janela de contexto do LLM com ruído. Blocos curtos fragmentam instruções em várias recuperações e fazem o agente pular passos no meio da explicação. A regra rígida: nunca divida um procedimento numerado entre dois blocos. Se o "Passo 3" vive no bloco A e o "Passo 4" no bloco B, o recuperador pode retornar um sem o outro e o seu agente vai pular uma ação. Substack
Você deve ter agora blocos em que cada unidade ou contém um procedimento completo ou contém uma prosa contextual que faz sentido sem os seus vizinhos.
Marque cada bloco com, no mínimo, cinco campos: product, version, region, audience e last_verified_date. É isso que impede que quem liga do Texas ouça as políticas de devolução da Califórnia e impede que uma pergunta sobre ThinkPad puxe respostas sobre ThinkCentre.
Se um único agente vê conteúdo de base de conhecimento para vários estados ou localidades, a recuperação pode puxar o bloco do estado errado (por exemplo, a política da Califórnia para quem liga do Texas), a menos que o escopo e os metadados sejam cuidadosamente projetados. O mesmo problema se aplica a linhas de produto, versões de software, níveis de cliente e canais de suporte. Em tempo de execução, o seu agente passa os filtros relevantes junto com a consulta, para que a busca vetorial considere apenas os blocos que correspondem ao contexto de quem liga. Na Retell, você pode passar esses filtros como variáveis dinâmicas coletadas mais cedo na chamada. Optimize Smart
Você deve ter agora um esquema de metadados em que qualquer bloco individual pode ter um escopo exclusivo para um contexto de quem liga.
Defina o limiar de similaridade em 0,65 ou mais e limite a recuperação a 3 a 5 blocos. Um sistema de recuperação que sempre retorna algo é uma máquina de alucinação disfarçada.
Quando quem liga pergunta sobre um recurso que você não documenta, o recuperador ainda vai trazer à tona a correspondência semântica mais próxima. O LLM vai receber esse bloco e fluentemente tecê-lo em uma resposta errada. Nas configurações da base de conhecimento da Retell, dois parâmetros controlam esse comportamento. O parâmetro "Chunks to retrieve" define quantos resultados alimentam o LLM (padrão 3, recomendado no máximo 5 para voz). O "Similarity Threshold" define a similaridade de cosseno mínima para que um bloco seja considerado relevante (padrão 0,6). Para casos de uso de suporte de software, em que uma informação errada é pior do que nenhuma informação, eleve o limiar para 0,7.
Você deve ver agora o seu sistema de recuperação retornando menos correspondências, de maior qualidade, e rejeitando as marginais.
Adicione esta instrução exata ao prompt do agente: "Responda apenas usando as informações em ## Related Knowledge Base Contexts. Se essa seção estiver ausente ou não contiver informações relevantes, diga que não há informações relacionadas disponíveis e ofereça transferir a chamada." Esta única instrução é o controle antialucinação mais eficaz em qualquer agente de voz.
Sem ela, o LLM vai recorrer aos seus dados de treinamento quando a recuperação voltar vazia. Esse é o modo de falha por trás de quase todo desastre público de chatbot, incluindo o caso da tarifa de luto da Air Canada, em que a companhia aérea foi considerada legalmente responsável. O padrão de recusa inverte o modo de falha de "resposta errada com confiança" para "um honesto deixe-me-buscar-um-humano", que é exatamente o que quem usa o seu software de fato quer quando o sistema esbarra em um caso extremo.
Você deve ver agora o seu agente dizendo "Não tenho isso documentado; deixe-me transferir você" em perguntas fora do escopo, em vez de inventar passos.
Habilite a atualização automática nas fontes de URL para que a Retell as rebusque a cada 24 horas, versione os seus arquivos Markdown no Git e faça uma revisão trimestral de qualquer arquivo com um last_verified_date mais antigo que 90 dias. O conhecimento desatualizado é o parceiro silencioso da alucinação.
Se a base de conhecimento está desatualizada, o RAG apenas recupera a resposta errada mais rápido. A solução é automatizar a atualidade em vez de depender de alguém se lembrar de reenviar arquivos quando a documentação do produto muda. Combine a atualização automática com o rastreamento automático (auto-crawling) de subcaminhos da central de ajuda, para que novos artigos sejam indexados automaticamente sem intervenção manual. CX Today
Você deve ter agora uma base de conhecimento que se atualiza sozinha quando o seu conteúdo subjacente é atualizado, sem ninguém no circuito.
Rode as suas 50 perguntas reais de quem liga pelo sistema de recuperação e inspecione o que volta antes de qualquer geração pelo LLM. Três coisas importam para cada consulta: o bloco certo está entre os 3 primeiros, a pontuação de similaridade está acima do seu limiar, e um humano lendo apenas os blocos recuperados conseguiria responder à pergunta.
Para qualquer pergunta em que a recuperação falha, a correção quase sempre está na origem. Ou o conteúdo relevante está totalmente ausente, ou a divisão em blocos partiu um procedimento entre limites, ou os metadados o estão filtrando para fora. Resista ao impulso de corrigir falhas de recuperação adicionando instruções ao prompt do agente. Os remendos de prompt são como as bases de conhecimento viram uma bagunça impossível de manter. Mire em uma precisão de recuperação de mais de 90% no conjunto de testes antes de implantar em chamadas reais.
Você deve ter agora um número medido de precisão de recuperação para as suas principais perguntas de quem liga e uma lista de correções de documentos de origem para as perguntas que falharam.
Use o fluxo de conversa com bases de conhecimento em nível de nó para qualquer agente de voz em que a intenção de quem liga se divida em fluxos de trabalho distintos, especialmente suporte de software, agendamento na saúde e ambientes multiproduto. Uma base de conhecimento plana sob um único prompt é a arquitetura mais frouxa possível.
Para o suporte de software especificamente, o padrão de mais alta qualidade é o fluxo de conversa em que cada nó só recupera da fatia da documentação relevante para aquela parte da chamada. Um fluxo típico de suporte de software tem nós para triagem, consulta de conta, resolução de problemas, escalonamento e confirmação pós-resolução. O nó de resolução de problemas carrega a base de conhecimento de resolução de problemas. O nó de consulta de conta não carrega base de conhecimento nenhuma, porque ele deveria estar chamando uma API. Essa estrutura é mais confiável de manter do que um prompt gigante com uma base de conhecimento gigante. Combine-a com a análise pós-chamada integrada para que você possa ver quais nós estão disparando a recuperação e quais consultas estão voltando abaixo do limiar.
Você deve ter agora uma implantação em que o escopo da recuperação se estreita à medida que a conversa se afunila, em vez de cada turno buscar em todos os documentos.
Organize a base de conhecimento em camadas por público e limite o escopo da recuperação à camada de quem liga. Este é o padrão estrutural que a biblioteca de suporte empresarial da Lenovo usa para evitar que o conteúdo de gestão de sala de aula voltado a professores colida com o conteúdo técnico de engenharia.
A Lenovo estabeleceu três níveis de artigos — tópicos gerais e informações de produto, tópicos específicos para professores, e tópicos e questões técnicas, com artigos focados, redundâncias eliminadas e convenções de nomenclatura padronizadas nos três níveis. Aplique o mesmo padrão a uma base de conhecimento de IA de voz: Contiem
Nível 1: Produto geral e preços. Fatos públicos que qualquer pessoa que ligar pode perguntar. Marcados como audience: all. Indexe tudo.
Nível 2: Como fazer, para o usuário final. Procedimentos passo a passo para quem liga padrão. Marcados como audience: end_user, com escopo por product e region. Este nível carrega a maior parte do tráfego de recuperação.
Nível 3: Técnico e administrativo. Configuração, integrações e casos extremos. Marcados como audience: admin. Recuperados apenas quando quem liga foi identificado como administrador mais cedo na chamada.
Runbooks internos, matrizes de escalonamento e notas de engenharia vão em uma base de conhecimento totalmente separada, nunca acessível ao agente voltado para o cliente. A divisão em níveis é o que impede que uma chamada de resolução de problemas de um usuário final revele acidentalmente um procedimento de escalonamento interno.
Não. A base de conhecimento é para fornecer informações de apoio, não o comportamento do agente. Se você se vir enviando um arquivo Markdown intitulado "Como o agente deve se comportar quando X acontece", esse conteúdo pertence ao prompt ou a um nó do fluxo de conversa. Misturá-los dilui ambos: o recuperador classifica as instruções de comportamento em relação a consultas factuais e as puxa nos momentos errados.
Comece com o objetivo do usuário, não com o nome do recurso. "Configurar a autenticação de dois fatores" vira "Ativar o login de dois fatores". O recuperador faz a correspondência com as palavras faladas por quem liga, e perguntas em linguagem natural correspondem a títulos em linguagem natural muito melhor do que correspondem à terminologia do produto.
Cada bloco é recuperado sozinho. Use nomes completos em vez de pronomes, nomes completos de produtos em vez de "a plataforma", e repita qualquer contexto condicional em cada passo, em vez de dizer "se você estiver usando o console de administração, então..." três parágrafos depois. Essa única regra elimina uma fração surpreendente de alucinações, porque remove a ambiguidade que o LLM, de outra forma, tenta resolver adivinhando.
Capture os blocos recuperados, as pontuações de similaridade e os filtros de metadados em cada chamada, junto com a transcrição. Registrar apenas a resposta final do agente torna a depuração de alucinações quase impossível: você vê a resposta errada, mas não sabe se o recuperador retornou o bloco errado ou se o bloco certo foi gerado incorretamente. A maioria dos tickets de "alucinação" acaba sendo um problema de classificação na recuperação, que é corrigido na origem.
O pipeline de divisão em blocos não consegue preservar as relações espaciais que tornam as tabelas legíveis, então uma célula de tabela muitas vezes é recuperada sem o cabeçalho da sua coluna. Reescreva as tabelas críticas como prosa, com frases explícitas. "O plano Pro suporta 50 usuários e inclui acesso à API" é melhor do que uma célula de tabela que o recuperador separa do cabeçalho da sua coluna.
Uma base de conhecimento com 4.000 blocos em que 50 são relevantes para qualquer pessoa que ligar é pior do que uma com 400 blocos em que 50 são relevantes, porque o recuperador tem 10x mais correspondências concorrentes para confundi-lo. Em vez disso, construa bases de conhecimento estreitas por fluxo de trabalho e vincule-as no nível do nó.
Quando o agente diz algo errado, o instinto é adicionar "não diga X" ao prompt. Três desses e o prompt fica contraditório; dez e ele fica ingerenciável. Descubra por que o LLM disse X. Quase sempre, um bloco na base de conhecimento o sugeriu, ou a ausência de um bloco forçou o modelo a recorrer aos dados de treinamento. Corrija a origem.
Cada bloco adicional acrescenta tokens ao prompt e milissegundos à resposta. Definir o "chunks to retrieve" como 10 porque mais contexto parece mais seguro é um erro comum. Fique em 3 blocos para conteúdo de suporte típico, aumente para 5 apenas quando as perguntas de quem liga abrangerem vários tópicos, e nunca vá além disso a menos que você tenha medido uma melhoria na precisão.
Porque o agente tem permissão para falar sem uma instrução de recusa explícita. O chatbot da Air Canada foi responsabilizado depois de gerar uma política de luto inexistente que contradizia as regras reais da companhia aérea, e falhas semelhantes continuam se repetindo entre fornecedores que pulam a camada de recusa. Torne a recusa explícita, teste se ela é acionada e trate qualquer caso em que o agente inventa informações como um bug P0. CanLII
Adicionar um novo documento muda o cenário de recuperação para cada consulta existente. Um bloco que classificou em primeiro ontem pode classificar em terceiro hoje. Mantenha o conjunto de testes de 50 perguntas automatizado e rode-o novamente sempre que o conteúdo subjacente mudar de forma significativa.
A SWTCH implantou um agente de voz movido pela Retell, chamado Lucas, para lidar com chamadas de suporte a carregadores de veículos elétricos, em que quem liga está normalmente parado em frente a um carregador morto, com a bateria baixa e sem paciência para uma instrução errada. A implementação reduziu os custos de suporte em mais de 50% e melhorou significativamente as margens de SaaS, com o agente atendendo em segundos em vez de minutos. A régua de confiabilidade foi definida pelo caso de uso: um passo de resolução de problemas errado é a diferença entre um carregador funcionando e um motorista parado na estrada.
A Anker implantou a Retell em todo o suporte global de eletrônicos de consumo, em que quem liga faz perguntas específicas de produto sobre dezenas de SKUs e em vários idiomas. O estudo de caso ilustra por que o escopo por metadados importa em escala. Sem a filtragem em nível de produto na recuperação, uma pergunta sobre uma soundbar pode puxar o manual de um aspirador de pó, e o agente vai combiná-los com confiança. Com a estrutura adequada da base de conhecimento, o agente permanece dentro do contexto do produto durante toda a chamada.
A Retell AI agora impulsiona mais de 50 milhões de chamadas telefônicas com IA em tempo real todo mês para clientes em milhares de empresas, sem nenhum agente relatado saindo dos trilhos em todo esse volume. A arquitetura deste guia é a mesma que roda por baixo dessas chamadas. Yahoo Finance
A divisão recursiva em blocos de 512 tokens com 10 a 15% de sobreposição é o padrão validado por benchmark. Blocos menores (200 a 300 tokens) funcionam para conteúdo no estilo de perguntas frequentes; blocos maiores (1024 tokens) funcionam para prosa narrativa. Sempre divida primeiro nos títulos do Markdown, depois nos parágrafos e, então, nas frases.
Adicione uma instrução de recusa explícita ao prompt do agente: "Responda apenas usando as informações em ## Related Knowledge Base Contexts. Se essa seção estiver ausente ou não contiver informações relevantes, responda que não há informações relacionadas disponíveis." Combinada com um limiar de similaridade de 0,65 ou mais, este é o controle antialucinação único mais eficaz.
Menos de 100ms por turno no pipeline de recuperação otimizado da Retell, mantendo o agente dentro da janela de resposta total de ~600ms que quem liga espera. Se você observar uma latência materialmente maior, verifique se está recuperando mais blocos do que precisa ou se a filtragem por metadados está sendo aplicada no momento da consulta em vez de após a recuperação.
O fluxo de conversa vence para o suporte de software e qualquer cenário em que a intenção de quem liga se divide em fluxos de trabalho distintos. As bases de conhecimento em nível de nó permitem que cada estado da conversa recupere de uma fatia focada de conteúdo, o que melhora a precisão e torna a manutenção simples. Os prompts únicos funcionam para casos de uso estreitos, como uma FAQ de produto único. O guia de implantar IA conversacional da Retell cobre a escolha arquitetural em mais detalhes.
Habilite a atualização automática nas fontes de URL para que a Retell as rebusque a cada 24 horas. Para documentos enviados, faça uma revisão manual sempre que o produto ou a política subjacente mudar e trate qualquer coisa mais antiga que 90 dias como precisando de verificação.
Sim, parcialmente. Você pode usar transcrições de chamadas bem-sucedidas e gravações de representantes sênior como material de origem para a base de conhecimento. Extraia os pares de pergunta e resposta, converta-os para Markdown e indexe-os ao lado da sua documentação formal. Isso é especialmente útil para capturar o fraseado específico que os seus melhores representantes usam, que muitas vezes resolve problemas mais rápido do que o texto oficial da central de ajuda. Isso não substitui a documentação estruturada; ele a complementa.
No mínimo: product, version, region, audience e last_verified_date. Adicione topic para um roteamento granular em um fluxo de conversa, e compliance_scope se você tem conteúdo regulado (HIPAA, aconselhamento financeiro) que nunca deveria ser recuperado fora de contextos de chamada específicos.
Construa um conjunto de testes de 50 a 100 perguntas reais de quem liga dos últimos 30 dias de tickets de suporte. Para cada uma, inspecione os blocos recuperados antes de qualquer geração pelo LLM: o bloco certo está entre os 3 primeiros, a pontuação de similaridade está acima do limiar, e um humano conseguiria responder à pergunta apenas com esses blocos. Mire em uma precisão de recuperação de mais de 90% no conjunto de testes antes de implantar.
Com uma instrução de recusa em vigor e um limiar de similaridade de 0,65 ou mais, o agente diz que não tem essa informação documentada e ou se oferece para anotar um recado ou faz a transferência assistida via transferência de chamadas para um agente humano com o contexto completo da conversa. Sem esses controles, o agente recorre aos dados de treinamento do LLM subjacente, que é exatamente o modo de falha que este guia foi projetado para evitar.
Você agora tem uma arquitetura de base de conhecimento que ancora cada resposta do agente em conteúdo verificado, limita o escopo da recuperação pelo contexto de quem liga, recusa-se a responder quando a resposta não está documentada e se atualiza à medida que o seu material de origem muda. Essa é a base que permite a um agente de voz lidar com suporte de software, setores regulados ou qualquer chamada de alto risco em que um passo errado importa mais do que um passo rápido.
Para estender isso ainda mais, a mesma arquitetura de recuperação suporta casos de uso como a automação de suporte ao cliente com IA, a qualificação de leads com roteamento específico por produto, e recepcionistas movidos por IA para consultórios de saúde, em que o escopo de conformidade é inegociável. Os mesmos padrões também se aplicam a implantações em saúde e seguros, em que o custo de uma alucinação é uma questão regulatória, não apenas de experiência do cliente.
Comece a construir grátis com US$ 10 em créditos de uso em retellai.com.
Veja quanto seu negócio poderia economizar ao migrar para agentes de voz com IA.
Total Human Agent Cost
AI Agent Cost
Estimated Savings
Um número de telefone de demonstração do consultório da Retell Clinic
Start building smarter conversations today.
.avif)
.avif)
