Arquitetura de engenharia da IA ​​e feedback do usuário

Arquitetura de engenharia da IA

Na sua forma mais simples, seu aplicativo recebe uma consulta e o envia para o modelo. O modelo gera uma resposta, que é retornada ao usuário. Não há aumento de contexto, sem proteções (guardrails) e otimização. A API do modelo refere-se tanto a APIs de terceiros (por exemplo, OpenAI, Google, Anthropic) quanto a modelos auto-hospedados.

A partir dessa arquitetura simples, você pode adicionar mais componentes conforme as necessidades. O processo pode parecer o seguinte:

1. Aprimore a entrada de contexto em um modelo, concedendo a ele acesso a fontes de dados externas e ferramentas para coleta de informações.
2. Crie proteções (guardrails) para proteger seu sistema e seus usuários.
3. Adicione roteador e gateway ao modelo para suportar pipelines complexos e aumentar a segurança.
4. Otimize a latência e os custos com cache.
5. Adicione lógica complexa e escreva ações para maximizar os recursos do seu sistema.

Etapa 1. Aprimore o contexto

A expansão inicial de uma plataforma geralmente envolve adicionar mecanismos para permitir que o sistema construa o contexto relevante necessário pelo modelo para responder a cada consulta. O contexto pode ser construído através de vários mecanismos de recuperação, incluindo recuperação de texto, recuperação de imagem e recuperação de dados tabulares. O contexto também pode ser aumentado usando ferramentas que permitem que o modelo colete automaticamente informações através de APIs como pesquisa na web, notícias, clima, eventos, etc.

Etapa 2. Adicione proteções (guardrails)

As proteções (guardrails) ajudam a mitigar riscos e proteger você e seus usuários. Elas devem ser colocados sempre que houver exposições aos riscos. Em geral, elas podem ser categorizadas como guardrails em torno de entradas e saídas.

Proteções de entrada

As proteções de entrada normalmente protegem contra dois tipos de riscos: vazamento de informações privadas para APIs externas e execução de prompts ruins que comprometam seu sistema.

O vazamento de informações privadas para APIs externas é um risco específico de usar APIs de modelo externas quando você precisa enviar seus dados para fora de sua organização.

Você pode usar uma das muitas ferramentas disponíveis que detectar automaticamente dados sensíveis.

Muitas ferramentas de detecção de dados sensíveis usam IA para identificar informações potencialmente sensíveis, como determinar se uma string se assemelha a um endereço válido de uma residência. Se uma consulta que contém informações confidenciais for encontrada, você terá duas opções: bloquear a consulta inteira ou remover as informações confidenciais

Proteções de saída

Um modelo pode falhar de várias maneiras diferentes. As proteções de saída têm duas funções principais:

• Detectar falhas de saída
• Especificar a política para lidar com diferentes modos de falha

Muitas falhas podem ser atenuadas pela lógica simples da re-tentativa. Os modelos de IA são probabilísticos, o que significa que, se você tentar uma consulta novamente, poderá obter uma resposta diferente. Por exemplo, se a resposta estiver vazia, tente novamente x vezes ou até obter uma resposta não vazia. Da mesma forma, se a resposta for mal formada, tente novamente até que a resposta seja formatada corretamente.

Implementação de proteção (guardrail)

As proteções carregam trade-offs. Uma é a confiabilidade versus latência. Enquanto reconhecem a importância das proteções, algumas equipes acreditam que a latência é mais importante. As equipes podem decidir não implementar as proteções porque elas podem aumentar significativamente a latência do aplicativo.

Proteções de saída pode não funcionar bem no modo de conclusão do fluxo.

Dados os muitos lugares diferentes em que um aplicativo pode falhar, as proteções podem ser implementadas em muitos níveis diferentes.

Devido à sobreposição de riscos em entradas e saídas, uma solução de proteção provavelmente fornecerá proteção para entradas e saídas.

Etapa 3. Adicione um roteador e gateway ao modelo

À medida que os aplicativos crescem para envolver mais modelos, os roteadores e gateways emergem para ajudá-los a gerenciar a complexidade e os custos de servir múltiplos modelos.

