Comece pelo caso de uso e pela avaliação
Defina a tarefa, quem é afetado por uma resposta errada, qual conteúdo pode ser enviado e como a qualidade será avaliada. Monte um conjunto representativo de entradas e respostas esperadas ou critérios de revisão humana. Meça qualidade, latência, custo e taxa de recusa antes de liberar mudanças de modelo ou prompt.
Modelos são probabilísticos: exemplos isolados não provam confiabilidade. Combine avaliações automatizadas com revisão humana para decisões de impacto significativo.
Separe o domínio do provedor de modelo
Coloque a chamada ao provedor atrás de uma abstração pequena da aplicação, injete-a no caso de uso e mantenha segredos na configuração protegida do ambiente. Isso permite aplicar timeout, cancelamento, métricas e limites de custo em um ponto claro e substituir implementação sem espalhar SDKs pelo domínio.
Ecossistemas .NET oferecem bibliotecas e abstrações que evoluem rapidamente. Confira documentação e compatibilidade da versão escolhida antes de depender de uma API específica; isole o SDK no adaptador e não copie chaves para exemplos, logs ou repositório.
RAG: buscar contexto antes de gerar
Retrieval-Augmented Generation (RAG) recupera documentos relevantes e os fornece como contexto ao modelo. Um fluxo comum inclui ingestão e divisão de documentos, criação de embeddings, busca por relevância, autorização para acessar fontes, montagem de contexto e geração de resposta com referências.
RAG não garante resposta correta. Avalie qualidade da recuperação, atualidade, filtros por permissão, citações e comportamento quando não há evidência suficiente. Uma busca excelente não compensa documentos errados ou acesso indevido.
Ferramentas e saída estruturada
Um modelo pode sugerir uma chamada de ferramenta ou produzir JSON, mas a aplicação continua responsável por validar argumentos, autenticar o usuário e autorizar cada ação. Trate o resultado como entrada não confiável: valide schema, limites e estado atual antes de executar qualquer operação.
Ferramentas devem ter privilégio mínimo, escopo explícito e confirmação humana para efeitos relevantes. Nunca transforme texto gerado em SQL, comandos de shell ou chamadas arbitrárias sem validação e controle rigorosos.
Segurança, privacidade e injeção de prompt
Instruções maliciosas podem aparecer na mensagem do usuário ou em documentos recuperados. Prompt injection não se resolve apenas com uma instrução no system prompt. Separe dados de instruções, limite ferramentas, valide saídas fora do modelo, faça checagens de autorização no servidor e evite conceder acesso direto a dados ou ações amplas.
Classifique dados, avalie retenção e uso pelo fornecedor, aplique redaction quando necessário e controle acesso a prompts e respostas em logs. Informe ao usuário quando uma saída é gerada e mantenha supervisão apropriada ao risco.
Streaming, resiliência e custo
Streaming melhora a percepção de latência, mas a resposta parcial ainda pode falhar no meio. Defina cancelamento quando o cliente desconectar, timeouts, limites de tokens, concorrência e quotas. Faça retries apenas quando apropriado; uma geração repetida pode custar mais e produzir outra resposta. Meça tokens, latência, erros, limites e uso por funcionalidade sem registrar conteúdo sensível desnecessariamente.
Veja resiliência para políticas contra falhas e observabilidade para medir o sistema em produção.
Quando não usar um LLM
Se uma regra determinística, busca tradicional ou fluxo de formulário resolve o problema com menor custo e resultado verificável, prefira essa solução. LLM pode complementar recuperação e interação, mas não deve ser introduzido como camada obrigatória sem benefício demonstrável.
Para estruturar dependências e limites, veja Clean Architecture e arquitetura hexagonal. Para publicar mudanças em produção, consulte também Docker para .NET.