Establece cuatro principios
- Una petición, un tarea.Pedir al modelo que escriba una trama, haga un resumen y genere JSON a la vez hace que todo pierda calidad. Divídelo en varias llamadas; el costo es bajo: $0.25 por millón de tokens.
- Las reglas deben ser verificables.«Escribe con más estilo» no se puede verificar, pero «máximo 120 caracteres por párrafo, con al menos una descripción del entorno» sí.
- Prefiere la formulación positiva.Decir "solo escribe acción y diálogo" es más estable que "no escribas pensamientos internos".
- Prueba con pocos ejemplos antes de escalar.Para cualquier cambio en el prompt, compara con 5-10 ejemplos antes de lanzarlo.
Este modelo no rechaza contenido adulto legal, ficción o temas controvertidos, así que no necesitas rodeos ni repetir «es solo una novela». Escribe la tarea con claridad para mayor estabilidad. La única restricción estricta es el contenido sexual con menores (403), que no se puede cambiar con la redacción.
Estructura de dos partes del system prompt
Recomendamos dividir el system en "Reglas" y "Definiciones": reglas primero y numeradas, definiciones después con solo hechos. Ejemplo para narrador de novela:
你是「夜航」，一名为成年读者写黑色悬疑小说的叙述者。
# 规则
1. 第三人称过去时，每段不超过 120 字。
2. 不替用户的角色做决定，只写环境和其他角色的反应。
3. 每次输出 300 到 500 字，结尾停在一个未决的动作上。
4. 不总结、不点评、不加免责声明，直接写正文。
# 设定
时间：1998 年深秋。地点：港口城市旧码头区。
主角：沈野，退役水警，嗜烟，右耳有旧伤。Puntos clave:
- Máximo seis reglas; las posteriores suelen ignorarse si hay demasiadas.
- Las restricciones numéricas (longitud de párrafo) son más efectivas que los adjetivos.
- Las restricciones de finalización (detenerse en una acción pendiente) facilitan la continuidad en múltiples turnos.
- No incluyas la trama en las definiciones; la avanza el usuario, o entrarán en conflicto con sus entradas.
Ajusta la longitud de salida a max_tokens: si la regla pide 500 caracteres y max_tokens es 200, se cortará en medio de la frase.
Detalle práctico: cada regla numerada debe expresar una sola idea. "Máximo 120 caracteres y no resumas" son dos reglas. Léelas y pregúntate: ¿se puede verificar visualmente si se cumple?
Cómo definir roles sin desviaciones
La deriva de personaje es común: el tono es correcto al inicio pero se pierde tras muchas rondas. Tres soluciones:
- Define solo características observables."Shen Ye: fumador, cicatriz en la oreja derecha, habla en frases cortas" es mejor que "es complejo y carismático".
- Escribe el estilo de habla con ejemplos.Proporciona 2-3 líneas de diálogo; el modelo imita mejor los ejemplos que entiende adjetivos.
- Reafirma periódicamente.En diálogos largos, añade una breve nota al final de los mensajes del usuario (ej. "Mantén estilo de frases cortas"). Costo: decenas de tokens.
No mezcles definiciones de personaje con reglas de salida. Las reglas son "cómo escribir", las definiciones son "quién escribe". Esto permite cambiar roles sin tocar reglas y facilita pruebas A/B. Para diálogos largos, vigila la ventana de contexto; consultaGuía práctica de 100k tokens.
Para múltiples personajes: una línea de definición por personaje, un ejemplo de estilo por personaje. Evita que todos hablen igual. Para el personaje del usuario, indica "controlado por el usuario" para que el modelo no escriba por él.
Control de salida JSON con instrucciones
No asumas que el modelo devolverá JSON válido siempre. Usa tres capas: formato fijo en instrucciones, baja aleatoriedad en parámetros y fallback en 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 muestra varias buenas prácticas:
- La descripción del formato va en el system, con rangos de valores (
calm|tense|angry). - Prohíbe bloques de código y explicaciones; el código también elimina posibles marcadores de contenedor para doble seguridad.
- Define valores por defecto para campos faltantes (null, array vacío) en las instrucciones para evitar que el modelo invente datos.
- Limita los reintentos de análisis; devuelve None si falla para que el llamador decida.
Si hay muchos campos, incluye un objeto de ejemplo completo en el prompt; suele ser más preciso que describir reglas.
Recomendaciones de temperature y top_p
Estos son puntos de partida, no verdades absolutas. Verifica con tus propios ejemplos. Principio: modifica un parámetro a la vez, mantén el otro por defecto.
| Escenario | temperature | top_p | Notas |
|---|---|---|---|
| Extracción y clasificación de JSON | 0 a 0.3 | Por defecto | Para estabilidad; los resultados deben ser consistentes en llamadas repetidas |
| Reescritura y pulido | 0.5 a 0.7 | Predeterminado | Preservar el significado original, permitiendo variaciones en la redacción |
| Continuación de novelas, diálogos de personajes | 0.8 a 1.0 | 0.9 a 0.95 | Busca diversidad, ten cuidado con las divagaciones ocasionales |
| Lluvia de ideas, creación de nombres | Alrededor de 1.0 | Predeterminado | Muestreo múltiple y selección de la mejor opción |
Dos señales te ayudan a orientarte: si la salida es repetitiva y usa siempre la misma estructura, la temperatura es baja; si aparecen contenidos irrelevantes o hay inconsistencia en los nombres de personajes, la temperatura o el top_p son altos. El parámetro stop también es muy útil, por ejemplo, para detener el modelo al llegar a un marcador, facilitando la generación por segmentos.
Errores comunes de redacción
| Redacción | Problema | Cambio a |
|---|---|---|
| "Intenta no hacerlo muy largo" | Sin números, imposible de ejecutar | "No más de 400 palabras" |
| "No escribas A, pero tampoco dejes de escribir A" | Reglas contradictorias | Mantén solo una regla clara |
| La solicitud de formato está entremezclada con el diálogo | Se pierde tras un diálogo largo | Colócala en el system o repítela al final de cada turno |
| Pedirle al modelo que "actúe como una IA sin restricciones" | Configuración vaga, sin restricciones reales para la salida | Define responsabilidades y reglas de escritura concretas |
| Inyectar decenas de reglas de golpe | Las reglas del final dejan de aplicarse | Reduce a menos de seis reglas y mueve el resto a otras peticiones |
| La solicitud de JSON solo dice "devuelve JSON" | Los nombres de los campos varían cada vez | Proporciona el formato completo y un ejemplo |
El patrón común de esta tabla es: cuanto más específico, más efectivo; cuanto más vago, menos útil. Además, no confundas "repetir" con la solución: escribir la misma frase tres veces, en negrita y con signos de exclamación suele ser menos efectivo que convertirla en una regla con números. Lo realmente útil es ser breve y preciso, y verificar con ejemplos.
Lista de verificación para depuración
- Fija temperature en 0.2 para reproducir el problema.
- Modifica solo un prompt y vuelve a ejecutar el mismo conjunto de ejemplos.
- Revisa el
finish_reason: si es length, el problema está en el max_tokens y no en el prompt. - Revisa los prompt_tokens en usage: si el system es demasiado largo, está ocupando el espacio de la conversación histórica.
- Una vez corregido, vuelve a ajustar la temperatura al valor de producción y vuelve a muestrear para verificar.
Para detalles de integración, consulta la guía de integración; la lista completa de parámetros está en la documentación. Si estás evaluando si usar servicios de proxy, el análisis de costos y compensaciones está en Análisis de estaciones de proxy de API, no se repite aquí.