Roteador

Em vez de usar um modelo para todas as consultas, você pode ter soluções diferentes para diferentes tipos de consultas. Essa abordagem tem vários benefícios. Primeiro, ele permite modelos especializados, que podem ter um desempenho melhor do que um modelo de uso geral para consultas específicas. Segundo, isso pode ajudá-lo a economizar custos.

Um roteador normalmente consiste em um classificador de intenção que prevê o que o usuário está tentando fazer. Com base na intenção prevista, a consulta é roteada para a solução apropriada. Como exemplo, considere diferentes intenções relevantes para um chatbot de suporte ao cliente:

• Caso o usuário queira redefinir a senha, encaminhe-o para a página de perguntas frequentes sobre recuperação de senha.
• Caso a solicitação seja para corrigir um erro de cobrança, encaminhe-a para um operador humano.

Outros roteadores podem ajudar o modelo a decidir o que fazer a seguir. Por exemplo, para um agente capaz de várias ações, um roteador pode assumir a forma de um preditor de próxima ação: o modelo deve usar um intérprete de código ou uma API de pesquisa a seguir?

Classificadores de intenções e preditores de ação da próxima ação podem ser implementados no topo dos modelos de fundamento. Muitas equipes adaptam modelos de idiomas menores, como GPT-2, Bert e Llama 7B como seus classificadores de intenção. Muitas equipes optam por treinar classificadores ainda menores do zero. Os roteadores devem ser rápidos e baratos para que seja possível usar vários deles sem incorrer em latência e custo significativos.

Gateway

Um gateway de modelo é uma camada intermediária que permite que sua organização faça uma interface com diferentes modelos de maneira unificada e segura. A funcionalidade mais básica de um gateway de modelo é fornecer uma interface unificada a diferentes modelos, incluindo modelos de terceiros (chamados por API) e modelos auto-hospedados. Um gateway de modelo facilita a manutenção de seu código. Se uma API de modelo mudar, você só precisará atualizar o gateway em vez de atualizar todos os aplicativos que dependem desta API.

Um gateway de modelo fornece controle de acesso e gerenciamento de custos. Em vez de dar a todos que desejam acesso aos tokens de sua organização à API do OpenAi, que podem ser facilmente vazados, você dá às pessoas acesso apenas ao gateway do modelo, criando um ponto de acesso centralizado e controlado. O gateway também pode implementar controles de acesso de granularidade fina, especificando qual usuário ou aplicativo deve ter acesso a qual modelo. Além disso, o gateway pode monitorar e limitar o uso de chamadas de API, impedindo o abuso e gerenciando os custos de maneira eficaz.

Um gateway do modelo também pode ser usado para implementar políticas de fallback para superar os limites da taxa ou as falhas da API (o último é infelizmente comum). Quando a API primária não está disponível, o gateway pode rotear solicitações para modelos alternativos, tentar novamente após uma curta espera ou lidar com falhas graciosamente de outras maneiras.

Etapa 4. Reduza a latência com caches

O cache há muito tempo é parte integrante de aplicativos de software para reduzir a latência e o custo. Muitas idéias do cache de software podem ser usadas para aplicações de IA.

Cache exato

Com o cache exato, os itens em cache são usados ​​apenas quando esses itens exatos são solicitados.

O cache exato também é usado para a recuperação baseada em embeddings para evitar a pesquisa vetorial redundante. Se uma consulta recebida já estiver no cache de pesquisa do vetor, busque o resultado em cache. Caso contrário, execute uma pesquisa vetorial por esta consulta e adicione o resultado ao cache.

O cache é especialmente atraente para consultas que envolvem várias etapas (por exemplo, cadeia de pensamento) e/ou ações demoradas (por exemplo, recuperação, execução de SQL ou pesquisa na web).

Um cache exato pode ser implementado usando o armazenamento na memória para recuperação rápida. No entanto, como o armazenamento na memória é limitado, um cache também pode ser implementado usando bancos de dados como PostgreSQL, Redis ou armazenamento em camadas para equilibrar a velocidade e a capacidade de armazenamento.

