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 têm duas finalidades principais. Em primeiro lugar, eles ajudam a determinar se o RAG é a abordagem mais adequada para um determinado caso de uso. 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. Os requisitos bem definidos fornecem a base para os estágios subsequentes do ciclo de vida de desenvolvimento que iremos analisar.

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 o senhor precisa estabelecer é se o RAG é mesmo a abordagem certa para o seu caso de uso. Dado o hype em torno do RAG, é tentador view como uma possível solução para qualquer problema. No entanto, há 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 a melhor opção 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

• São necessárias respostas de latência extremamente baixa (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 que o senhor determinar que o RAG é adequado para o seu caso de uso, considere as seguintes perguntas para captar requisitos concretos. Os requisitos são priorizados da seguinte forma:

🟢 P0: O senhor deve definir esse requisito antes de iniciar sua POC.

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

P2: É bom ter esse requisito.

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

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

🟢 [P0] Como será 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 vão interagir 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 ter? (formal, conversacional, técnico?)

🟡 [P1] Como o aplicativo deve lidar com consultas ambíguas, incompletas ou irrelevantes? O senhor deve fornecer alguma forma de feedback ou orientação nesses casos?

⚪ [P2] Há requisitos específicos de formatação ou apresentação para o resultado gerado? O resultado 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 estão 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] 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 comercial / KPI que o senhor 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 do usuário, juntamente 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

Identificar 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 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. Tratamento de 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 claras e técnicas 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 mantida por equipes dedicadas de documentação e 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 da taxa de resolução de tíquetes de suporte. Diminuição do tempo gasto pelo usuário por tíquete de suporte. Qualidade métrica. Correção e relevância das respostas avaliadas pelo LLM. O LLM julga a precisão da recuperação. O usuário pode votar a favor ou contra. Coleta de feedback. O Slack será instrumentado para fornecer um polegar para cima/para baixo.
Segurança	Manuseio 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. Implementação e controle de versão.	Integração com o sistema de tíquetes 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.