Well-Architected Framework:Transformação nativa de IA

Saídas não determinísticas

Os sistemas de software tradicionais seguem uma lógica determinística: ao chamar a mesma interface com os mesmos parâmetros, você sempre obterá o mesmo resultado. Uma carga de trabalho de IA quebra fundamentalmente essa premissa. Mesmo com uma entrada idêntica, um modelo de linguagem grande pode produzir saídas diferentes a cada execução de inferência, variando em redação, estrutura ou até mesmo nas conclusões.

Considere um cenário de atendimento ao cliente corporativo. Quando um usuário pergunta "Quando meu pedido chegará?", um sistema tradicional consulta um banco de dados para obter o status logístico e retorna uma data definida. Em contrapartida, um agente de atendimento ao cliente com IA, após recuperar as mesmas informações logísticas, pode responder uma vez com "A previsão é que seu pedido chegue amanhã à tarde" e, em outra ocasião, com "Com base nas informações de envio, seu pacote será entregue no seu endereço antes das 14:00 do dia 21 de junho". As duas respostas são semanticamente equivalentes, mas a fraseologia é completamente diferente. Esse não determinismo torna ineficazes os métodos tradicionais de teste automatizado baseados em correspondência exata e exige que os arquitetos introduzam uma estrutura de avaliação de qualidade em nível semântico.

Ao criar aplicações de conversação com um modelo de linguagem grande, defina o parâmetro temperature próximo de zero para reduzir a aleatoriedade. No entanto, isso não elimina completamente o não determinismo. Fatores como a precisão da aritmética de ponto flutuante dentro do modelo ou diferentes ordens de computação em vários hardwares ainda podem causar um desvio sutil na saída. Portanto, a estratégia de teste para sistemas de IA deve mudar de foco: não busque apenas a exatidão, mas verifique se a saída está dentro de uma faixa aceitável.

Para resolver isso, os arquitetos devem estabelecer um sistema de avaliação em nível semântico. Esse sistema vai além das verificações tradicionais de "a saída é igual ao valor esperado?" e, em vez disso, constrói uma linha de base de qualidade usando pontuação multidimensional (relevância, precisão, integridade e segurança) e monitora continuamente desvios de qualidade.

Qualidade subjetiva e contextual

A definição de "bom" torna-se incomumente complexa em sistemas de IA. O resumo de um mesmo documento precisa extrair insights estratégicos para executivos, preservar detalhes técnicos para engenheiros e destacar a exposição a riscos para as equipes jurídicas. Não existe um único resumo "absolutamente correto" — o julgamento de qualidade depende inteiramente do caso de uso e das expectativas do público.

Essa subjetividade tem implicações profundas no nível do product. Defeitos em softwares tradicionais podem ser encontrados antes da implantação por meio de testes de unidade e de integração. Em contrapartida, os "defeitos de qualidade" em sistemas de IA costumam surgir apenas em contextos de negócios específicos. A resposta de um assistente de consulta médica pode ser clinicamente precisa, mas se usar jargão profissional demais para um paciente entender, ela será considerada de "baixa qualidade" nesse cenário.

Na prática de engenharia, isso significa que a avaliação de qualidade deve ser em camadas: uma camada fundamental verifica a factualidade, a segurança e a conformidade de formato (automatizável); uma camada de negócios avalia a integridade das informações e a consistência lógica (semiautomatizável); e uma camada de experiência julga o tom, o nível de detalhe e a adequação ao público (requer amostragem manual).

O custo escala com o uso

Os custos de arquitetura cloud tradicional estão principalmente atrelados a recursos de infraestrutura, como quantidade de servidores, capacidade de armazenamento e largura de banda de rede. Uma carga de trabalho de IA introduz uma nova dimensão de custo: o consumo de token. Cada chamada de modelo é cobrada com base nos tokens de entrada e saída, tornando o custo diretamente proporcional ao volume de negócios e à complexidade da solicitação.