Quanto ao tempo a manter uma consulta no cache, depende da probabilidade dessa consulta a ser chamada novamente. Consultas específicas do usuário, como “Qual é o status do meu pedido recente?”, são menos prováveis de serem reutilizadas por outros usuários e, portanto, não devem ser armazenado em cache.

Cache semântico

Diferentemente do cache exato, os itens em cache são usados, mesmo que sejam apenas semanticamente semelhantes, não idênticos, à consulta recebida. Reutilizar consultas semelhantes aumenta a taxa de acerto do cache e potencialmente reduz o custo. No entanto, o cache semântico pode reduzir o desempenho do seu modelo.

O cache semântico funciona apenas se você tiver uma maneira confiável de determinar se duas consultas são semelhantes. Uma abordagem comum é usar similaridade semântica. Como uma atualização, a similaridade semântica funciona da seguinte maneira:

1. Para cada consulta, gera sua incorporação usando um modelo de incorporação.
2. Usa a pesquisa vetorial para encontrar o embedding em cache com a maior pontuação semelhante ao embedding da consulta atual. Digamos que a pontuação dessa semelhança seja X.
3. Se X for maior que um determinado limite de similaridade, a consulta armazenada em cache será considerada semelhante e os resultados armazenados em cache serão retornados. Caso contrário, processe a consulta atual e armazene-a em cache, juntamente com sua incorporação e resultados.

Essa abordagem requer um banco de dados vetorial para armazenar os embeddings de consultas em cache.

Comparado a outras técnicas de armazenamento em cache, o valor da semântica em cache é mais duvidoso porque muitos de seus componentes são propensos a falhas.

Além disso, o cache semântico pode ser demorado e intensivo em computação, pois envolve uma pesquisa vetorial. A velocidade e o custo desta pesquisa vetorial dependem do tamanho de suas incorporações em cache.

Etapa 5. Adicione padrões de agente

Os aplicativos discutidos até agora ainda são bastante simples. Cada consulta segue um fluxo seqüencial. No entanto, um fluxo de aplicação pode ser mais complexo com loops, execução paralela e ramificação condicional. Padrões agênticos podem ajudá-lo a criar aplicativos complexos.

Se você seguiu todas as etapas até agora, sua arquitetura provavelmente cresceu bastante complexa. Enquanto sistemas complexos podem resolver mais tarefas, eles também introduzem mais modos de falha, tornando-os mais difíceis de depurar devido aos muitos pontos potenciais de falha. A próxima seção cobrirá melhor as práticas para melhorar a observabilidade do sistema.

Monitoramento e observabilidade

A observabilidade é uma prática universal em todas as disciplinas de engenharia de software. É uma grande indústria com práticas recomendadas estabelecidas e muitas soluções proprietárias e de código aberto prontas para uso.

O objetivo do monitoramento é o mesmo que o objetivo da avaliação: mitigar riscos e descobrir oportunidades. Riscos que o monitoramento deve ajudá-lo a mitigar incluem falhas de aplicação, ataques de segurança e desvios. O monitoramento pode ajudar a descobrir oportunidades de melhoria de aplicativos e economia de custos. O monitoramento também pode ajudar a mantê-lo responsável, dando visibilidade ao desempenho do seu sistema.

Três métricas podem ajudar a avaliar a qualidade da observabilidade do seu sistema, derivada da comunidade DevOps:

• MTTD (mean time to detection – tempo médio para detecção): Quando algo ruim acontece, quanto tempo leva para detectá-lo?
• MTTR (mean time to response – tempo médio de resposta): Após a detecção, quanto tempo leva para ser resolvido?
• CFR (change failure rate – taxa de falha nas mudanças): A porcentagem de alterações ou implantações que resultam em falhas que exigem correções ou reversões.

Métricas

Como os modelos de fundamento podem gerar saídas abertas, existem muitas maneiras pelas quais as coisas podem dar errado. O design das métricas requer pensamento analítico, conhecimento estatístico e, muitas vezes, criatividade. Quais métricas você deve rastrear são altamente específicas de aplicativos.

Os tipos de falhas mais fáceis de rastrear são as falhas de formato, porque são fáceis de observar e verificar. Por exemplo, se você espera saídas de JSON, acompanhe a frequência com que o modelo gera JSON inválidos.

