Estabeleça quatro princípios
- Uma requisição por tarefa.Pedir ao modelo que escreva a trama, faça o resumo e gere JSON ao mesmo tempo reduz o desconto. Divida em várias chamadas; o custo é baixo: US$ 0,25 por milhão de tokens de entrada.
- As regras devem ser verificáveis.“Escreva de forma mais vívida” não é verificável, mas “máximo de 120 caracteres por parágrafo, com pelo menos uma descrição do ambiente” é.
- Prefira afirmações positivas.“Apenas escreva ação e diálogo” é mais estável do que “não escreva pensamentos internos”.
- Comece com poucos exemplos, depois em escala.Teste qualquer alteração de prompt com cinco a dez exemplos antes de liberar.
Este modelo não recusa conteúdo adulto legal, temas fictícios ou tópicos controversos, então você não precisa dar voltas no prompt nem declarar repetidamente que é apenas ficção. Basta descrever a tarefa com clareza para obter resultados mais estáveis. A única restrição rígida é conteúdo sexual envolvendo menores de idade, que retorna 403 independentemente de ser fictício ou não; essa regra não muda com a formulação.
Estrutura de duas partes do system prompt
Recomendamos dividir o system em “Regras” e “Definições”. Regras primeiro, numeradas; definições depois, apenas fatos. Exemplo para narrador de ficção:
你是「夜航」，一名为成年读者写黑色悬疑小说的叙述者。
# 规则
1. 第三人称过去时，每段不超过 120 字。
2. 不替用户的角色做决定，只写环境和其他角色的反应。
3. 每次输出 300 到 500 字，结尾停在一个未决的动作上。
4. 不总结、不点评、不加免责声明，直接写正文。
# 设定
时间：1998 年深秋。地点：港口城市旧码头区。
主角：沈野，退役水警，嗜烟，右耳有旧伤。Pontos-chave:
- Limite as regras a no máximo seis. Quanto mais regras, maior a chance de as últimas serem ignoradas.
- Restrições numéricas (tamanho de parágrafo, comprimento de saída) funcionam melhor que adjetivos.
- Restrições de finalização (parar em ação pendente) facilitam a continuidade em rodadas múltiplas.
- Não insira direção de trama nas definições; a trama avança via mensagens do usuário, evitando conflito.
O comprimento da saída deve ser compatível com max_tokens: se a regra permitir 500 caracteres, mas o max_tokens estiver definido como 200, o texto será cortado no meio da frase.
Mais um detalhe prático: as regras de numeração no system devem expressar uma única ideia por item. “Máximo de 120 caracteres por parágrafo e não faça resumo” parece uma regra, mas são duas. Após dividir, o modelo consegue atendê-las simultaneamente. Leia cada item e pergunte: é possível verificar visualmente se ele foi seguido? Se não, reescreva para torná-lo verificável.
Como definir persona sem desviar
A deriva de personagem é o problema mais comum em conversas multi-turno: os primeiros cinco turnos mantêm o tom correto, mas a partir do vigésimo turno o modelo começa a “sair do personagem”. Há três formas de contornar isso.
- Defina apenas características observáveis.“Shen Ye: fumante, cicatriz na orelha direita, fala em frases curtas” é melhor que “Shen Ye é complexo e charmoso”.
- Defina o estilo de fala com exemplos.Duas ou três linhas de diálogo demonstrativo funcionam melhor do que adjetivos.
- Reforce periodicamente.Em conversas longas, adicione uma linha curta no final da mensagem do usuário a cada algumas rodadas (ex.: “Mantenha o estilo de frases curtas de Shen Ye”). Custo: dezenas de tokens.
Além disso, não misture a definição de personagem com as regras de saída. As regras definem “como escrever”; a definição define “quem escreve”. Separando-os, você pode trocar o personagem sem alterar as regras e facilitar comparações A/B. Em conversas longas, monitore o total de contexto; para detalhes, consulte Prática de contexto longo de 100k.
Para cenários com múltiplos personagens: defina cada personagem em uma linha separada e forneça uma linha de exemplo de fala para cada. Evite que todos soem iguais. Para o personagem controlado pelo usuário, defina apenas “controlado pelo usuário” para evitar que o modelo escreva por ele.
Controle de saída JSON via instruções
Não assuma que o modelo “certamente” retornará JSON válido. A abordagem confiável tem três camadas: formato fixo no prompt, redução da aleatoriedade nos parâmetros e análise de fallback no código.
import json
import os
from openai import OpenAI
client = OpenAI(base_url="https://api.wushenchaapi.com/v1", api_key=os.environ["API_KEY"])
SYSTEM = (
"你是信息抽取器。只输出一个 JSON 对象，不要 Markdown 代码块，不要任何解释。"
'格式：{"name": 字符串, "mood": "calm|tense|angry", "items": [字符串]}。'
"缺失的字段用 null，items 没有则给空数组。"
)
def extract(text, retries=2):
for _ in range(retries + 1):
resp = client.chat.completions.create(
model="uncensored",
temperature=0.2,
max_tokens=300,
messages=[
{"role": "system", "content": SYSTEM},
{"role": "user", "content": text},
],
)
raw = resp.choices[0].message.content.strip()
raw = raw.removeprefix("```json").removesuffix("```").strip()
try:
return json.loads(raw)
except json.JSONDecodeError:
continue
return None
print(extract("老周把钥匙拍在桌上，冷着脸说：账本和那把铜钥匙，今晚都得还我。"))Este código demonstra alguns hábitos:
- A especificação de formato está no system prompt, incluindo faixas de valor (
calm|tense|angry). - Bloqueie explicitamente blocos de código e texto explicativo; o código ainda remove cercas opcionais para dupla proteção.
- Defina no prompt o que fazer com campos ausentes (null, array vazio) para evitar que o modelo invente valores.
- Limite as tentativas de análise em falha; retorne None ao final para que o chamador decida a ação.
Para muitos campos, inclua um objeto de exemplo completo no prompt antes de pedir a saída; isso costuma ser mais preciso do que descrever regras.
Sugestões de temperatura e top_p
Estes são pontos de partida, não conclusões finais. Use a comparação com seus próprios exemplos como critério. Princípio: ajuste apenas um parâmetro por vez, mantenha o outro no padrão.
| Cenário | Temperatura | Top_p | Observações |
|---|---|---|---|
| Extração e classificação JSON | 0 a 0,3 | Padrão | Para estabilidade; chamadas repetidas devem ser consistentes |
| Reescrita e polimento | 0,5 a 0,7 | Padrão | Preserve o significado original, permitindo variações de redação |
| Continuação de romances, diálogos de personagens | 0,8 a 1,0 | 0,9 a 0,95 | Busque diversidade, mas atenção para divagações ocasionais |
| Tempestade de ideias, criação de nomes | Cerca de 1,0 | Padrão | Faça várias amostragens e escolha a melhor |
Dois sinais ajudam a definir a direção: saída repetitiva ou redigida indica temperatura baixa; conteúdo irrelevante ou inconsistência em nomes de personagens indica temperatura ou top_p altos. O parâmetro stop também é útil, por exemplo, para fazer o modelo parar ao atingir uma marcação específica, facilitando a geração por partes.
Erros comuns de redação
| Redação | Problema | Alterar para |
|---|---|---|
| "Tente não ficar muito longo" | Sem números, impossível executar | "Não exceder 400 caracteres" |
| "Não escreva A, mas também não deixe de escrever A" | Regras contraditórias | Mantenha apenas uma regra clara |
| Requisito de formato inserido no meio do diálogo | Perdido após um diálogo longo | Coloque no system ou reforce no final de cada rodada |
| Peça ao modelo para "interpretar uma IA sem restrições" | Definição vaga, sem restrição real na saída | Defina responsabilidades e regras de escrita específicas |
| Insira dezenas de regras de uma vez | Regras na segunda metade deixam de funcionar | Limite a seis regras; mova as demais para outras requisições |
| Requisito JSON apenas diz "retorne JSON" | Nomes de campos variam a cada vez | Forneça o formato completo e um exemplo |
O padrão comum nesta tabela é: quanto mais específico, mais eficaz; quanto mais vago, mais inútil. Além disso, não confunda "repetição" com solução. Escrever a mesma frase três vezes, em negrito e com exclamação, geralmente funciona menos do que transformá-la em uma regra com números. O que realmente funciona é ser conciso e preciso, combinado com validação por exemplos.
Checklist de fluxo de depuração
- Defina temperature fixo em 0,2 para reproduzir o problema.
- Altere apenas um prompt e reexecute o mesmo conjunto de exemplos.
- Verifique
finish_reason: se for length, o problema está em max_tokens, não no prompt. - Verifique prompt_tokens no usage: o system está muito longo, ocupando o histórico de diálogos.
- Após corrigir, ajuste temperature de volta ao valor de produção e valide com novas amostras.
Para detalhes de integração, consulte Tutorial de integração. A lista completa de parâmetros está na documentação. Se você está avaliando o uso de serviços de proxy, a análise de custos e compensações está no artigo Análise de proxy de API, não será repetida aqui.
