Pré-requisito: reunir requisitos

A definição de requisitos de casos de uso claros e abrangentes é um primeiro passo fundamental para o desenvolvimento de um aplicativo RAG bem-sucedido. Esses requisitos atendem a dois propósitos principais. Em primeiro lugar, eles ajudam a determinar se o RAG é a abordagem mais adequada para o caso de uso específico. Se o RAG for de fato uma boa opção, esses requisitos guiarão as decisões de projeto, implementação e avaliação. Investir tempo no início de um projeto para reunir requisitos detalhados pode evitar desafios e contratempos significativos mais tarde no processo de desenvolvimento, além de garantir que as soluções resultantes atendam às necessidades dos usuários finais e das partes interessadas. Requisitos bem definidos fornecem a base para os estágios subsequentes do ciclo de vida de desenvolvimento que abordaremos.

Consulte o repositório do GitHub para obter o código de amostra nesta seção.

O caso de uso é adequado para o RAG?

A primeira coisa que você precisa estabelecer é se o RAG é mesmo a abordagem certa para seu caso de uso. Dado o hype em torno do RAG, é tentador view 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 quando:

• Raciocínio sobre informações recuperadas (estruturadas e não estruturadas) que não se encaixam totalmente na janela de contexto do site LLM

• Sintetizar informações de várias fontes (por exemplo, gerar um resumo de key pontos de diferentes artigos sobre um tópico)

• A recuperação dinâmica com base em uma consulta do usuário é necessária (por exemplo, dada uma consulta do usuário, determinar 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 mais adequado quando:

• A tarefa não exige a recuperação específica da consulta. Por exemplo, a geração de resumos de transcrições de chamadas; mesmo que transcrições individuais sejam fornecidas como contexto no prompt LLM, as informações recuperadas permanecem as mesmas para cada resumo.

• O conjunto completo de informações a serem recuperadas pode caber na janela de contexto do site LLM

• Respostas de latência extremamente baixa são necessárias (por exemplo, quando as respostas são necessárias em milissegundos)

• Respostas simples baseadas em regras ou em 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 é adequado para seu caso de uso, considere as perguntas a seguir para capturar requisitos concretos. Os requisitos são priorizados da seguinte forma:

🟢 P0: É necessário definir esse requisito antes de iniciar seu POC.

🟡 P1: Deve ser definido antes de entrar em produção, mas pode refinar iterativamente durante o POC.

⚪ P2: É bom ter requisitos.

Esta não é uma lista exaustiva de perguntas. No entanto, ele deve fornecer uma base sólida para capturar os requisitos do key para suas soluções RAG.

Experiência do usuário

Defina como os usuários interagirão com o sistema RAG e que tipo de respostas são esperadas

🟢 [P0] Qual será a aparência de uma solicitação típica para a cadeia RAG? Peça às partes interessadas exemplos de possíveis consultas de usuários.

🟢 [P0] Que tipo de respostas os usuários esperam (respostas curtas, explicações longas, uma combinação ou outra coisa)?

🟡 [P1] Como os usuários interagirão com o sistema? Por meio de uma interface de bate-papo, barra de pesquisa ou alguma outra modalidade?

🟡 [P1] Que tom ou estilo as respostas geradas devem adotar? (formal, coloquial, técnico?)

🟡 [P1] Como o aplicativo deve lidar com consultas ambíguas, incompletas ou irrelevantes? Alguma forma de feedback ou orientação deve ser fornecida nesses casos?

⚪ [P2] Existem requisitos específicos de formatação ou apresentação para a saída gerada? A saída deve incluir algum metadado além da resposta da cadeia?

Dados

Determinar a natureza, a(s) fonte(s) e a qualidade dos dados que serão usados nas soluções do RAG.

🟢 [P0] Quais são as fontes disponíveis para uso?

Para cada fonte de dados:

• 🟢 [P0] Os dados são estruturados 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 de API)?

• 🟢 [P0] Onde esses dados residem?

• 🟢 [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] O senhor conhece algum problema ou inconsistência na qualidade dos dados de cada fonte de dados?

Considere a possibilidade de criar uma tabela de inventário para consolidar essas informações, por exemplo:

Origem de dados	Origem	Tipo (s) de arquivo	Tamanho	Frequência de atualização
fonte de dados 1	Unity Catalog volume	JSON	10 GB	Diariamente
fonte de dados 2	API pública	XML	NA (API)	Em tempo real
fonte de dados 3	SharePoint	PDF, .docx	500 MB	Mensal

Restrições de desempenho