Para gerações abertas, considere monitorar a consistência factual e as métricas de qualidade de geração relevantes, como concisão, criatividade, ou positividade.

Se a segurança for um problema, você pode rastrear métricas relacionadas à toxicidade e detectar informações privadas e sensíveis em entradas e saídas.

As métricas relacionadas ao comprimento também são importantes para rastrear a latência e os custos.

Rastrear latência é essencial para entender a experiência do usuário. Métricas de latência comum, já discutidas, incluem:

• Tempo até o primeiro token (TTFT): o tempo que leva para o primeiro token ser gerado.
• Tempo por token de saída (TPOT): o tempo que leva para gerar cada token de saída.
• Latência total: o tempo total necessário para concluir uma resposta.

Você também deseja rastrear custos. Métricas relacionadas a custos são o número de consultas e o volume de tokens de entrada e saída, como tokens por segundo (TPS).

Logs and traces

As métricas são tipicamente agregadas. Eles condensam informações de eventos que ocorrem no seu sistema ao longo do tempo.

Se as métricas são medições numéricas que representam atributos e eventos, os logs são um registro incremental de eventos. Na produção, um processo de depuração pode ser assim:

1. As métricas informam que algo deu errado há cinco minutos, mas não informam o que aconteceu.
2. Você analisa os registros de eventos que ocorreram há cerca de cinco minutos para descobrir o que aconteceu.
3. Correlacione os erros nos registros às métricas para garantir que você identificou o problema correto.

Para detecção rápida, as métricas precisam ser calculadas rapidamente. Para uma resposta rápida, os logs precisam estar prontamente disponíveis e acessíveis. Se seus logs estiverem 15 minutos atrasados, você terá que esperar que os logs chegarem para rastrear um problema que aconteceu há 5 minutos.

Como você não sabe exatamente quais logs precisarão examinar no futuro, a regra geral é registrar tudo. Registre as configurações, incluindo o endpoint da API do modelo, nome do modelo, configurações de amostragem (temperatura, top-p, top-k, condição de parada, etc.) e modelo do prompt.

Registre a consulta do usuário, o prompt final enviado ao modelo, à saída final e as saídas intermediárias. Registre se chamar alguma ferramenta. Registre as saídas da ferramenta. Registre quando um componente começa, termina, quando algo trava, etc. Ao gravar um pedaço de log, certifique-se de atribuir tags e IDs que podem ajudar você a saber de onde vem esse log no sistema.

Registrar tudo significa que a quantidade de logs que você tem pode crescer muito rapidamente. Muitas ferramentas para análise de log automatizada e anomalia de log são alimentadas por IA.

Embora seja impossível processar registros manualmente, é útil inspecionar manualmente seus dados de produção diariamente para ter uma noção de como os usuários estão usando seu aplicativo.

Se os registros são uma série de eventos desconexos, os traces são reconstruídos pela ligação de eventos relacionados para formar uma linha do tempo completa de uma transação ou processo, mostrando como cada etapa se conecta do início ao fim. Em resumo, um trace (rastreamento) é a gravação detalhada do caminho de execução de uma solicitação por meio de vários componentes e serviços do sistema.

Orquestração de pipeline de IA

Um aplicativo de IA pode ficar bastante complexo, consistindo em vários modelos, recuperando dados de muitos bancos de dados e tendo acesso a uma ampla gama de ferramentas. Um orquestrador ajuda a especificar como esses diferentes componentes funcionam juntos para criar um pipeline de ponta a ponta. Ele garante que esses dados fluam perfeitamente entre os componentes. Em um nível alto, um orquestrador opera em duas etapas, definição de componentes e encadeamento:

• Definição dos componentes: você precisa dizer ao orquestrador quais componentes seu sistema usa, incluindo diferentes modelos, dados externos, fontes de recuperação e ferramentas que seu sistema pode usar.
• Encadeamento: Encadeamento é basicamente composição de funções: combina diferentes funções (componentes). No encadeamento (pipelining), você informa ao orquestrador as etapas que o seu sistema percorre desde o recebimento da consulta do usuário até a conclusão da tarefa.