Considere um sistema de perguntas e respostas corporativo. Suponha que um modelo de inferência custe A dólares por 1.000 tokens de entrada e B dólares por 1.000 tokens de saída, onde B é tipicamente 2 a 4 vezes A. Uma única interação de 8.000 token s (7.000 de entrada, 1.000 de saída) custaria aproximadamente 7A + B. Multiplicado por uma média de um milhão de solicitações por dia, o custo mensal de inferência pode aumentar significativamente. escolha um modelo com mais parâmetros, e A e B poderão aumentar de 5 a 10 vezes. Mais criticamente, à medida que os sistemas de geração aumentada por recuperação (RAG) recuperam mais contexto e os agentes realizam mais rodadas de chamadas de ferramentas, o consumo de token por solicitação continuará a inflar, elevando os custos muito além das expectativas.

A Token economics exige que os arquitetos tratem o custo como uma restrição arquitetônica de primeira classe. Isso significa não apenas optar por modelos mais econômicos (por exemplo, usar o Qwen-Plus em vez do Qwen-Max para consultas simples), mas também projetar mecanismos de controle de custos no nível arquitetônico, como compressão de context window, otimização de acertos de cache e roteamento de solicitações baseado em complexidade. Na plataforma Model Studio, selecione modelos de diferentes especificações dinamicamente com o recurso de model routing com base nas características da solicitação, minimizando o gasto de token e atendendo aos requisitos de qualidade.

Cadeia de suprimentos estendida

No software tradicional, os riscos da cadeia de suprimentos concentram-se principalmente nas dependências de código e na infraestrutura — por exemplo, se uma biblioteca de código aberto tem uma vulnerabilidade ou se uma imagem de contêiner é confiável. Uma carga de trabalho de IA estende a cadeia de suprimentos a um escopo sem precedentes. Pesos de modelos, dados de treinamento, conjuntos de dados de ajuste fino, modelos de prompts, benchmarks de avaliação e até mesmo documentos da base de conhecimento em um sistema RAG tornam-se componentes da cadeia de suprimentos, onde cada elo pode se tornar uma superfície de ataque.

Já ocorreram vários ataques à cadeia de suprimentos de modelos. Atacantes publicaram arquivos de pesos de modelos cuidadosamente envenenados em repositórios de modelos de código aberto. Na superfície, o modelo funciona normalmente, mas sob condições de gatilho específicas, ele pode vazar dados de entrada do usuário ou gerar conteúdo nocivo. Se uma empresa implantar esse modelo em um ambiente de produção sem uma validação rigorosa, as consequências poderão ser desastrosas.

Além disso, o próprio prompt representa um risco para a cadeia de suprimentos. As empresas costumam armazenar modelos de prompts principais em sistemas de controle de versão ou centros de configuração, mas frequentemente não possuem processos de auditoria e aprovação para alterações no prompt. Uma única modificação não revisada em um prompt pode causar uma mudança fundamental no comportamento do modelo, como contornar filtros de segurança de conteúdo ou vazar lógica de negócios sensível contida nas instruções do sistema.

A conformidade não é opcional

A china está na vanguarda da regulamentação global para IA generativa. As Medidas Provisórias para a Gestão de service de Inteligência Artificial Generativa, implementadas em 2023, afirmam claramente que as empresas que fornecem service de IA generativa ao público devem concluir um Algorithm Filing; o conteúdo gerado deve refletir os valores socialistas fundamentais; os provedores de service são responsáveis pela legalidade de suas source de dados de treinamento; e os usuários têm o direito de saber que estão interagindo com uma IA, e não com um humano.

O Algorithm Filing não é uma ação de conformidade única, mas uma obrigação contínua. Um novo registro pode ser necessário sempre que um modelo passar por uma atualização importante, como alterar a versão do modelo base, modifique a estratégia principal do prompt ou introduzir novos dados de treinamento. Isso impõe demandas claras ao design arquitetônico: o sistema deve ter capacidades completas para rastreamento de versão do modelo, procedência dos dados de treinamento e auditoria de conteúdo gerado.

