Amazon
Web Services
Microsoft Azure
Google Cloud PlatformPré-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 senhor também pode usar o código do repositório como um padrão para criar seus próprios aplicativos AI.
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 |
|
|
Dados |
|
|
Desempenho |
|
|
Avaliação |
|
|
Segurança |
|
|
Implantação |
|
|