O orquestrador é responsável por passar dados entre componentes. Ele deve fornecer ferramentas que ajudem a garantir que a saída da etapa atual está no formato esperado pela próxima etapa.

Embora seja tentador pular direto para uma ferramenta de orquestração ao iniciar um projeto, convém começar a criar seu aplicativo sem uma inicialmente. Qualquer ferramenta externa traz complexidade adicional. Um orquestrador pode abstrair detalhes críticos de como seu sistema funciona, tornando difícil entendê-lo e depurá-lo.

Ao avançar para os estágios posteriores do seu processo de desenvolvimento de aplicativos, você pode decidir que um orquestrador pode facilitar sua vida. Aqui estão três aspectos a serem lembrados ao avaliar orquestradores:

• Integração e extensibilidade
• Suporte para pipelines complexos
• Facilidade de uso, desempenho e escalabilidade

Feedback do usuário

O feedback do usuário sempre desempenhou um papel crítico nos aplicativos de software de duas maneiras principais: avaliar o desempenho do aplicativo e informar seu desenvolvimento. No entanto, em aplicativos de IA, o feedback do usuário assume um papel ainda mais significativo. O feedback do usuário consiste em dado proprietário, e dados são uma vantagem competitiva. Um sistema de feedback de usuário bem projetado é necessário para criar o ciclo de dados já discutido.

O feedback do usuário pode ser usado não apenas para personalizar modelos para usuários individuais, mas também para treinar iterações futuras dos modelos. Visto que os dados tornam-se cada vez mais escassos, os dados proprietários são mais valiosos do que nunca. Um produto que é lançado rapidamente e atrai os usuários mais cedo pode reunir dados para melhorar continuamente os modelos, dificultando a atualização dos concorrentes.

Extraindo feedback conversacional

Tradicionalmente, o feedback pode ser explícito ou implícito. Feedback explícito é a informação que os usuários provêem em resposta a solicitações explícitas de feedback em um aplicativo.

Feedback implícito é a informação inferida a partir das ações do usuário. Por exemplo, se alguém compra um produto recomendado a ele, significa que foi uma boa recomendação.

O feedback do usuário, extraído de conversas, pode ser usado para avaliação, desenvolvimento e personalização:

• Avaliação: derivar métricas para monitorar o aplicativo
• Desenvolvimento: treinar os modelos futuros ou orientar seu desenvolvimento
• Personalização: personalizar o aplicativo para cada usuário

Feedback da linguagem natural

O feedback extraído do conteúdo das mensagens é chamado de feedback em linguagem natural. Aqui estão alguns sinais de feedback em linguagem natural que indicam como uma conversa está indo.

Término antecipado
Se um usuário encerra uma resposta prematuramente, por exemplo, interrompendo a geração de uma resposta no meio do caminho ou saindo do aplicativo, é provável que a conversa não esteja indo bem.

Correção de erros
Se um usuário inicia seu acompanhamento com “Não, …” ou “Eu quis dizer, …”, a resposta do modelo provavelmente está equivocada.

Reclamações
Muitas vezes, os usuários apenas reclamam dos resultados do seu aplicativo sem tentar corrigi-los. Por exemplo, eles podem reclamar que uma resposta está errada, é irrelevante, tóxica, longa, carente de detalhes ou simplesmente ruim.

Sentimento
Reclamações também podem ser expressões gerais de sentimentos negativos (frustração, decepção, ridículo, etc.) sem explicar o motivo, como “Ugh”. Isso pode parecer distópico, mas a análise dos sentimentos de um usuário ao longo de conversas com um bot pode fornecer insights sobre o desempenho do bot.

Regeneração
Muitos aplicativos permitem que os usuários gerem outra resposta, às vezes com um modelo diferente. Se um usuário optar pela regeneração, pode ser porque não está satisfeito com a primeira resposta. No entanto, também pode ser que a primeira resposta seja adequada, mas o usuário queira opções para comparar. Isso é especialmente comum com solicitações criativas, como geração de imagens ou histórias.