No Alibaba Cloud, os recursos de moderação de conteúdo do Model Studio e do Alibaba Cloud Content Security fornecem a base técnica para a conformidade. No entanto, os arquitetos devem entender que a conformidade não é simplesmente uma questão de adicionar um filtro antes do lançamento. Isso significa integrar os requisitos de conformidade em cada camada da arquitetura — desde a marcação de source durante a ingestão de dados e a limpeza de dados durante o treinamento do modelo, até a moderação de conteúdo durante a inference e a retenção e rastreabilidade de logs no lado do servidor.

Evolução rápida dos modelos

O ritmo da iteração tecnológica no campo da IA supera em muito o do ecossistema de software tradicional. A série de modelos Qwen passou por várias atualizações importantes de versão em dois anos — do Qwen para o Qwen2, Qwen2.5 e Qwen3. Cada atualização traz melhorias significativas de capacidade e pequenas alterações de interface. Uma estratégia de prompt cuidadosamente ajustada hoje pode ter um desempenho ruim com a próxima versão do modelo, e os recursos investidos no fine-tuning de um modelo hoje podem se tornar desnecessários devido às melhorias de capacidade de um novo modelo base.

A principal conclusão arquitetônica dessa evolução rápida é que os sistemas de IA devem ser projetados para a substituição de modelos. Abstrair as chamadas de modelo em uma interface unificada, versionar prompts e persistir benchmarks de avaliação para testes de regressão rápidos em novos modelos são investimentos arquitetônicos necessários. Na plataforma Model Studio, separar a configuração da aplicação da configuração do modelo permite alternar o modelo subjacente sem modificar o código da aplicação, reduzindo significativamente a carga de engenharia da iteração do modelo.

Ao mesmo tempo, os arquitetos precisam ficar atentos à "armadilha da superotimização": evite investir engenharia personalizada excessiva em um modelo que pode se tornar obsoleto em seis meses. Durante uma fase de melhoria rápida da capacidade do modelo, o prompt engineering leve e a retrieval-augmented generation (RAG) costumam oferecer um retorno sobre o investimento melhor do que o fine-tuning pesado do modelo. Isso ocorre porque as otimizações do primeiro são migradas mais facilmente para novos modelos.

Qualidade versus custo

Um modelo com uma escala de parâmetros maior geralmente oferece melhor compreensão, raciocínio mais preciso e expressão mais fluente, mas isso também significa um aumento multiplicativo no custo de inference. Tome a série Qwen como exemplo: o Qwen-Max tem um desempenho significativamente melhor que o Qwen-Plus em tarefas de raciocínio complexo, mas seu custo por chamada também é várias vezes maior.

Em um sistema de atendimento ao cliente inteligente que lida com 500.000 consultas de usuários por dia, rotear todas as solicitações para o Qwen-Max pode elevar os custos mensais de inference para mais de um milhão de yuans. Mas se todas as solicitações usarem o Qwen-Plus, a qualidade das respostas para perguntas complexas cairá significativamente, levando a uma menor satisfação do usuário e a uma taxa maior de escalonamento para agentes humanos.

O padrão arquitetônico para resolver essa tensão é o roteamento inteligente: use um classificador de intenção leve para determinar a complexidade da solicitação. Consultas simples (como "Qual é o horário de funcionamento?") são roteadas para o Qwen-Plus, enquanto consultas complexas que exigem raciocínio em várias etapas (como "Compare os custos de longo prazo do plano A e do plano B") são roteadas para o Qwen-Max. Em cenários de aplicação de modelos grandes, use a orquestração de workflow para implementar esse roteamento em camadas, encontrando uma solução ótima de Pareto entre alcançar os objetivos de qualidade e controlar os custos. No entanto, a própria estratégia de roteamento tem um custo. Erros de julgamento do classificador podem levar à perda de qualidade ou a gastos desperdiçados, portanto, monitore continuamente a precisão do roteamento e itere nas otimizações.

