Un autor publica en GitHub un prompt de investigación y pide que le rompan el método
Se llama Research Pass, va por la versión 1.0 y llega con un benchmark de diez casos y un protocolo de pruebas para que otros encuentren dónde falla.
Alguien ha publicado en GitHub un prompt llamado Research Pass, en su versión 1.0, y en lugar de venderlo pide que se lo destrocen. No busca respuestas mejores, sino forzar al modelo a seguir un protocolo de investigación: formular la pregunta de fondo, anotar la creencia de partida, generar explicaciones rivales, buscar contraevidencia y separar lo que es evidencia de lo que es interpretación.
Qué hace distinto
La idea de partida es que el uso habitual de un LLM para investigar cae siempre en el mismo patrón: pregunta, unas cuantas búsquedas, resumen y respuesta. El Research Pass mete pasos intermedios. Entre ellos: rastrear de dónde salen las afirmaciones populares, comprobar si varias fuentes son realmente independientes, mirar por qué fuentes creíbles discrepan, distinguir descubrir una idea de demostrarla, declarar el nivel de confianza y la incertidumbre que queda, y parar cuando seguir buscando ya no cambiaría la decisión. La interfaz es una sola línea:
Research Pass this: [whatever you want to understand]
En el repositorio hay además un benchmark inicial de diez casos, una plantilla de informe de fallos, un protocolo de pruebas y el historial de versiones. No es solo el texto del prompt: viene con la infraestructura para que otros lo evalúen.
Cómo pide que se pruebe
El método que propone es sencillo: la misma pregunta en dos conversaciones nuevas con el mismo modelo, una sin nada y otra con el prompt cargado, y comparar. Lo que quiere encontrar no son elogios, sino los casos en los que el método pierde: preguntas donde el modelo sin prompt lo hace mejor, premisas falsas que no detecta, alucinaciones, elección de fuentes mala, investigación innecesaria, paradas prematuras o tardías, dominios donde la metodología no transfiere, secciones que parecen aportar y no aportan, y modificaciones que mejoran una cosa y rompen otra.
Pide probar la versión canónica antes de tocar nada y, después, bifurcar el repositorio, acortarlo, reescribir secciones o adaptarlo a otro modelo, con la condición de explicar qué casos mejora la variante y qué empeora.
El autor no presenta esto como una solución cerrada, y con razón: no hay mediciones publicadas, solo un marco de trabajo y una petición de colaboración. La parte que importa técnicamente es si un protocolo escrito en lenguaje natural se comporta igual en modelos distintos y en manos de personas distintas. Los casos de fallo que salgan del benchmark valen más que el prompt en sí.
