Pré-requisito: Reunir requisitos
Definir requisitos de caso de uso claros e abrangentes é uma primeira etapa crítica no desenvolvimento bem-sucedido de um aplicativo RAG. Esses requisitos atendem a duas finalidades primárias. Em primeiro lugar, eles ajudam a determinar se o RAG é a abordagem mais adequada para o caso de uso determinado. Se o RAG for realmente uma boa opção, esses requisitos orientarão as decisões de design, implementação e avaliação da solução. Investir tempo no início de um projeto para reunir requisitos detalhados pode evitar desafios e problemas significativos posteriormente no processo de desenvolvimento e garante que a solução resultante atenda às necessidades dos usuários finais e dos stakeholders. Os requisitos bem definidos fornecem a base para os estágios subsequentes do ciclo de vida de desenvolvimento que percorreremos’.
Consulte o repositório do GitHub para obter o código de exemplo nesta seção. Você também pode usar o código do repositório como um modelo para criar seus próprios aplicativos de IA.
O caso de uso é uma boa opção para RAG?
A primeira coisa que você precisa estabelecer é se o RAG é mesmo a abordagem certa para seu caso de uso. Dado o entusiasmo em torno do RAG, é tentador vê-lo como uma possível solução para qualquer problema. No entanto, existem nuances sobre quando o RAG é adequado ou não.
O RAG é uma boa opção ao:
- Raciocínar sobre informações recuperadas (não estruturadas e estruturadas) que não cabem inteiramente na janela de contexto do LLM
- Sintetizar informações de várias fontes (por exemplo, gerar um resumo de pontos-chave de artigos diferentes sobre um tópico)
- Houver necessidade de recuperação dinâmica com base em uma consulta de usuário (por exemplo, dada uma consulta de usuário, determine de qual fonte de dados recuperar)
- O caso de uso requer a geração de conteúdo novo com base nas informações recuperadas (por exemplo, responder a perguntas, fornecer explicações, oferecer recomendações)
O RAG pode não ser o melhor ajuste quando:
- A tarefa não requer recuperação específica de consulta. Por exemplo, gerando resumos de transcrição de chamadas; mesmo que as transcrições individuais sejam fornecidas como contexto no prompt de LLM, as informações recuperadas permanecem as mesmas para cada resumo.
- Todo o conjunto de informações a serem recuperadas pode caber dentro da janela de contexto do LLM
- Respostas extremamente de baixa latência são necessárias (por exemplo, quando as respostas são necessárias em milissegundos)
- Respostas simples baseadas em regras ou modelos são suficientes (por exemplo, um chatbot de suporte ao cliente que fornece respostas predefinidas com base em palavras-chave)
Requisitos para descobrir
Depois de estabelecer que o RAG é uma boa opção para seu caso de uso, considere as perguntas a seguir para capturar requisitos concretos. Os requisitos são priorizados da seguinte maneira:
🟢 P0: deve definir esse requisito antes de iniciar sua POC.
🟡 P1: deve definir antes de ir para a produção, mas pode refinar iterativamente durante a POC.
⚪ P2: é bom ter requisitos.
Esta não é uma lista completa de perguntas. No entanto, ela deve fornecer uma base sólida para capturar os principais requisitos para sua solução de RAG.
Experiência do usuário
Definir como os usuários interagirão com o sistema RAG e que tipo de respostas são esperadas
🟢 [P0] Como será uma solicitação típica para a cadeia de RAG? Peça aos stakeholders exemplos de possíveis consultas de usuário.
🟢 [P0] Que tipo de respostas os usuários esperam (respostas curtas, explicações de forma longa, uma combinação ou outra coisa)?
🟡 [P1] Como os usuários interagirão com o sistema? Por meio de uma interface de chat, barra de pesquisa ou alguma outra modalidade?
🟡 [P1] Qual estilo ou tom deve ter as respostas geradas? (formal, conversa, técnico?)
🟡 [P1] Como o aplicativo deve lidar com consultas ambíguas, incompletas ou irrelevantes? Alguma forma de comentários ou diretrizes deve ser fornecida nesses casos?
⚪ [P2] Há requisitos específicos de formatação ou apresentação para a saída gerada? A saída deve incluir metadados além da resposta da cadeia’?
Dados
Determine a natureza, as fontes e a qualidade dos dados que serão usados na solução RAG.
🟢 [P0] Quais são as fontes disponíveis para uso?
Para cada fonte de dados:
- 🟢 [P0] Dados são semiestruturados ou não estruturados?
- 🟢 [P0] Qual é o formato de origem dos dados de recuperação (por exemplo, PDFs, documentação com imagens/tabelas, respostas estruturadas da API)?
- 🟢 [P0] Onde residem esses dados?
- 🟢 [P0] Quantos dados estão disponíveis?
- 🟡 [P1] Com que frequência os dados são atualizados? Como essas atualizações devem ser tratadas?
- 🟡 [P1] Há problemas de qualidade de dados conhecidos ou inconsistências para cada fonte de dados?
Considere a criação de uma tabela de inventário para consolidar essas informações, por exemplo:
| Fonte de dados | Origem | Tipo(s) de arquivo | Tamanho | Frequência de atualização |
|---|---|---|---|---|
| Fonte de dados 1 | Volume do Catálogo do Unity | JSON | 10GB | Diariamente |
| Fonte de dados 2 | API pública | XML | NA (API) | Tempo real |
| Fonte de dados 3 | SharePoint | PDF, .docx | 500MB | Mensal |
Restrições de desempenho
Capture os requisitos de desempenho e recursos para o aplicativo RAG.
🟡 [P1] Qual é a latência máxima aceitável para gerar as respostas?
🟡 [P1] Qual é o tempo máximo aceitável para o primeiro token?
🟡 [P1] Se a saída estiver sendo transmitida, a latência total maior será aceitável?
🟡 [P1] Há limitações de custo em recursos de computação disponíveis para inferência?
🟡 [P1] Quais são os padrões de uso esperados e as cargas de pico?
🟡 [P1] Quantos usuários ou solicitações simultâneas o sistema deve ser capaz de lidar? O Databricks lida nativamente com esses requisitos de escalabilidade por meio da capacidade de dimensionar automaticamente com Serviço de Modelo.
Avaliação
Estabeleça como a solução de RAG será avaliada e aprimorada ao longo do tempo.
🟢 [P0] Qual é a meta de negócios/KPI que você deseja impactar? Qual é o valor da linha de base e qual é o destino?
🟢 [P0] Quais usuários ou stakeholders fornecerão comentários iniciais e contínuos?
🟢 [P0] Quais métricas devem ser usadas para avaliar a qualidade das respostas geradas? A Avaliação de Agente de IA do Mosaico fornece um conjunto recomendado de métricas a serem usadas.
🟡 [P1] Qual é o conjunto de perguntas em que o aplicativo RAG deve ser bom para entrar em produção?
🟡 [P1] Existe um [conjunto de avaliações]? É possível obter um conjunto de avaliação de consultas de usuário, juntamente com respostas básicas e (opcionalmente) os documentos de suporte corretos que devem ser recuperados?
🟡 [P1] Como os comentários do usuário serão coletados e incorporados ao sistema?
Segurança
Identifique quaisquer considerações de segurança e privacidade.
🟢 [P0] Há dados sensíveis/confidenciais que precisam ser tratados com cuidado?
🟡 [P1] Os controles de acesso precisam ser implementados na solução (por exemplo, um determinado usuário só pode recuperar de um conjunto restrito de documentos)?
Implantação
Noções básicas sobre como a solução RAG será integrada, implantada e mantida.
🟡 Como a solução RAG deve se integrar aos sistemas e fluxos de trabalho existentes?
🟡 Como o modelo deve ser implantado, dimensionado e com versão? Este tutorial aborda como o ciclo de vida de ponta a ponta pode ser tratado no Databricks usando o MLflow, o Catálogo do Unity, o SDK do Agente e o Serviço de Modelo.
Exemplo
Por exemplo, considere como essas perguntas se aplicam a este aplicativo RAG de exemplo usado por uma equipe de suporte ao cliente do Databricks:
| Área | Considerações | Requisitos |
|---|---|---|
| Experiência do usuário | - Modalidade de interação. - Exemplos típicos de consulta de usuário. - Formato e estilo de resposta esperado. - Tratamento de consultas ambíguas ou irrelevantes. |
- Interface de chat integrada ao Slack. - Consultas de exemplo: “como reduzir o tempo de inicialização do cluster?” “Qual tipo de plano de suporte eu tenho?” - Respostas técnicas claras com snippets de código e links para a documentação relevante, quando apropriado. - Forneça sugestões contextuais e escale para dar suporte aos engenheiros quando necessário. |
| Dados | - Número e tipo de fontes de dados. - Formato e localização de dados. - Tamanho de dados e frequência de atualização. - Qualidade e consistência dos dados. |
- Três fontes de dados. - Documentação da empresa (HTML, PDF). - Tíquetes de suporte resolvidos (JSON). - Postagens do fórum da comunidade (tabela Delta). - Dados armazenados no Catálogo do Unity e atualizados semanalmente. - Tamanho total dos dados: 5 GB. - Estrutura de dados consistente e qualidade mantida por equipes de suporte e documentos dedicados. |
| Desempenho | - Latência máxima aceitável. - Restrições de custo. - Uso e simultaneidade esperados. |
- Requisitos de latência máxima. - Restrições de custo. - Carga de pico esperada. |
| Avaliação | - Disponibilidade do conjunto de dados de avaliação. - Métricas de qualidade. - Coleta de comentários do usuário. |
- Especialistas em assuntos de cada área do produto ajudam a examinar as saídas e ajustar respostas incorretas para criar o conjunto de dados de avaliação. - KPIs de negócios. - Aumentar a taxa de resolução de tíquetes de suporte. - Diminuir o tempo gasto pelo usuário por tíquete de suporte. - Métricas de qualidade. - Correção e relevância da resposta julgada por LLM. - A LLM julga a precisão da recuperação. - Voto a favor ou voto contra do usuário. - Coleta de feedback. - O Slack será instrumentado para fornecer uma aprovação/desaprovação. |
| Segurança | - Administração de dados confidenciais. - Requisitos de controle de acesso. |
- Nenhum dado confidencial do cliente deve estar na fonte de recuperação. - Autenticação de usuário por meio do SSO da Comunidade do Databricks. |
| Implantação | - Integração com sistemas existentes. - Implantação e controle de versão. |
- Integração com o sistema de tíquetes de suporte. - Cadeia implantada como um ponto de extremidade de Serviço de Modelo do Databricks. |
Próxima etapa
Introdução à Etapa 1. Clonar repositório de código e criar o recurso de computação.