Para volumes de solicitações diárias abaixo de 100.000, a complexidade de engenharia do roteamento e a manutenção do classificador podem superar os custos de inference economizados; nesse caso, usar um único modelo de tamanho médio é mais econômico. Quando a taxa de classificação incorreta do classificador para consultas complexas excede 15% (roteando-as para o modelo mais simples), usar o modelo grande para todas as solicitações pode, na verdade, reduzir os custos gerais, minimizando as solicitações de acompanhamento e as intervenções manuais causadas por respostas de baixa qualidade.

Velocidade versus segurança

Os usuários esperam que os sistemas de IA respondam tão instantaneamente quanto uma conversa humana. A tecnologia de Streaming permite que os tokens gerados pelo modelo sejam enviados ao usuário um a um, criando um efeito de "máquina de escrever" e reduzindo o time-to-first-token (TTFT) para algumas centenas de milissegundos. No entanto, o streaming significa que o conteúdo é exibido ao usuário à medida que é gerado. Se o modelo produzir repentinamente conteúdo inapropriado no terceiro parágrafo, os dois primeiros parágrafos já terão sido enviados e não poderão ser retractados.

A solução tradicional é "revisar e depois liberar": aguarde o modelo gerar a resposta completa, execute-a em uma verificação de segurança de conteúdo e, em seguida, retorne tudo de uma vez. Isso aumenta o tempo de resposta do primeiro token da faixa de subsegundos para vários ou até dezenas de segundos, prejudicando gravemente a experiência do usuário. Em cenários de conversação, um tempo de espera superior a três segundos pode levar a uma perda significativa de usuários.

As soluções de compromisso práticas incluem a revisão segmentada (executar uma verificação rápida após a geração de cada frase), streaming em tempo real com revisão assíncrona e retratação posterior, e estratégias diferenciadas com base nos níveis de confiança do usuário (usuários internos recebem saída em streaming, enquanto usuários públicos exigem saída pré-moderada). O Alibaba Cloud Content Security suporta detecção de texto em streaming, o que permite a filtragem de conteúdo em tempo real sem aumentar significativamente a latência. No entanto, os arquitetos devem avaliar a compensação aceitável entre o risco de detecções perdidas e a degradação da experiência do usuário para seu cenário específico.

Para aplicações voltadas a usuários internos com baixo risco de conteúdo, adote um modelo de "transmitir primeiro, revisar depois", realizando apenas uma revisão atrasada no conteúdo sinalizado. Para aplicações voltadas ao público ou aquelas em domínios regulamentados, como consultoria financeira ou informações médicas, "revisar primeiro, liberar depois" é o requisito básico, mesmo que adicione de 200 a 500 ms de latência.

Autonomia versus controle

O valor de um agent de IA reside em sua capacidade de concluir tarefas complexas de forma autônoma — recuperando informações automaticamente, chamando ferramentas, tomando decisões e executando ações. Mas quanto maior a autonomia, maior o risco de perder o controle. Um agent autorizado a realizar operações de banco de dados pode causar um desastre se execute uma instrução DELETE não intencional devido a um ataque de prompt injection ou a uma alucinação do modelo.

Considere um agent de compras internas projetado para fazer pedidos de reposição automaticamente com base nos níveis de estoque. Se receber autonomia total, ele pode comprar em excesso devido a um mal-entendido dos sinais de mercado, imobilizando um capital significativo. Mas se cada compra exigir aprovação manual, a vantagem de eficiência da automação se perde.

Uma estratégia arquitetônica viável é a "autonomia em camadas": defina limites de ação claros, como um limite de transação única de 50.000 yuans e um limite cumulativo diário de 200.000 yuans. Dentro desses limites, o agent pode executar automaticamente. Quando um limite é excedido, ele pausa e solicita aprovação manual. Ao criar um agent na plataforma Model Studio, implemente esse controle em camadas usando nós de condição e revisão humana em um workflow. A chave é fazer com que o agent escale quando encontrar incerteza, em vez de tomar silenciosamente uma decisão potencialmente errada.

