O formulário foi enviado com sucesso.
Encontrará mais informações na sua caixa de correio.
Contrate-nos
Contrate-nos
Contrate-nos Selecionar a língua
Sobre nós 
Tecnologias Carteira
Contrate-nos 
Se já experimentou um chatbot LLM no trabalho, sabe qual é o ponto de rutura: parece confiante, mas depois alguém pergunta por um pormenor de política, uma regra de produto ou o processo interno mais recente, e a resposta está errada ou é vaga. A sua equipa acaba por verificar tudo duas vezes, pesquisar em PDFs e wikis e preocupar-se com quem viu o quê no chat.
Um chatbot RAG liga um LLM aos conhecimentos aprovados da sua empresa no momento da pergunta. Extrai as passagens certas dos seus documentos, utiliza-as como base para a resposta e pode mostrar o texto de origem para que as pessoas o possam verificar. As regras de acesso podem fazer parte da configuração, para que o bot não apresente conteúdos sensíveis à pessoa errada.
Neste guia, explicarei as Definição do chatbot RAG, A Geração Aumentada por Recuperação (RAG) é uma ferramenta de gestão de riscos que permite às equipas de trabalho compreender como funciona a Geração Aumentada por Recuperação, onde se enquadra melhor e como implementá-la passo a passo, incluindo as funcionalidades e verificações de segurança de que as equipas normalmente necessitam em ambientes reais.
Um chatbot RAG, ou recuperação geração aumentada chatbot, O LLM é um assistente de conversação que responde com os dados que tem à sua frente. Antes de responder, procura nos seus documentos, bases de dados ou APIs as partes mais relevantes e, em seguida, o LLM escreve a resposta utilizando esse contexto extraído. O contraste é simples. Um LLM simples responde com base no que se lembra (a partir de dados inseridos anteriormente). A RAG AI chatbot respostas após verifica as suas fontes, o que reduz as alucinações e acrescenta citações para apoiar as suas afirmações.
Para compreender o Significado do chatbot RAG Sem jargão, imaginem isto. Segunda-feira de manhã. Está a reservar um voo de 9 horas para uma viagem de um cliente e (de certeza) quer ser rápido, por isso deixa uma mensagem no chat para verificar se a sua empresa cobre a classe económica premium para voos com mais de 6 horas. O bot básico responde imediatamente que sim. Faz a reserva. Está feito.
Duas semanas depois, o seu pedido de reembolso de despesas é rejeitado. Porque, sem o seu conhecimento, a política foi alterada no último trimestre, tendo sido adicionado um novo passo de aprovação. Agora, tem uma troca de impressões com o departamento financeiro, o seu gestor é chamado a intervir e está a pesquisar na wiki para tentar provar qual é a regra.
Chatbot alimentado por RAG responde à mesma questão verificando primeiro a política de viagens, citando a regra exacta e retirando a ligação. Ou se faz a reserva correta ou se obtém primeiro a aprovação. De qualquer forma, não há surpresas mais tarde.
As diferenças são mais fáceis de compreender quando olhamos para exemplos comuns:
Normalmente, na primeira semana é possível saber se um chatbot vai pegar. Se as pessoas não confiarem nas respostas, deixam de o utilizar. Se não puderem verificar a fonte, param ainda mais depressa. O RAG dá-lhes algo sólido em que se podem apoiar. Aqui estão as vitórias que vejo com mais frequência quando está a funcionar:
Criámos muitos sistemas com muitos documentos para equipas internas: políticas, bases de conhecimento, portais, tudo. Por isso, sabemos o que quebra primeiro. Se está a planear um chatbot RAG para uma empresa, estas são as funcionalidades que as equipas mais pedem. Não porque pareçam fixes. Porque o salvam quando os utilizadores reais aparecem.
Quando um bot responde sem mostrar a sua fonte, as pessoas hesitam porque não podem confiar totalmente nele. A atribuição da fonte adiciona um link ou nota para o documento e secção exactos de onde veio a resposta. Assim, quando alguém pergunta: “De onde é que isso veio?”, o bot pode apontar para o recibo em vez de obrigar as pessoas a pesquisar na wiki.
Algumas perguntas são caça às palavras-chave, como o erro 0x801c03f3, um número de peça ou uma ID de política. Outras são apenas a forma como as pessoas falam, por exemplo, “Porque é que isto está a falhar após a atualização?” A pesquisa híbrida abrange ambos. Executa a pesquisa de palavras-chave (BM25) juntamente com a pesquisa de vectores, para que o bot possa corresponder à cadeia exacta e ainda assim captar a intenção por detrás da pergunta. Sem ela, obtém-se as falhas irritantes. Você pergunta sobre um código ou ID exato, o documento tem esse código exato, e o bot continua a puxar a página errada ou diz que não encontrou nada.
As pessoas não falam com os bots como falam com uma barra de pesquisa. Escrevem depressa, saltam pormenores e deixam escapar respostas vagas. A reescrita de consultas corrige isso antes mesmo de a pesquisa começar. Limpa os erros de digitação, preenche o contexto em falta sempre que possível e transforma uma pergunta confusa em algo que o sistema pode realmente procurar. Desta forma, evita-se o Chatbot RAG LLM agarrar o documento errado desde o primeiro passo.
A pesquisa raramente devolve uma correspondência perfeita. Dá-lhe uma pilha de correspondências suficientemente próximas. E o modelo tende a pegar na primeira coisa que vê e a construir a resposta em torno dela. A reclassificação corrige isso. Pega nos melhores resultados, classifica-os novamente e coloca os melhores em primeiro lugar antes de o modelo começar a escrever. A diferença é óbvia na utilização real. Obtém-se menos desvios estranhos e menos respostas baseadas no parágrafo errado.
A maioria dos documentos da empresa é longa, e a parte útil raramente está no primeiro parágrafo. Sem compressão, o bot puxa parágrafos inteiros e a resposta começa a vaguear. Graças à compactação, ele reduz a fonte às poucas linhas que realmente importam para a pergunta e deixa o resto de lado. Assim, obtém-se uma resposta mais limpa.
Uma hiperligação de citação é melhor do que nada, mas continua a enviar-nos para um PDF gigante e passamos cinco minutos à procura de uma frase. As pré-visualizações de citações eliminam essa dor. Passa o rato sobre a citação e o Chatbot RAG LLM mostra as linhas exactas que utilizou. Verifica-se em dois segundos e segue-se em frente.
O chat real é uma cadeia, não uma única pergunta. Você pergunta algo, recebe uma resposta e continua. A memória de conversação mantém o bot no fio da meada, para que ele entenda a que se está a referir e possa continuar sem reiniciar. Sem ela, o bot esquece-se, você repete tudo, e o chat começa a parecer um formulário com passos extra.
As equipas guardam informações importantes em tabelas, gráficos, capturas de ecrã e PDFs digitalizados. Um bot só de texto não consegue ler esse conteúdo, pelo que pode perder o pormenor que decide a resposta. O suporte multimodal permite que o bot leia esses formatos e os utilize na resposta. Esta funcionalidade é importante em manuais e relatórios financeiros, em que a resposta se encontra frequentemente numa célula de uma tabela.
O chatbot com RAG tem de seguir as suas regras de acesso, tal como qualquer empregado, incluindo os casos complicados em que um documento tem secções abertas e secções restritas. Se o fizer de forma incorrecta, a implementação será bloqueada. Se o fizer de forma correta, as pessoas podem utilizar o chat sem se preocuparem com o facto de este poder divulgar algo que não devem.
Alguns ambientes necessitam de controlos mais rigorosos em matéria de integridade e utilização indevida. Uma abordagem que vi numa implementação de referência é adicionar uma camada de cadeia de blocos para a governação. Esta pode armazenar registos de uma forma apenas anexa, enquanto os contratos inteligentes executam regras de governação utilizando a votação e o consenso para a aplicação das regras. Mas isto não é necessário para todos os projectos. Considere-o quando pretender controlos mais fortes sobre a forma como o conteúdo e as permissões mudam ao longo do tempo.
Os sistemas RAG são atacados de formas específicas. A injeção de prompts e o conteúdo envenenado são comuns. Pode adicionar monitorização que analisa os registos de conversação para detetar padrões de risco, analisa documentos para detetar sinais de envenenamento e observa o fluxo de dados para detetar atividade invulgar. Se algo parecer estranho, o sistema assinala-o e encaminha-o para um caminho de resposta, como bloquear a fonte, alertar a segurança ou forçar um passo de revisão.
Não precisa de um motivo sofisticado para construir isto. Se a sua equipa está sempre a perguntar a mesma coisa e a resposta já está escrita algures, está a pagar a taxa de pesquisa. Um bot que pode citar a fonte acaba com essa dor rapidamente. Reuni os casos de utilização em que essa lacuna é mais evidente.
Os chatbots tradicionais limitam-se normalmente a um menu fixo de perguntas. Se não o fizerem, ficam bloqueados. Um chatbot com RAG pode procurar a resposta nas fontes que liga, para que as respostas correspondam ao que os seus documentos e sistemas realmente dizem.
Escolha primeiro um domínio específico, como documentos de suporte, políticas internas ou manuais de execução IT. Anote as principais perguntas que deseja cobrir e defina o que conta como uma resposta correta. Decida o que o bot faz quando as fontes não suportam uma resposta. Por exemplo, indicar ao utilizador a secção correta do documento ou fazer uma pergunta de seguimento para limitar o pedido.
Comece por enumerar todas as fontes que espera que o Chatbot RAG LLM a utilizar, quem é o seu proprietário, qual a sua atualidade e quais as regras de acesso. Em seguida, limpe o material que será recuperado mais tarde:
Se as políticas mudam com frequência, chegue a acordo sobre uma regra de versão simples para que os rascunhos antigos não continuem a ganhar. Além disso, armazene as permissões com os documentos e imponha-as sempre que o bot recupera o conteúdo.
A qualidade da recuperação depende de dois factores: a forma como divide o conteúdo e como o rotula. No caso das políticas e procedimentos, divida-os por secções e títulos para que o texto recuperado seja legível por si só. Adicione uma pequena sobreposição para não cortar uma regra em dois blocos. Deduplique as repetições para que os parágrafos copiados não dominem a recuperação. Uma vez divididos e limpos, passe estes blocos de texto por um modelo de incorporação para os converter em números vectoriais, o que permite que a base de dados pesquise posteriormente por significado e contexto.
Adicione metadados que serão filtrados posteriormente (título, secção, data, equipa, região, produto, versão). Defina accionadores de reindexação, como uma atualização de documento, uma nova versão ou uma alteração de permissão. Para PDFs e digitalizações, execute a extração de texto e verificações de qualidade para não indexar texto quebrado.
Como já sabe, um chatbot RAG precisa de algumas partes a trabalhar em conjunto:
Agora tem uma verdadeira escolha: optar por uma configuração pronta a utilizar ou criar uma pilha própria.
Uma configuração com um clique permite-lhe obter uma demonstração rapidamente. No entanto, também torna as alterações dolorosas mais tarde. Uma pilha que você controla dá-lhe espaço para se mover. Por exemplo, uma interface de utilizador React com serviços Python por trás permite-lhe trocar o fornecedor LLM ou a camada de recuperação sem ter de reconstruir tudo.
Neste caso, recomendo a segunda opção se quiser manter o controlo quando as coisas mudam.
A fuga de permissões é uma falha da qual é difícil recuperar. Por exemplo, um funcionário júnior faz uma pergunta inofensiva sobre salários. O Chatbot alimentado por RAG vai à procura, pega numa linha da pasta privada do Diretor Executivo e coloca-a no chat. Agora é um problema da empresa.
É por isso que as permissões têm de fazer parte da recuperação. Filtrar durante a recuperação utilizando listas de acesso a documentos, associação a grupos e etiquetas de metadados. Executar novamente as mesmas verificações quando o utilizador abre uma ligação de origem.
Planeie também o acesso parcial. Alguns utilizadores podem ver uma secção de um documento mas não outra, o que afecta a fragmentação e os metadados. Se os utilizadores pedirem códigos, IDs ou números de apólices exactos, a recuperação híbrida (semântica e palavra-chave) funciona muitas vezes melhor do que a incorporação isolada.
Depois de definidas a recuperação e as permissões, decida o que aparece na resposta. As pessoas querem duas coisas: a resposta e a prova logo abaixo dela.
Uma predefinição sólida tem o seguinte aspeto:
Em seguida, defina a regra de não adivinhar. Se o que o bot extraiu não for a resposta, o bot deve dizer isso e fazer uma pergunta de seguimento específica ou enviar o utilizador para a secção de origem.
Antes do lançamento, testar o Chatbot alimentado por RAG com perguntas reais de utilizadores reais. Procure pontos fracos, tais como quando a recuperação obtém a secção errada, não encontra o documento certo ou a resposta vai para além do que a fonte diz. Utilize estas descobertas para ajustar o tamanho dos blocos, as definições de recuperação, os filtros de metadados e os avisos.
Simplifique o processo de avaliação, dividindo-o em duas partes. Primeiro, veja se a recuperação encontrou a passagem correta. De seguida, verifique se a resposta se manteve dentro dessa passagem. Acompanhe a taxa de acerto da recuperação, a cobertura das citações e quantas respostas são apoiadas pela fonte para medir o progresso ao longo do tempo.
Adicione verificações para a injeção de mensagens, registe quem perguntou o quê e guarde as fontes utilizadas para cada resposta. Se o seu ambiente estiver em risco mais elevado, esteja atento a conteúdos nocivos e a fluxos de dados estranhos que pareçam estranhos. Reduza segredos e dados pessoais quando necessário, defina regras de retenção claras para registos de conversação e fragmentos recuperados e mantenha registos de auditoria que mostrem o utilizador, as fontes recuperadas e a resposta final.
Distribuir em pequenas versões. Comece com um piloto, leia as conversas reais, corrija o que não funciona e depois alargue o acesso. Após o lançamento, nomeie proprietários para actualizações de conteúdos, ajustes de recuperação e alterações de permissões. Sem proprietários, os documentos mudam, as pastas deslocam-se e o bot começa lentamente a dar respostas em que as pessoas deixam de confiar.
De acordo com a minha experiência, um pequeno projeto-piloto demora normalmente entre 4 a 8 semanas. Trata-se de um domínio, um fluxo de conversação que funciona de ponta a ponta, fontes e citações, além de verificações básicas de acesso. O suficiente para provar que o bot pode responder e mostrar o seu trabalho. Não o suficiente para se transformar numa missão secundária.
Uma implementação mais alargada demora normalmente 10 a 16 semanas. Esse tempo extra é necessário para obter mais tipos de fontes, lidar com permissões mais rigorosas, adicionar monitorização e registos e testar com as perguntas confusas que as pessoas realmente escrevem.
A equipa é normalmente assim:
Também é possível contratar um engenheiro de segurança de aprendizagem automática quando a injeção rápida e o conteúdo envenenado são riscos reais. Ou adicionar competências em cadeias de blocos, mas apenas quando a governação com um registo apenas de anexos faz parte do plano.
Quando um chatbot RAG entra em funcionamento, as equipas podem atingir um aumento de produtividade de 41% e um salto de 20% na deteção de tentativas de violação. Muito louco.
Claro, não posso prometer que verá os mesmos números. Esses resultados foram obtidos em construções específicas e os pormenores são importantes. Pelo menos não antes de analisarmos o seu âmbito. A questão mantém-se. Quando o bot responde a partir de fontes aprovadas e as regras de acesso se mantêm apertadas, o trabalho acelera e as actividades de risco são detectadas mais cedo.
Se quiser verificar se um chatbot RAG se adequa à sua equipa, mostramos-lhe o que é um chatbot baseado em RAG, A nossa equipa de especialistas em segurança da informação, partilha casos semelhantes, analisa os seus casos de utilização e fontes de dados e ajuda-o a conceber uma construção que se adapte às suas restrições.
Pode utilizar documentos internos, artigos da base de conhecimentos, páginas wiki, conteúdos de suporte e outras fontes de texto que aprove. A chave é que o utilizador controla as fontes e as regras de acesso.
Um exemplo comum é um chatbot dentro de uma ferramenta de colaboração interna em que os funcionários pedem resumos, extraem cláusulas e comparam documentos, enquanto o bot devolve trechos de fontes e impõe limites de visualização.
Nem sempre. Muitas construções utilizam modelos existentes para incorporação e geração, concentrando depois os esforços na preparação dos dados, na qualidade da recuperação, nas permissões e na monitorização.
Os problemas mais comuns incluem a recuperação da parte errada, a falta de contexto chave e a injeção de prompt para orientar o modelo. As análises de segurança e a monitorização ajudam, além dos formatos de resposta que apontam para o texto de origem.