Organização da conversa
As ações que um usuário realiza para organizar suas conversas — como excluir, renomear, compartilhar e marcar como favoritas — também podem ser sinais. Excluir uma conversa é um sinal bastante forte de que ela é ruim.

Duração da conversa
Outro sinal comumente rastreado é o número de turnos por conversa. Se este é um sinal positivo ou negativo depende do aplicativo. Para companheiros de IA, uma conversa longa pode indicar que o usuário está gostando da conversa.

Design de feedback

Quando coletar feedback

O feedback pode e deve ser coletado ao longo da jornada do usuário. Os usuários devem ter a opção de fornecer feedback, especialmente para relatar erros, sempre que necessário.

No início
Quando um usuário acaba de se cadastrar, o feedback pode ajudar a calibrar o aplicativo para ele.

Quando algo ruim acontece
Quando o modelo alucina em uma resposta, bloqueia uma solicitação legítima, gera uma imagem comprometedora ou demora muito para responder, os usuários devem poder notificá-lo sobre essas falhas. Você pode dar aos usuários a opção de rejeitar uma resposta, regenerar com o mesmo modelo ou mudar para outro modelo.

O ideal é que, quando seu produto comete erros, os usuários ainda consigam realizar suas tarefas. Por exemplo, se o modelo categorizar um produto incorretamente, os usuários podem editar a categoria.

Quando o modelo tem baixa confiança
Quando um modelo está incerto sobre uma ação, você pode pedir feedback ao usuário para aumentar sua confiança.

Você pode se perguntar: e quanto ao feedback quando algo bom acontece? As ações que os usuários podem realizar para expressar sua satisfação incluem curtir, favoritar ou compartilhar.

Como coletar feedback

O feedback deve se integrar perfeitamente ao fluxo de trabalho do usuário. Deve ser fácil para os usuários fornecerem feedback sem trabalho extra. A coleta de feedback não deve atrapalhar a experiência do usuário e deve ser fácil de ignorar. Deve haver incentivos para que os usuários deem um bom feedback.

O feedback por si só pode ser útil para análises de produtos. Por exemplo, ver apenas as informações de curtidas/não curtidas é útil para calcular a frequência com que as pessoas estão satisfeitas ou insatisfeitas com seu produto. Para uma análise mais aprofundada, no entanto, você precisaria de contexto em torno do feedback, como os 5 a 10 diálogos anteriores. Esse contexto pode ajudar a descobrir o que deu errado. No entanto, obter esse contexto pode não ser possível sem o consentimento explícito do usuário, especialmente se o contexto contiver informações de identificação pessoal.

Por esse motivo, alguns produtos incluem termos em seus contratos de serviço que permitem o acesso aos dados do usuário para análises e aprimoramento do produto.

Limitações do Feedback

Não há dúvidas sobre o valor do feedback do usuário para um desenvolvedor de aplicativos. No entanto, o feedback não é um almoço grátis. Ele tem suas próprias limitações.

Vieses

Como qualquer outro dado, o feedback do usuário tem vieses. É importante entender esses vieses e projetar seu sistema de feedback em torno deles. Cada aplicativo tem seus próprios vieses. Aqui estão alguns exemplos de vieses de feedback para lhe dar uma ideia do que procurar.

Viés de leniência
Viés de leniência é a tendência das pessoas a avaliarem itens de forma mais positiva do que o necessário, muitas vezes para evitar conflitos porque se sentem compelidas a serem gentis ou porque é a opção mais fácil.

Aleatoriedade
Os usuários geralmente fornecem feedback aleatório, não por maldade, mas porque não têm motivação para dar uma contribuição mais ponderada.

Viés de posição
A posição em que uma opção é apresentada aos usuários influencia a forma como essa opção é percebida. Os usuários geralmente são mais propensos a clicar na primeira sugestão do que na segunda. Se um usuário clicar na primeira sugestão, isso não significa necessariamente que seja uma boa sugestão.

É importante analisar o feedback do usuário para descobrir seus vieses. Compreender esses vieses ajudará você a interpretar o feedback corretamente, evitando decisões enganosas sobre o produto.

Referências

Huyen, Chip. AI Engineering: Building Applications with Foundation Models