Quando o impacto de uma única operação está abaixo de um determinado limite monetário (por exemplo, 5.000 yuans) e é reversível, o agent pode ser autorizado a executar de forma autônoma. Se o limite for excedido ou a operação for irreversível (como exclua de dados ou envio de notificações externas), uma etapa de confirmação humana é obrigatória.

Inovação versus governança

As equipes de negócios querem experimentar as capacidades de IA rapidamente — descobrir um novo caso de uso esta semana e lançar um chatbot na próxima semana. Essa tensão é particularmente aguda em grandes organizações, onde diferentes linhas de negócios podem incubar dezenas de aplicações de IA simultaneamente. Se cada aplicação tiver que passar por todo o processo de conformidade de forma independente, a equipe de governança ficará sobrecarregada e as equipes de negócios perderão oportunidades de mercado devido a longas esperas.

A solução é a governança baseada em plataforma: construa uma plataforma unificada de service de IA e integre capacidades de conformidade (como moderação de conteúdo, auditoria de logs e notificação de usuários) como service no nível da plataforma. As aplicações de negócios construídas nessa plataforma herdam sua linha de base de conformidade e exigem apenas uma avaliação incremental para riscos específicos da aplicação. Essa abordagem mantém um piso de conformidade enquanto permite uma inovação rápida nos negócios. O AI Governance pode ser configurado com uma linha de base de governança de IA para detectar automaticamente implantações de aplicações que violam políticas de segurança, fornecendo guardrails de governança sem bloquear o processo de desenvolvimento.

Para aplicações de IA abertas ao público, o Algorithm Filing deve ser concluído antes de entrarem no ar. Este é um requisito legal, não uma recomendação.

Customização versus manutenibilidade

Por meio do fine-tuning de modelos, as empresas podem fazer com que um modelo base se destaque em domínios específicos. Cenários verticais, como consulta médica, consultoria jurídica e análise financeira, podem se beneficiar significativamente do fine-tuning. Mas cada modelo ajustado é um ativo técnico que requer manutenção contínua: ele precisa ser reajustado quando o modelo base é atualizado, retreinado quando os dados de treinamento são atualizados e diagnosticado quando o desempenho degrada.

Uma empresa que mantém modelos ajustados e personalizados para 12 linhas de negócios diferentes está, na prática, mantendo 12 pipelines de treinamento de modelos independentes, 12 conjuntos de benchmarks de avaliação e 12 responsabilidades operacionais separadas. Quando o Qwen atualize do Qwen2.5 para o Qwen3, todos os 12 modelos precisam ser avaliados quanto à compatibilidade e podem precisar ser reajustados. A carga de engenharia cresce linearmente.

Uma estratégia alternativa é priorizar a obtenção de customização com prompt engineering e RAG. Ao usar prompts de sistema cuidadosamente projetados e injeção de contexto por meio de aumento de recuperação, você pode fazer com que um modelo de uso geral tenha um bom desempenho em um domínio específico. Os resultados dessa abordagem não estão vinculados a uma versão específica do modelo; quando o modelo é atualizado, verifique apenas se os efeitos do prompt permanecem estáveis, o que reduz significativamente os custos de manutenção. Escale para uma solução de fine-tuning apenas quando o prompt engineering e o RAG não puderem atender aos requisitos de qualidade.

Se a precisão de uma tarefa específica de domínio atingir um nível de negócios aceitável (por exemplo, >90% de satisfação) por meio do prompt engineering, não há necessidade de introduzir a complexidade do fine-tuning. Considere um investimento em fine-tuning apenas quando os limites do prompt engineering forem atingidos, os requisitos de negócios ainda não forem atendidos e você tiver pelo menos vários milhares de pontos de dados rotulados de alta qualidade.

Princípio 1: Autonomia controlada

