O principal desafio no design de arquitetura de IA não é a falta de opções, mas o excesso delas sem uma metodologia sistemática de tomada de decisão. Quando uma empresa decide criar uma aplicação de IA, ela não enfrenta uma única decisão, mas uma série de escolhas interconectadas: qual modelo usar? Como implantá-lo? Como organizar os dados? Como orquestrar os agentes? Construir ou comprar? Cada escolha impacta as decisões subsequentes, e muitas são difíceis de reverter.
Essas árvores de decisão são interdependentes e não devem ser usadas de forma isolada. Este capítulo apresenta cinco árvores de decisão sistemáticas para ajudar os arquitetos a fazer escolhas baseadas em evidências em momentos críticos da arquitetura de IA. A estratégia de modelo determina o espaço de seleção para a arquitetura de inferência. A arquitetura de dados afeta a viabilidade da estratégia de modelo, e a arquitetura de agentes se baseia na combinação das três primeiras. Por fim, a decisão de construir versus comprar restringe todas as escolhas técnicas sob as perspectivas econômica e organizacional.
Árvore de decisão 1: Estratégia de modelo
A estratégia de modelo é a decisão mais fundamental na arquitetura de IA, pois determina o teto de capacidade do sistema, a linha de base de custos e a complexidade operacional. Os arquitetos devem responder a três perguntas sequenciais: qual modelo usar? Como personalizar o modelo? Como combinar os modelos?
API vs. modelos auto-hospedados
A primeira decisão é chamar um modelo hospedado na cloud via API ou baixá-lo e execute em sua própria infraestrutura.
Escolher um modelo de API na plataforma Model Studio (Bailian), como a série Tongyi Qianwen, oferece zero de sobrecarga operacional, pagamento conforme o uso e atualizações automáticas do modelo. Essa abordagem é adequada quando a sensibilidade dos dados é moderada (a transmissão criptografada é suficiente para conformidade) e a latência na ordem de segundos é aceitável. Também se aplica quando não são necessárias modificações profundas no comportamento do modelo e a carga de trabalho do negócio ainda não atingiu o ponto de inflexão em que os custos fixos de GPU se tornam mais econômicos.
Optar por implantar um modelo de código aberto, como o Qwen3-72B, no PAI-EAS oferece controle total dos dados, otimizações de inferência personalizáveis e possíveis vantagens de custo em escala. A auto-hospedagem é preferível se:
O modelo precisa processar dados classificados como informações pessoais sensíveis sob a Lei de Proteção de Informações Pessoais (PIPL) e não pode sair da rede corporativa.
Requisitos rigorosos de latência exigem otimização de baixo nível do motor de inferência.
Suas necessidades extensas de personalização do modelo, como vocabulários personalizados ou estratégias de decodificação especiais, excedem a flexibilidade dos modelos de API.
Seu volume diário de chamadas ultrapassa um limite em que o custo fixo das GPUs se torna menor que o pagamento conforme o uso.
Fine-tuning, RAG e engenharia de prompts
Após determinar a source do modelo, a próxima decisão é como adaptar um modelo de uso geral a um cenário de negócios específico. Os três principais métodos de personalização têm suas condições ideais:
A engenharia de prompts tem o menor custo inicial e a maior velocidade de iteração. Ao projetar cuidadosamente os prompts do sistema, construir exemplos few-shot e usar técnicas como chain of thought, é possível melhorar significativamente o desempenho do modelo nas tarefas-alvo. Isso é adequado quando a tarefa pode ser claramente descrita em linguagem natural, o conhecimento público é suficiente para garantir a qualidade da resposta e a lógica de negócios muda com frequência, exigindo ajustes rápidos. Na plataforma Model Studio (Bailian), é possível iterar rapidamente e realizar testes A/B de prompts por meio da interface de configure do aplicativo.
A geração aumentada por recuperação (RAG) se baseia na engenharia de prompts ao introduzir a recuperação de conhecimento externo. O RAG é adequado quando: o modelo precisa acessar conhecimento privado da empresa (como documentação de product, políticas internas ou dados de clientes); o conhecimento é atualizado com frequência (como uma lista de preços de product semanal); ou as respostas devem ser rastreáveis até suas source (citando documentos e parágrafos específicos). O recurso de base de conhecimento no Model Studio (Bailian) fornece um pipeline de RAG de ponta a ponta — desde o upload de documentos e fragmentação automática até a vetorização, armazenamento e recuperação — reduzindo a barreira de entrada para a construção de sistemas RAG.
Use o fine-tuning de modelo quando a engenharia de prompts e o RAG não conseguirem atender aos seus requisitos. É ideal quando: o modelo precisa aprender um novo estilo de voz ou terminologia especializada (como um formato específico de documento jurídico); o modelo deve concluir uma tarefa em poucos tokens que, de outra forma, exigiria prompts longos (reduzindo os custos de execução); ou os critérios de avaliação são altamente subjetivos e devem ser aprendidos a partir de grandes volumes de dados de preferência humana. A plataforma PAI suporta tanto o fine-tuning de parâmetros completos quanto métodos eficientes em parâmetros como o LoRA, fornecendo uma toolchain completa para gerenciamento de dados de treinamento e avaliação de modelo.
Na prática, esses três métodos costumam ser usados em combinação. Uma progressão típica é usar primeiro a engenharia de prompts para validar rapidamente a viabilidade, depois adicionar o RAG para incorporar o conhecimento corporativo e, por fim, usar o fine-tuning para os cenários principais a fim de melhorar a consistência. Com o DataWorks, gerencie fluxos de trabalho de pré-processamento de dados no pipeline de RAG, garantindo a qualidade e a atualização da base de conhecimento.
Modelo único, roteamento de modelos e ensemble de modelos
A dimensão final da estratégia de modelo é a abordagem de combinação:
A abordagem de modelo único é a mais simples: selecione um modelo altamente capaz para lidar com todas as solicitações. Isso é adequado para cenários de negócios de propósito único, complexidade de solicitação uniforme e situações em que o custo não é a restrição principal. Por exemplo, um assistente de análise estratégica para executivos internos pode ter um baixo volume de solicitações, mas exigir qualidade extremamente alta, tornando um único modelo Qwen-Max suficiente.
O roteamento de modelos é valioso quando a complexidade das solicitações é desigual. Um padrão típico envolve um classificador leve (motor de regras, modelo pequeno ou algoritmo heurístico) responsável por rotear as solicitações para diferentes modelos com base em suas características. Por exemplo, é possível rotear chats simples para o Qwen-Flash, perguntas padrão que exigem RAG para o Qwen-Plus e solicitações de raciocínio complexo para o Qwen-Max. Os fluxos de trabalho do Model Studio (Bailian) orquestram essa lógica de roteamento e registram as decisões para otimização futura.
Um ensemble de modelos é usado quando a precisão da decisão é primordial. Vários modelos geram respostas de forma independente para a mesma solicitação, e a saída final é determinada por votação, fusão ponderada ou uma verificação de consistência. Isso é adequado para cenários com tolerância a falhas extremamente baixa, como controle de risco financeiro ou assistência de diagnóstico médico. A contrapartida é um aumento multiplicativo no custo e na latência. Na prática, um consenso de dois modelos menores às vezes pode substituir um único modelo massivo, alcançando uma melhor relação custo-benefício em determinados cenários.
Matriz de trade-off
Os principais trade-offs na estratégia de modelo podem ser analisados em quatro dimensões:
Latência: os modelos de API geralmente têm sobrecarga de rede (50-200ms). É possível otimizar modelos auto-hospedados para latência extremamente baixa, mas isso exige investimento operacional. Modelos maiores têm inferência mais lenta, mas arquiteturas como mixture of experts (MoE) podem manter os recursos de modelos grandes enquanto controlam a sobrecarga de inferência.
Custo: as APIs são faturadas por token, portanto, os custos escalam linearmente com o uso, o que é ideal para cargas de trabalho flutuantes. A auto-hospedagem é faturada por tempo de GPU, o que envolve um custo fixo, mas custos marginais baixos, sendo adequada para cargas de trabalho estáveis e de alto volume. O fine-tuning adiciona um custo único de treinamento, mas pode reduzir o consumo de tokens em tempo de execução ao permitir que as tarefas sejam concluídas com prompts mais curtos.
Qualidade: modelos com mais parâmetros geralmente oferecem melhor qualidade, mas não para todas as tarefas. Um modelo menor com fine-tuning pode superar um modelo grande de uso geral em uma tarefa vertical específica. O RAG melhora significativamente a precisão factual, mas aumenta a complexidade do sistema.
Privacidade de dados: com modelos de API, os dados saem do limite da empresa (mesmo que criptografados em trânsito). Com modelos auto-hospedados, os dados nunca saem da sua rede. O fine-tuning exige o upload de dados de treinamento para uma plataforma de treinamento (o PAI suporta treinamento dentro de uma VPC para reduzir o risco). Para o RAG, avalie a conformidade do local de armazenamento dos dados da sua base de conhecimento.
Reavalie sua estratégia de modelo quando: os custos da API do modelo excederem o orçamento em mais de 20% por três meses consecutivos; uma nova geração de modelos oferecer uma melhoria de preço-desempenho superior a 50%; os requisitos de privacidade de dados aumentarem devido a atualizações regulatórias; ou a equipe de operações de auto-hospedagem não conseguir acompanhar os patches de segurança.
Árvore de decisão 2: Arquitetura de inferência
Depois que um modelo é escolhido, a próxima decisão chave é como implantar e executar o service de inferência do modelo. A arquitetura de inferência determina diretamente a velocidade de resposta, a escalabilidade, a disponibilidade e o custo operacional do sistema.
Serverless, GPU dedicada e implantação híbrida
A inferência Serverless significa confiar totalmente as chamadas de modelo a uma plataforma cloud sem provisionar ou gerencie instâncias de GPU. Ao acionar chamadas de API por meio do Function Compute (FC) ou usar os service de inferência gerenciados no Model Studio (Bailian), é possível evitar o gerenciamento do fornecimento, do agendamento e das operações de GPU subjacentes. As vantagens são o pagamento conforme o uso com custo zero de ociosidade, dimensionamento automático para lidar com picos de tráfego e zero de carga operacional para a disponibilidade do service. Essa abordagem é adequada para cargas de trabalho com alta volatilidade de tráfego (picos 10 vezes ou mais maiores que os vales) e tolerância a possível latência de cold-start (a primeira solicitação pode levar de 1 a 3 segundos extras). Também se aplica quando não há necessidade de personalização de motor de inferência de baixo nível.
A implantação de GPU dedicada (via PAI-EAS) significa reservar um conjunto de instâncias de GPU exclusivamente para o seu service de inferência de modelo. Essa abordagem proporciona controle total sobre a configuração do motor de inferência, permitindo otimizações ajustadas como tamanho de lote, estratégias de quantização, gerenciamento de cache KV e decodificação especulativa. É adequada para tráfego estável e de grande escala onde a utilização da GPU pode ser mantida acima de 60%; requisitos extremos de latência que exigem otimização no nível de milissegundos; uso de modelos personalizados ou com fine-tuning que não estão na lista padrão de modelos do DashScope; ou requisitos de segurança que exigem a execução do modelo dentro de uma VPC dedicada.
Uma estratégia de implantação híbrida combina as vantagens de ambas. O tráfego de linha de base é lidado por instâncias de GPU dedicadas (mantendo 70-80% de utilização), enquanto picos repentinos de tráfego transbordam para a inferência Serverless como um fallback baseado em API. Essa arquitetura é especialmente útil para cenários com padrões de tráfego previsíveis, mas picos extremamente altos, como promoções de e-commerce. O PAI-EAS suporta políticas de dimensionamento elástico que dimensionam automaticamente as instâncias de GPU com base na profundidade da fila, mas essa velocidade de dimensionamento (minutos) é mais lenta que a do Serverless (segundos). Um fallback Serverless é, portanto, necessário para lidar com picos repentinos de tráfego.
Streaming em tempo real, processamento em lote e filas assíncronas
O modelo de execução de inferência depende dos requisitos de tempestividade do cenário de negócios:
O streaming em tempo real é para cenários interativos onde o usuário está aguardando uma resposta de IA e espera um efeito de "máquina de escrever" com geração palavra por palavra. O Model Studio (Bailian) suporta nativamente Server-Sent Events (SSE) para respostas em streaming. As principais considerações arquiteturais incluem implementar a lógica de renderização de streaming no cliente, usar um balanceador de carga com suporte a conexões de longa duração e definir uma política de timeout considerando o tempo total para gerar textos longos (podendo exceder 30 segundos). No modo de streaming, o tempo até o primeiro token (TTFT) é uma métrica chave de experiência do usuário e geralmente deve ser mantido abaixo de um segundo.
O processamento em lote é para tarefas offline que não são sensíveis ao tempo, como resumo de documentos em grande escala, rotulagem de dados históricos ou geração de relatórios periódicos. O Model Studio (Bailian) fornece uma API de inferência em lote que suporta o envio de grandes listas de solicitações e a recuperação de resultados de forma assíncrona. As vantagens incluem custos reduzidos pelo uso de recursos de computação de baixa prioridade (como instâncias preemptíveis), throughput melhorado pelo compartilhamento do cache KV entre solicitações e otimizações de agendamento global pela plataforma. O DataWorks orquestra jobs de inferência em lote para gatilhos agendados e gerenciamento de dependências.
Uma fila assíncrona é para tarefas de IA orientadas por fluxo de trabalho onde o usuário envia uma solicitação, mas não precisa de um resultado imediato, recebendo em vez disso uma notificação quando o resultado estiver pronto. Por exemplo, um usuário faz o upload de um contrato de 100 páginas para revisão por IA; o sistema aceita a solicitação, retorna um ID de tarefa e notifica o usuário após a conclusão. O padrão arquitetural geralmente envolve um frontend que envia solicitações para uma fila de mensagens (como o RocketMQ). Em seguida, um consumidor recupera as solicitações para chamar o modelo, grava os resultados no armazenamento e envia uma notificação final ao usuário. Esse padrão desacopla o recebimento da solicitação do processamento, permitindo que o sistema consuma a fila no seu próprio ritmo e suavize naturalmente os picos de tráfego.
Inferência de região única, multirregião e no dispositivo
A estratégia de implantação geográfica envolve o equilíbrio entre conformidade de dados, experiência do usuário e robustez do sistema:
A implantação de região única é a solução mais simples. Se seus usuários e dados estiverem localizados na China continental, implantar o service de inferência de IA em uma região principal é suficiente. Os service do Model Studio (Bailian) nas regiões da China continental cobrem a maioria dos cenários domésticos. As vantagens são uma arquitetura simples, residência de dados dentro da região e sobrecarga operacional mínima.
A implantação multirregião é adequada para dois casos: operações globais com necessidade de atender usuários a partir de uma região próxima para reduzir a latência de rede (por exemplo, usando a região China (Beijing) para usuários domésticos e a região Singapore para usuários do Sudeste Asiático) e requisitos de alta disponibilidade com exigência de recuperação de desastres no nível da região. Os desafios da implantação multirregião incluem a sincronização entre regiões de modelos e bases de conhecimento, estratégias de roteamento de solicitações de usuários e requisitos regulatórios diferentes (como o GDPR da UE versus a PIPL da China). No PAI-EAS, é possível implantar service de modelo de forma independente em várias regiões e usar o Global Accelerator ou roteamento baseado em DNS para fornecer acesso à região mais próxima.
A inferência no dispositivo (ou inferência de borda) implanta modelos pequenos em dispositivos de usuário final ou nós de borda. Isso é adequado para ambientes offline com redes não confiáveis (como minas ou navios), interações em tempo real com requisitos de latência extremamente baixa (como assistentes de voz em AR/VR) e cenários de alta sensibilidade onde os dados nunca devem sair do dispositivo (como assistência de diagnóstico local em equipamentos médicos). Os modelos no dispositivo são geralmente versões menores (como Qwen3-0,6B ou Qwen3-4B) com recursos limitados, mas respostas extremamente rápidas. Uma arquitetura híbrida permite que um modelo no dispositivo lide com solicitações simples e encaminhe as complexas para a cloud quando uma rede estiver disponível.
Planejamento de capacidade
A escolha da arquitetura de inferência pode ser inicialmente orientada pelo volume de solicitações:
Menos de 10.000 solicitações por dia: use o modo Serverless (chamadas diretas de API para o Model Studio (Bailian)). Nenhum recurso dedicado é necessário, e os custos escalam elasticamente com o uso. Isso é adequado para aplicações de IA em estágio inicial e ferramentas internas.
De 10.000 a 1 milhão de solicitações por dia: avalie o ponto de equilíbrio de custo entre Serverless e GPU dedicada. Se a distribuição de solicitações for relativamente uniforme, o custo por solicitação das GPUs dedicadas (PAI-EAS) pode ser menor. Se houver picos e vales significativos, o Serverless costuma ser a escolha mais econômica. Nesta fase, recomenda-se construir um sistema de monitoramento de desempenho para rastrear as distribuições de latência P50, P95 e P99.
Mais de 1 milhão de solicitações por dia: uma implantação de GPU dedicada é quase sempre necessária para controlar os custos. O foco arquitetural muda para a otimização do motor de inferência (quantização, otimização de cache KV, decodificação especulativa), balanceamento de carga de múltiplas instâncias, políticas de dimensionamento automático e implantação multirregião para alta disponibilidade. Use uma estratégia de implantação híbrida para lidar com picos de tráfego.
Mais de 10 milhões de solicitações por dia: essa escala exige otimização profunda de inferência e estratégias de implantação personalizadas. Pode envolver técnicas avançadas como destilação de modelo (comprimir o conhecimento de um modelo grande em um menor para reduzir o custo por solicitação), uso de chips de inferência especializados e mesclagem de solicitações para processamento em lote.
Reavalie sua arquitetura de inferência quando: a utilização da GPU permanecer abaixo de 20% por mais de um trimestre (um sinal de superprovisionamento); a latência de cold-start levar a um aumento significativo nas reclamações dos usuários; o crescimento do tráfego fizer com que os custos do Serverless excedam os custos das instâncias dedicadas; ou novas tecnologias de aceleração de inferência (como novo hardware ou frameworks de otimização) causarem uma mudança geracional no preço-desempenho.
Árvore de decisão 3: Arquitetura de dados de IA
Se um modelo é o "cérebro" de um sistema de IA, então a arquitetura de dados é a sua "memória". O teto de qualidade para o RAG é determinado pela qualidade do pipeline de dados — se o pipeline não conseguir recuperar o conhecimento certo, nem o modelo mais poderoso poderá fornecer uma resposta precisa. O design da arquitetura de dados deve equilibrar a precisão da recuperação, a latência de resposta e o custo de armazenamento.
Recuperação vetorial pura, recuperação híbrida e RAG aprimorado por grafo
A recuperação vetorial pura é a forma mais básica de um sistema RAG. Os documentos são divididos em fragmentos, convertidos em vetores de embedding e armazenados em um banco de dados vetorial. Durante a recuperação, a consulta do usuário é vetorizada para execute uma busca aproximada do vizinho mais próximo, retornando os fragmentos de documento semanticamente mais semelhantes como contexto. Este método é simples de implementar e funciona bem para texto não estruturado. É adequado para perguntas e respostas no estilo FAQ, onde as perguntas e respostas são semanticamente relacionadas, e para recuperação simples de documentos (como consultas a manuais de product). O modo padrão da base de conhecimento do Model Studio (Bailian) é a recuperação vetorial.
No entanto, a recuperação vetorial pura tem limitações claras. Ela captura apenas a similaridade semântica e tem dificuldades com requisitos de correspondência exata (como consultar um ID de product específico como SKU-20240315), não pode usar metadados estruturados para filtragem (por exemplo, "mostrar apenas documentos publicados em 2026") e tem um desempenho ruim em perguntas complexas que exigem o entendimento das relações entre entidades.
A recuperação híbrida combina a busca semântica vetorial com a busca tradicional por palavras-chave (como BM25) e adiciona filtragem de metadados. Ela executa ambos os tipos de busca simultaneamente e, em seguida, usa um modelo reranker para mesclar e reclassificar os resultados. Essa abordagem oferece tanto compreensão semântica quanto recursos de correspondência exata, tornando-a a escolha principal para sistemas RAG corporativos. É adequada para bibliotecas de documentos corporativos com metadados claros, bases de conhecimento técnico com conceitos e parâmetros exatos, e bases de conhecimento de atendimento ao cliente com FAQs semânticas e IDs de correspondência exata. A base de conhecimento do Model Studio (Bailian) suporta um modo de recuperação híbrida, e o AnalyticDB for PostgreSQL fornece os recursos subjacentes de indexação de texto completo e vetorial fundido.
O RAG aprimorado por grafo se baseia na recuperação híbrida ao introduzir um grafo de conhecimento para modelar explicitamente as relações entre entidades. Quando uma pergunta envolve raciocínio de múltiplos saltos (por exemplo, "Quais componentes do Fornecedor A são usados em projetos gerenciados por João da Silva?"), a recuperação semântica tem dificuldade em conectar informações entre documentos. Um grafo de conhecimento, no entanto, pode encontrar respostas rapidamente percorrendo caminhos de relacionamento de entidades. Essa abordagem é adequada para domínios com relacionamentos de entidades complexos (como gerenciamento de cadeia de suprimentos ou redes de citações acadêmicas) e para perguntas e respostas de múltiplos saltos. A complexidade e o custo de manutenção do RAG aprimorado por grafo são significativamente maiores, portanto, só deve ser considerado quando a recuperação híbrida não puder atender aos requisitos de precisão.
Base de conhecimento gerenciada vs. pipeline autoconstruído
O recurso de base de conhecimento no Model Studio (Bailian) fornece um pipeline de RAG pronto para uso: faça o upload de documentos e a plataforma cuida da análise automática, fragmentação inteligente, vetorização, construção de índice e APIs de recuperação. Isso exige quase nenhum esforço de engenharia, tornando-o ideal para validar rapidamente a viabilidade do RAG e para bases de conhecimento de pequeno a médio porte. Suas vantagens são alta eficiência de desenvolvimento (configuração em minutos), zero de sobrecarga operacional e integração perfeita com as aplicações do Model Studio (Bailian).
No entanto, uma base de conhecimento gerenciada oferece personalização limitada. Não é possível controlar finamente as estratégias de fragmentação (por exemplo, usar lógicas diferentes para código versus tabelas), inserir etapas de limpeza personalizadas no pipeline de pré-processamento (como mascaramento de dados ou normalização de terminologia) ou ajustar extensivamente as estratégias de recuperação. Quando seus requisitos de qualidade de RAG são excepcionalmente altos, pode ser necessário construir seu próprio pipeline de dados.
Um pipeline autoconstruído significa criar a própria cadeia, desde a ingestão de dados até o service de recuperação. Isso inclui: análise de documentos (PDF, Word, páginas da web); pré-processamento (limpeza, mascaramento, extração de metadados); fragmentação (por parágrafo semântico, tamanho fixo ou hierarquia); embedding (chamando modelos DashScope ou um modelo auto-treinado); armazenamento de índice (usando AnalyticDB for PostgreSQL, Lindorm ou Elasticsearch); e um service de recuperação com lógica de recall e reranking personalizados. O DataWorks orquestra a execução agendada e as atualizações incrementais desse pipeline.
A consideração chave é o foco da sua equipe. Se sua equipe tem menos de cinco pessoas e a IA não é um negócio principal, comece com uma base de conhecimento gerenciada. Se você tem engenheiros de dados dedicados e a qualidade do RAG é um diferencial principal, construa seu próprio pipeline para ter controle total. Se você estiver no meio-termo, comece com uma base de conhecimento gerenciada e autoconstrua componentes específicos somente após identificar gargalos.
Atualização de dados e implicações arquiteturais
A tempestividade necessária dos dados na sua base de conhecimento determina diretamente a complexidade da arquitetura do seu pipeline de dados:
Atualizações em tempo real (segundos a minutos): adequado para dados que mudam rapidamente, como status de pedidos ou informações de estoque. A arquitetura é um pipeline de streaming que usa uma fila de mensagens (como Kafka ou RocketMQ) para ouvir eventos de alteração de dados e acionar a vetorização incremental e atualizações de índice. Esta é a opção mais complexa, o que exige lidar com consistência, eventos fora de ordem e mensagens duplicadas.
Atualizações quase em tempo real (por hora): adequado para conteúdo com frequência de atualização moderada, como notícias, anúncios ou documentação de product. A arquitetura é um job agendado. Use o DataWorks para configure tarefas de sincronização de dados por hora ou diárias que processem dados incrementais em lotes e atualize o índice. Isso tem complexidade moderada e é uma escolha pragmática para a maioria das bases de conhecimento corporativas.
Atualizações estáticas ou infrequentes (semanais a mensais): adequado para conteúdo que raramente muda, como regulamentos, materiais de treinamento ou arquivos históricos. A arquitetura é uma reconstrução completa manual ou periódica. Processe todos os documentos de uma vez e acione manualmente uma reconstrução apenas quando ocorrem grandes alterações de conteúdo. Esta é a opção menos complexa e é bem suportada pelo modo padrão da base de conhecimento do Model Studio (Bailian).
O trade-off: Precisão de recall, latência e custo de armazenamento
O design da arquitetura de dados deve sempre navegar por este trade-off de três vias:
Métodos para melhorar a precisão de recall (como tamanhos de fragmento menores, vetores de embedding de maior dimensão, adição de um reranker ou aumento de candidatos de recuperação) geralmente aumentam os custos de armazenamento e a latência de recuperação. Um índice com 100 milhões de vetores de 1536 dimensões requer cerca de 600 GB de armazenamento, e cada busca pode levar de 50 a 100 ms.
Métodos para reduzir a latência (como usar um índice vetorial na memória, reduzir candidatos de recuperação ou simplificar a lógica de reranking) podem sacrificar a precisão de recall. Carregar um índice totalmente na memória pode reduzir a latência de busca para milissegundos de um dígito, mas a memória é muito mais cara que o armazenamento em disco.
Métodos para controlar o custo de armazenamento (como reduzir a dimensionalidade do vetor, usar compressão de quantização ou aumentar o tamanho do fragmento para reduzir o número total de vetores) podem afetar negativamente a precisão de recall. A Quantização de Produto (PQ) pode comprimir o armazenamento do vetor para um quarto do seu tamanho original, mas introduz alguma perda de precisão.
Os arquitetos devem definir prioridades com base no cenário específico. As perguntas e respostas em tempo real voltadas para o usuário devem priorizar a baixa latência (P95 < 200ms) e a precisão da linha de base. Um assistente de pesquisa aprofundada para analistas deve priorizar a precisão de recall, mesmo que a latência seja de vários segundos. A recuperação de arquivos de repositórios massivos de documentos deve priorizar o baixo custo de armazenamento.
Reavalie sua arquitetura de dados quando: a precisão do sistema RAG cair consistentemente abaixo dos requisitos do negócio (pode ser necessário atualize da recuperação vetorial pura para a híbrida ou aprimorada por grafo); o crescimento da base de conhecimento fizer com que a latência de recuperação exceda os SLAs; ou os requisitos de atualização de dados mudarem de diários para o nível de minutos.
Árvore de decisão 4: Arquitetura de agentes
Um agente é uma evolução chave para os sistemas de IA, movendo-os de respostas passivas a perguntas para ações proativas. Quando uma IA deve não apenas responder a perguntas, mas também chamar ferramentas, realizar operações e coordenar tarefas de múltiplas etapas, a arquitetura de agentes se torna uma consideração central de design.
Orquestração de agente único vs. multiagente
Uma arquitetura de agente único é a implementação mais direta. Um agente tem todos os recursos para entender a intenção, chamar ferramentas e gerar respostas. Isso é adequado quando o escopo da tarefa é claro e limitado, o número de ferramentas necessárias é inferior a dez e não é necessário nenhum role-playing complexo ou coordenação de processos. Por exemplo, um agente de gerenciamento de calendário pode entender "Agende uma reunião com o Sr. Zhang para amanhã às 15h", depois chamar a API do calendário, encontrar um horário disponível, criar o convite e enviar notificações — tudo lidado por um único agente.
Quando a complexidade da tarefa excede a capacidade de um único agente, a orquestração multiagente se torna necessária. Os sinais dessa complexidade incluem: a necessidade de diferentes conhecimentos especializados e conjuntos de ferramentas (um agente para análise de código, outro para compreensão de documentos); a necessidade de execute subtarefas em paralelo e agregar resultados; a necessidade de freios e contrapesos entre funções (um agente gera um plano, outro o revisa quanto à conformidade); ou a janela de contexto de um único agente ser muito pequena para conter todas as informações da tarefa.
Os padrões comuns de orquestração multiagente incluem: o Padrão Orquestrador, onde um agente central decompõe e despacha tarefas para vários agentes especialistas; o Padrão Pipeline, onde a saída de um agente se torna a entrada para o próximo; e o Padrão Debate, onde múltiplos agentes analisam um problema de diferentes ângulos e debatem para convergir na melhor resposta.
Agentes de chamada de ferramenta, orientados por fluxo de trabalho e autônomos
A arquitetura interna de um agente classifica-se em três tipos com base em seu grau de autonomia:
Um agente de chamada de ferramenta é centrado na capacidade do modelo de chamar ferramentas. O modelo decide quando chamar qual ferramenta e como analisar o resultado. O caminho de execução é dinâmico, com o modelo determinando a próxima ação em cada etapa com base no contexto. Isso é adequado para espaços de problemas abertos onde nem todos os caminhos de execução podem ser predefinidos e a flexibilidade é necessária. Por exemplo, um assistente geral de análise de dados deve decidir dinamicamente qual source de dados consultar, qual análise realizar e como visualizar os resultados para qualquer pergunta.
Um agente orientado por fluxo de trabalho executa um fluxograma predefinido. Cada nó é uma etapa determinística, como uma chamada de modelo, uma chamada de ferramenta, uma ramificação condicional ou uma aprovação manual. O caminho de execução, incluindo quaisquer ramificações, é definido no momento do design. Isso é adequado para cenários de negócios com processos fixos e requisitos rigorosos de conformidade, como aprovação de empréstimos (verificação de crédito → verificação de renda → avaliação de risco → decisão final) ou triagem médica (coleta de sintomas → avaliação de urgência → recomendação de departamento).
Um agente autônomo opera com o maior grau de autonomia. Ele pode definir seus próprios subobjetivos, planejar etapas de execução e refletir e ajustar sua estratégia durante a execução. Isso é adequado para tarefas de pesquisa complexas e de longa duração (como "Analise o cenário competitivo desta indústria e gere um relatório") e tarefas exploratórias com alta incerteza. Os agentes autônomos também carregam o maior risco. Um agente não controlado pode cair em um loop infinito, incorrer em altos custos de API ou realizar ações não intencionais. Implemente condições claras de terminação (máximo de etapas, orçamento de tokens, timeout) e checkpoints (pausando para confirmação manual antes de decisões críticas).
Execução síncrona vs. assíncrona
O modo de execução do agente depende da duração da tarefa e do modelo de interação do usuário:
A execução síncrona é para tarefas que são concluídas rapidamente (em segundos). O usuário envia uma solicitação, o agente a processa e o resultado é retornado diretamente. Este é o modo padrão para a maioria dos cenários de conversação. As principais considerações incluem controlar o tempo total de execução com timeouts e colocar restrições de latência nas chamadas de ferramentas para que uma API não responsiva não bloqueie toda a solicitação.
A execução assíncrona é para tarefas que levam muito tempo para serem concluídas. O usuário envia a tarefa e pode sair, recebendo uma notificação após a conclusão. Por exemplo, "Analise os dados de vendas dos últimos três meses e gere um relatório semanal" pode levar vários minutos. Uma arquitetura assíncrona deve incluir o rastreamento do status da tarefa (pendente, em execução, concluída, falhou), relatórios de progresso para manter o usuário informado, persistência de resultados intermediários para evitar perda de dados em caso de falha e notificações de resultados (via mensagem, e-mail ou push de UI).
Um modelo híbrido combina ambos. O agente primeiro retorna uma resposta rápida e preliminar de forma síncrona (por exemplo, "Estou analisando seus dados e espero terminar em cerca de 3 minutos"). Em seguida, ele realiza a análise detalhada de forma assíncrona e envia o resultado completo após a conclusão.
Árvore de decisão 5: Construir, comprar ou personalizar
Em última análise, todas as decisões técnicas são restringidas por uma questão estratégica fundamental: qual é o papel da IA na stack de tecnologia da sua empresa? É uma competência principal ou um utilitário de uso geral? Esse julgamento determina o seu modelo de investimento.
SaaS vs. PaaS vs. IaaS
Uma solução de IA SaaS é a opção mais leve. Você compra diretamente software de prateleira com recursos de IA integrados, como um SaaS de atendimento ao cliente com um recurso de resumo de IA ou uma IDE com codificação assistida por IA. Você não precisa conhecer o modelo subjacente ou gerencie prompts e bases de conhecimento; você consome a IA como um recurso de product. Isso é adequado quando a IA não é um diferencial principal, os recursos padrão atendem às suas necessidades, você não tem preocupações com residência de dados e deseja o tempo de lançamento mais rápido.
O modelo PaaS, representado pelo Model Studio (Bailian), fornece recursos fundamentais como invocação de modelo, bases de conhecimento, orquestração de agentes e segurança de conteúdo, sobre os quais você constrói suas próprias aplicações de IA. Você controla a lógica da aplicação, as estratégias de prompt, o conteúdo da base de conhecimento e os processos de negócios, mas não gerencia os recursos de GPU subjacentes ou a veiculação do modelo. Este é o ponto de partida recomendado para a maioria das aplicações de IA corporativas, especialmente quando você precisa de alguma personalização, tem desenvolvedores de aplicações, mas não possui profunda experiência em MLOps, e exige segurança e conformidade no nível da plataforma.
O modelo IaaS significa que você mesmo gerencia toda a stack de tecnologia de IA. Você implanta modelos de código aberto no ECS ou ACK, constrói seus próprios service de inferência e pipelines de treinamento, e mantém todo o ciclo de vida do modelo. Você obtém o máximo de flexibilidade e controle, mas também assume toda a complexidade de engenharia e responsabilidade operacional. Isso é adequado quando a IA é uma competência principal que exige personalização extrema, sua equipe tem profundos recursos de engenharia de ML, você tem requisitos rigorosos de controle de dados (por exemplo, dados do sistema financeiro principal) ou sua escala é tão grande que construir é significativamente mais barato do que usar service de plataforma.
Custo total de propriedade (TCO)
O custo total de propriedade (TCO) de um sistema de IA vai muito além das taxas de recursos da cloud. Uma avaliação completa de TCO deve incluir:
Custo de Desenvolvimento: O esforço de engenharia para construir do zero. Isso é quase zero para SaaS, requer desenvolvimento na camada de aplicação para PaaS (pessoas-semana) e desenvolvimento full-stack para IaaS (pessoas-mês a pessoas-ano).
Custo de Operações: O esforço humano contínuo para manutenção, incluindo monitoramento, solução de problemas e atualizações. Isso é lidado pelo fornecedor para SaaS, compartilhado para PaaS (a Alibaba Cloud gerencia a plataforma, você gerencia a aplicação) e é de sua total responsabilidade para IaaS.
Custo de Atualização de Modelo: O investimento para acompanhar a evolução dos modelos de base. As atualizações de SaaS são geralmente automáticas. O PaaS permite que você mude para novos modelos via configure. O IaaS exige que você gerencie todo o processo de substituição, avaliação e reimplantação, incluindo o retreinamento de modelos com fine-tuning.
Custo de Conformidade: O esforço para atender aos requisitos regulatórios. Os fornecedores de SaaS geralmente lidam com isso, mas você deve confirme se cobre o seu caso de uso. O PaaS fornece conformidade no nível da plataforma, mas você ainda é responsável pela sua aplicação. Com o IaaS, todo o trabalho de conformidade é de sua responsabilidade.
Custo de Oportunidade: Os benefícios potenciais perdidos ao escolher um caminho em vez de outro. Construir um sistema de IA ao longo de vários meses significa atrasar seu lançamento. Em um mercado em rápido movimento, um atraso de seis meses pode significar perder sua vantagem de pioneiro. Este custo oculto é frequentemente subestimado.
Custo de Saída: A despesa futura de migrar para uma nova solução. A integração profunda com um fornecedor SaaS pode dificultar a migração de dados. Um sistema autoconstruído altamente personalizado pode ser difícil de migrar devido ao bloqueio arquitetural. Projete com camadas de abstração razoáveis para reduzir os custos de saída.
Capacidade da equipe e caminho recomendado
A capacidade de engenharia de IA da sua equipe é uma restrição chave. Uma solução tecnicamente ideal que excede as habilidades da sua equipe se torna a pior escolha na prática.
Nenhuma equipe dedicada de IA/ML: Os desenvolvedores de negócios lidam com suas necessidades de IA, sem engenheiros de algoritmos dedicados ou funções de MLOps. Caminho recomendado: Primeiro, avalie se uma solução SaaS atende às suas necessidades. Se não, use os recursos de baixo código do Model Studio (Bailian) para construir sua aplicação. Aproveite a orquestração de agentes da plataforma, o gerenciamento de base de conhecimento e os recursos de avaliação de modelo para diminuir a barreira de especialização. Concentre-se em cenários de negócios e otimização de prompts, não na engenharia subjacente.
Pequena equipe de IA (3-10 pessoas): Você tem alguns engenheiros de algoritmos e desenvolvedores de aplicações de IA com alguma capacidade de avaliação de modelo e processamento de dados. Caminho recomendado: Use o Model Studio (Bailian) como sua base principal. Entregue rapidamente onde os recursos padrão forem suficientes e invista em personalização profunda apenas para os diferenciais principais. Use a plataforma PAI para fine-tuning seletivo de modelos e o DataWorks para construir pipelines de dados personalizados. Concentre-se em identificar quais partes valem a pena construir você mesmo e quais devem permanecer na plataforma.
Grande equipe de engenharia de ML (mais de 10 pessoas): Você tem uma organização completa de P&D de IA, incluindo pesquisa, treinamento, otimização de inferência, engenharia de dados e MLOps. Caminho recomendado: Uma abordagem híbrida IaaS+PaaS. Autoconstrua os recursos principais do modelo no IaaS (implantando service de inferência personalizados no ACK, executando treinamento em grande escala no PAI) para máximo controle e vantagem de custo. Use os recursos de PaaS (como segurança de conteúdo do Model Studio (Bailian)) para necessidades periféricas a fim de melhorar a eficiência. Concentre seu poder de engenharia naquilo que constrói seu fosso competitivo.
Independentemente do tamanho da equipe, uma recomendação comum é começar com uma prova de conceito (PoC) na plataforma Model Studio (Bailian) para validar o valor do negócio com investimento mínimo. Depois que o PoC confirme que uma solução de IA pode resolver um problema real de negócios, decida se deve permanecer na plataforma ou evoluir para uma solução autoconstruída com base nas capacidades da sua equipe e na estratégia de longo prazo. O investimento prematuro em autoconstrução é um desperdício comum de recursos em projetos de IA; muitas empresas passam meses construindo um service personalizado apenas para descobrir que o caso de negócios não era viável ou que uma solução de plataforma já atendia às suas necessidades.
Os arquitetos devem documentar a justificativa e as premissas para cada decisão. Isso permite uma reavaliação e ajuste rápidos quando as condições externas mudam, como expansão da equipe, crescimento dos negócios, novos lançamentos de modelos ou atualizações regulatórias. A arquitetura de IA não é um design único, mas um processo dinâmico de otimização contínua que evolui com o negócio.
Reavalie seu caminho técnico quando: as limitações da plataforma PaaS bloquearem repetidamente seus requisitos (sinalizando a necessidade de migrar para o IaaS); o custo de personalização de uma solução SaaS começar a se aproximar do custo de construí-la você mesmo; ou a capacidade de engenharia de IA da sua equipe crescer significativamente ao longo de um período de 6 a 12 meses.