Capturar os requisitos de desempenho e recurso para a aplicação do RAG.

🟡 [P1] Qual é a latência máxima aceitável para gerar as respostas?

🟡 [P1] Qual é o tempo máximo aceitável para os primeiros tokens?

🟡 [P1] Se a saída estiver sendo transmitida, a latência total mais alta é aceitável?

🟡 [P1] Há alguma limitação de custo no compute recurso disponível para inferência?

🟡 [P1] Quais são os padrões de uso e picos de carga esperados?

🟡 [P1] Quantos usuários ou solicitações de concorrente o sistema deve ser capaz de atender? Databricks lida nativamente com esses requisitos de escalabilidade, por meio da capacidade de escalonar automaticamente com o modelo de serviço.

Avaliação

Estabelecer como as soluções do RAG serão avaliadas e aprimoradas ao longo do tempo.

🟢 [P0] Qual é a meta de negócios ou KPI que você deseja impactar? Qual é o valor da linha de base e qual é a meta?

🟢 [P0] Quais usuários ou partes interessadas fornecerão feedback inicial e contínuo?

🟢 [P0] Quais métricas devem ser usadas para avaliar a qualidade das respostas geradas? O Mosaic AI Agent Evaluation 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ção]? É possível obter um conjunto de avaliação de consultas de usuários, junto com respostas verdadeiras e (opcionalmente) os documentos de apoio corretos que devem ser recuperados?

🟡 [P1] Como o feedback do usuário será coletado e incorporado ao sistema?

Segurança

Identifique quaisquer considerações de segurança e privacidade.

🟢 [P0] Existem dados confidenciais/confidenciais que precisam ser tratados com cuidado?

🟡 [P1] Os controles de acesso precisam ser implementados nas soluções (por exemplo, um determinado usuário só pode fazer a recuperação de um conjunto restrito de documentos)?

Implantação

Entender como as soluções da RAG serão integradas, implantadas e mantidas.

🟡 Como as soluções da RAG devem se integrar aos sistemas existentes e ao fluxo de trabalho?

🟡 Como o modelo deve ser implantado, dimensionado e versionado? Este tutorial aborda como o ciclo de vida de ponta a ponta pode ser tratado em Databricks usando MLflow, Unity Catalog, Agent SDK e servindo modelo.

Exemplo

Como exemplo, considere como essas perguntas se aplicam a este exemplo de aplicativo RAG usado por uma equipe de suporte ao cliente da Databricks:

Área	Considerações	Requisitos
Experiência do usuário	Modalidade de interação. Exemplos típicos de consultas de usuários. Formato e estilo de resposta esperados. Lidar com consultas ambíguas ou irrelevantes.	Interface de bate-papo integrada ao Slack. Exemplo de consultas: "Como faço para reduzir o tempo de cluster startup ?" "Que tipo de plano de suporte eu tenho?" Respostas técnicas e claras com trechos de código e links para a documentação relevante, quando apropriado. Forneça sugestões contextuais e encaminhe para os engenheiros de suporte quando necessário.
Dados	Número e tipo de fonte de dados. Formato e localização dos dados. Tamanho dos 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). Mensagens no fórum da comunidade (tabela Delta). Dados armazenados no Unity Catalog e atualizados semanalmente. Tamanho total dos dados: 5 GB. Estrutura de dados consistente e qualidade mantidas por documentos dedicados e equipes de suporte.
Desempenho	Latência máxima aceitável. Restrições de custo. Uso e simultaneidade esperados.	Requisito de latência máxima. Restrições de custo. Pico de carga esperado.
Avaliação	Avaliação dataset availability. Qualidade métrica. Coleta de feedback do usuário.	Os especialistas de cada área de produto ajudam a analisar os resultados e a ajustar as respostas incorretas para criar a avaliação dataset. KPIs de negócios. Aumento na taxa de resolução de tíquetes de suporte. Diminuição do tempo gasto pelo usuário por ticket de suporte. Qualidade métrica. Correção e relevância das respostas avaliadas pelo LLM. O LLM julga a precisão da recuperação. Voto positivo ou negativo do usuário. Coleta de feedback. O Slack será instrumentado para fornecer um polegar para cima/para baixo.
Segurança	Tratamento 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 Databricks.
Implantação	Integração com sistemas existentes. Implantação e controle de versão.	Integração com o sistema de tickets de suporte. Chain implantado como a Databricks servindo o modelo endpoint.

Próximo passo

Começar com o passo 1. Clonar o repositório de código e criar compute.