O valor de um sistema de IA reside em sua capacidade de concluir tarefas complexas de forma autônoma, mas essa autonomia deve ser exercida dentro de limites explícitos. O princípio da "autonomia controlada" exige que cada componente de IA tenha limites de capacidade e normas de comportamento claramente definidos. Quando uma situação excede esses limites, o sistema deve escalar ativamente para os tomadores de decisão humanos, em vez de falhar silenciosamente ou fazer uma escolha potencialmente errada.

A implementação desse princípio requer um mecanismo de três camadas. A primeira camada são os guardrails, que garantem que o comportamento da IA não cruze limites, filtrando entradas e verificando saídas. Isso inclui filtragem de segurança de conteúdo, mascaramento de informações sensíveis e validação de formato. Na plataforma Model Studio, os guardrails no nível da aplicação podem ser configurados por meio de prompts do sistema e regras de pós-processamento. A segunda camada é o modelo human-in-the-loop (HITL), que define quando a intervenção humana é necessária e projeta as condições de gatilho e os canais de escalonamento para revisão manual. A terceira camada é o limite de permissão do agent, que define claramente quais ferramentas o agent pode chamar, a quais dados ele pode acessar e quais ações pode realizar, usando o princípio do menor privilégio para restringir seu escopo de autorização.

Na prática, a autonomia controlada significa projetar uma "lista de linhas vermelhas" para um agent. Essa lista especifica ações que são absolutamente proibidas (por exemplo, jamais exclua dados de produção sem aprovação) e ações de área cinzenta que exigem confirmação humana (por exemplo, pagamentos que excedem um determinado limite). O sistema deve fornecer uma trilha de auditoria clara, registrando o contexto, a justificativa e o resultado de cada decisão autônoma.

Princípio 2: Mensurabilidade de ponta a ponta

"Você não pode melhorar o que não pode medir" — essa verdade da engenharia é ainda mais crítica no domínio da IA. A qualidade da saída, a eficiência de custos e o nível de risco de um sistema de IA precisam ser rastreados e otimizados por meio de métricas quantitativas. O princípio da "mensurabilidade de ponta a ponta" exige que cada decisão de IA gere dados de métricas observáveis em três dimensões: qualidade, custo e latência.

Uma arquitetura de observabilidade é a base para implementar esse princípio. Além do monitoramento de desempenho de aplicações tradicional (APM), um sistema de IA precisa de: rastreamento de consumo de token para registrar a contagem de token s de entrada e saída para cada solicitação e associá-la a cenários de negócios e centros de custo; pontuação de qualidade para realizar uma avaliação automatizada e multidimensional das saídas do modelo — relevância, precisão, integridade e segurança; e rastreamento de ponta a ponta em cenários de RAG e agent para registrar a cadeia de chamadas completa, desde a solicitação do usuário até a resposta final, incluindo resultados recuperados, saída bruta do modelo e modificações de pós-processamento.

Um mecanismo de contabilidade de token deve alocar os custos de inference de IA para departamentos de negócios e aplicações específicas, tornando a responsabilidade de custos rastreável. No Alibaba Cloud, use as estatísticas de uso no Model Studio combinadas com os recursos de armazenamento e consulta de logs do Log Service para criar um painel de consumo de token entre aplicações e entre modelos, permitindo o gerenciamento de custos de IA em granularidade fina.

Princípio 3: Autorização progressiva

Um sistema de IA recém-implantado não deve receber imediatamente permissões totais de produção e acesso de usuário. O princípio da "autorização progressiva" exige que as permissões e o escopo de um sistema de IA sejam expandidos gradualmente com base em sua confiabilidade demonstrada — primeiro validado em um ambiente controlado e, em seguida, exposto incrementalmente ao tráfego de produção.

