hh.ru explicou como projetar prompts de produção para serviços de AI sem surpresas

A hh.ru compartilhou uma prática sobre como escrever prompts para seus serviços de IA em produção. A ideia principal é simples: um prompt em um produto não é uma conversa com um chatbot, mas um sistema de engenharia com restrições, testes e ajustes constantes.

Produção não é Chat

No uso típico de LLM, tudo é bem flexível: um usuário faz uma pergunta, obtém uma resposta, refina a formulação, reinicia o diálogo e segue adiante. Em um produto, não há esse luxo. Aqui, uma resposta fracassada pode alcançar milhares de usuários, quebrar um cenário, criar um risco reputacional ou simplesmente piorar a conversão.

Portanto, um prompt em produção não é uma única frase como "deixe bonito", mas um conjunto de instruções interconectadas, dados, regras e chamadas de ferramentas, às vezes abrangendo centenas de linhas. O autor do artigo chama isso de batalha de um engenheiro contra um "papagaio estocástico". O modelo não compreende significado da forma como os humanos fazem; prevê o próximo token com base em probabilidades.

A tarefa da equipe é maximizar a redução do espaço de aleatoriedade: dar ao modelo um papel claro, contexto, restrições e formato de resposta esperado. Quanto melhor esse loop for projetado, maior a chance de obter um resultado previsível, seguro e útil para o negócio real. É por isso que trabalhar com prompts cada vez mais se assemelha ao desenvolvimento regular, em vez de um experimento criativo.

O Framework de um Bom Prompt

Na hh.ru, eles recomendam escrever as instruções em inglês, enquanto deixam exemplos de mensagens de usuários no idioma do produto — neste caso, russo. A razão não é apenas que instruções em inglês são frequentemente interpretadas com mais precisão pelo modelo. O inglês também economiza tokens, e em sistemas com milhares e milhões de chamadas, isso já afeta custo e latência. Modelos e marcação ajudam adicionalmente: markdown ou XML tornam instruções longas mais estruturadas e reduzem ambiguidade. Um framework típico geralmente inclui o papel do modelo, objetivo, contexto, etapas de resolução de problemas e formato de resposta.

• papel do modelo
• objetivo e tarefa específica
• contexto dos dados de entrada
• algoritmo de ação ou etapas de verificação
• restrições e formato de resposta

Exemplos few-shot são particularmente arriscados. Eles realmente ajudam o modelo a entender melhor a tarefa, mas tão facilmente se transformam em um modelo que ele começa a transferir mecanicamente para novas situações. O modelo frequentemente se apega às formulações literalmente e as reproduz fora de contexto. O artigo fornece um caso ilustrativo: eles adicionaram um exemplo de pergunta esclarecedora para um candidato ao prompt do sistema, após o qual o agente começou a fazê-la até onde era completamente inadequado.

"Você está pronto para viagens de negócios para Ryazan?"

Depois disso, o assistente periodicamente perguntava sobre viagens até em ofertas de emprego onde viagens não eram necessárias.

A conclusão da equipe é rigorosa: tudo arriscado deve ser explicitamente proibido. Se um bot não deve discutir outras empresas, expressar sua opinião, sair do tópico ou realizar tarefas não relacionadas, isso precisa ser declarado explicitamente. Outra dica prática é não temer prompts longos se forem montados logicamente e não se contradizerem. Também é importante passar explicitamente a data atual, ajustar cuidadosamente a temperatura e lembrar que prompts quase sempre precisam ser reescritos para diferentes modelos.

Como Eles Testam

Mesmo um bom prompt não pode ser considerado pronto após alguns testes bem-sucedidos. O comportamento de LLM não é totalmente determinístico: com solicitações idênticas e parâmetros idênticos, as respostas ainda podem variar ligeiramente. Portanto, a garantia de qualidade é mais como uma avaliação de engenharia de um sistema do que uma revisão de texto manual. Você precisa de grandes conjuntos de casos de teste, múltiplas execuções e cobertura de diferentes cenários de usuário — quase como em testes clássicos, mas com ajustes para a natureza probabilística do modelo.

A fonte mais valiosa de novos testes são os logs reais dos usuários. É lá que surgem perguntas inesperadas, tentativas de desviar o bot e casos extremos que a equipe não antecipou. Conforme esses casos se acumulam, o conjunto de dados de avaliação precisa ser constantemente reabastecido. Outra descoberta importante: prompts devem ser testados em um ambiente o mais próximo possível da produção. LLMs são sensíveis até mesmo a pequenas alterações no formato de entrada, então um ambiente "quase idêntico" facilmente dá falsa confiança em estabilidade.

O Que Isso Significa

O artigo da hh.ru demonstra bem que engenharia de prompt está rapidamente se transformando em engenharia de produto regular. Aqui, a vitória vai não para o pedido mais criativo, mas para uma combinação de estrutura, restrições, avaliações, logs e refinamento iterativo. Para equipes construindo recursos de IA em produção, este é um sinal: prompts agora precisam ser versionados, testados, rastreados por métricas, vinculados a cenários reais de usuários e adaptados a modelos específicos tão seriamente quanto código.