Uma implantação em fases é o mecanismo central para praticar esse princípio. O Shadow mode é o primeiro estágio: o sistema de IA executa em paralelo com o processo existente, mas sua saída é registrada em log e não é executada. Os humanos comparam as decisões da IA com as decisões reais para coletar dados de qualidade. O Grayscale release é o segundo estágio: uma pequena quantidade de tráfego real (por exemplo, 5%) é roteada para o sistema de IA, com monitoramento rigoroso de métricas de qualidade e anomalias. A implantação total é o terceiro estágio: após a validação em escala cinza ser bem-sucedida, a porcentagem de tráfego é aumentada gradualmente até que o processo antigo seja completamente substituído.

A expansão graduada de permissões é adequada para cenários de agent. Um agent recém-lançado recebe apenas permissões de leitura. Após duas semanas consecutivas atendendo às metas de qualidade, ele ganha permissões de gravação. Após mais um mês de operação estável, ele recebe permissão para realizar operações de alto risco. Cada expansão de permissão é baseada em evidências de confiabilidade quantificáveis, e não em julgamento subjetivo.

Princípio 4: Conscientização de custos

Um orçamento de token não é uma reflexão tardia para a equipe financeira calcular no final do mês. É uma restrição de primeira classe que deve ser incorporada ao design arquitetônico desde o primeiro dia. O princípio da "conscientização de custos" exige que se defina um orçamento de token para cada tipo de solicitação durante a fase de design do sistema e que se implemente o controle dinâmico de custos em tempo de execução.

Um orçamento de custo por solicitação significa estabelecer um limite de consumo de token para diferentes tipos de solicitações de negócios. Por exemplo, uma consulta simples de FAQ pode ter um orçamento de token de 2.000 (entrada e saída combinadas), enquanto uma solicitação complexa de geração de relatórios pode ter um orçamento de 30.000. Quando o contexto de uma solicitação estiver prestes a exceder seu orçamento, o sistema deve acionar uma estratégia de degradação, como comprimir o contexto, truncar resultados de recuperação de baixa relevância ou rejeitar uma solicitação muito ampla e orientar o usuário a restringir seu escopo.

O model routing baseado em complexidade é um componente central de uma arquitetura consciente de custos. Ao realizar uma avaliação rápida da complexidade de uma solicitação (usando correspondência de palavras-chave, classificação de consultas históricas ou reconhecimento de intenção), solicitações de diferentes complexidades podem ser roteadas para modelos de diferentes níveis de custo. Em um AI gateway, configure o Qwen-Plus como o modelo de processamento padrão e escale apenas as solicitações avaliadas como de alta complexidade para o Qwen-Max. Isso alcança a otimização de custos sob restrições de qualidade.

Princípio 5: Conformidade integrada

Transforme a conformidade de uma lista de verificação pré-lançamento em um atributo intrínseco da arquitetura. O princípio da "conformidade integrada" exige que os requisitos regulamentares sejam incorporados ao design arquitetônico desde o primeiro dia, em vez de serem adicionados como uma camada extra após o desenvolvimento do sistema.

Integrar a filtragem de conteúdo desde o início do design arquitetônico significa que o fluxo de dados do sistema inclui naturalmente nós de moderação de conteúdo, em vez de depender de um desenvolvedor lembrando de adicioná-los manualmente antes da implantação. Ao criar uma aplicação de IA na plataforma Model Studio, a política de segurança de conteúdo deve ser um item de configuração obrigatório, e não opcional.

O registro de auditoria integrado significa que a entrada, a saída, a versão do modelo e os parâmetros de configuração de cada chamada de modelo são registrados persistentemente e associados a uma identidade de usuário. Isso atende aos requisitos regulamentares para os provedores de service reterem logs (por exemplo, por pelo menos seis meses). Esses logs não são informações de depuração opcionais e alternáveis, mas um componente indispensável da operação normal do sistema.

A integração do Algorithm Filing significa que a arquitetura é projetada com capacidades para gerenciamento de versão de modelo, procedência de dados de treinamento e geração de relatórios de avaliação de segurança. Quando uma auditoria exige materiais relevantes, o sistema pode gerar automaticamente a documentação técnica necessária, em vez de depender de engenheiros para compilá-la manualmente.