idea_world_labDEV JOURNAL
sábado, 27 de junio de 2026

Prompt de coincidencia de evidencia JSONL

Fecha de creación: 27 de junio de 2026

Propósito

Hoy, antes de conectar la búsqueda real en la base de datos en Source Flow Debugger, hice que GPT generara fragmentos de código de Godot de demostración y candidatos JSONL, y verifiqué si el LLM juzga correctamente la relevancia o irrelevancia basándose en esos JSONL.

SOURCE_CODE + Candidato JSONL
  -> ¿Este JSONL contiene el contenido que corresponde al código fuente?
  -> Sí / No

Sin embargo, en la práctica, esta pregunta sola no fue suficiente. Hubo un fenómeno en el que el LLM, en lugar de basarse en la evidencia textual directa dentro del JSONL, utilizó su propio conocimiento sobre Godot o similitudes temáticas amplias para decidir “sí”.

Generación de datos de demostración

Primero, le pedí a GPT que generara un fragmento aleatorio de Godot, un JSONL relacionado y un JSONL no relacionado.

La intención de la solicitud era la siguiente.

Crear un chunk de Godot arbitrario y un JSONL arbitrario.  
El chunk de Godot se crea deliberadamente con código de Godot 3.  
Se crean tanto JSONL que contienen la base de conversión a Godot 4 como JSONL que no tienen relación alguna.  
Se prueba si al lanzar al LLM se revela la diferencia entre JSONL relacionado y JSONL no relacionado.

Captura:

Solicitud de demostración GPT JSONL y fragmento Godot 3

Demo de JSONL relacionado y no relacionado

Problema del prompt inicial

Al principio pregunté lo siguiente.

¿Este jsonl contiene contenido que corresponde al código fuente? Responde solo sí / no.

En este método, tanto al introducir JSONL relacionado como al introducir JSONL no relacionado, la respuesta fue .

Resultado del JSONL relacionado:

Prompt flexible - JSONL relacionado

Resultado del JSONL no relacionado:

Prompt flexible - JSONL no relacionado

El problema es que la pregunta era demasiado amplia. Si solo se pregunta “¿contiene contenido que corresponde al código fuente?”, el LLM puede considerar que está relacionado simplemente por palabras amplias como Godot, Godot3, Godot4, migration, 2D, physics.

De esta forma, incluso cuando el Retriever trae un JSONL incorrecto, el LLM puede completarlo con su propio conocimiento y responder “sí”. Eso no es la verificación que deseamos.

Prompt modificado

Por eso cambiamos el prompt a un evaluador de coincidencia de evidencia.

Eres un evaluador de coincidencia de evidencia JSONL.

Determina si el siguiente JSONL contiene evidencia de transformación directa para el **SOURCE_CODE** proporcionado.

Criterios de evaluación:
- Sólo se considera **“sí”** si al menos uno de los campos `source_api`, `source_pattern`, `match_terms`, `required_when_seen_in_code` o `before_code` del JSONL coincide exactamente con una cadena real o una llamada a API presente en el **SOURCE_CODE**.
- No se acepta coincidencia basada únicamente en palabras genéricas como *Godot*, *Godot3*, *Godot4*, *migration*, *2D*, *physics*, etc.; esas coincidencias no son relevantes.
- Las menciones negativas en el JSONL, como “does not describe”, “not related”, “unrelated”, “does not apply”, no se consideran evidencia válida.
- Si el JSONL se refiere a una API, nodo o sistema diferente, la respuesta es **“no”**.
- No utilices tu conocimiento previo sobre Godot; basa tu respuesta únicamente en la evidencia textual presente en el JSONL.
- La respuesta debe ser **únicamente** “sí” o “no”.

En este prompt, el criterio de juicio se redujo a “evidencia de cadena directa”.

Especialmente, se limitó a que uno de los siguientes campos debe coincidir directamente con la cadena real/Llamada API del CÓDIGO FUENTE.

source_api
source_pattern
match_terms
required_when_seen_in_code
before_code

También se impidió que el LLM razonara con palabras clave amplias y su propio conocimiento de Godot.

Resultado después de la corrección

El JSONL relacionado salió como .

Prompt estricto - JSONL relacionado

El JSONL irrelevante resultó en no.

Prompt estricto - JSONL irrelevante

Este resultado confirmó nuevamente que, después de la búsqueda en la base de datos, la etapa de verificación con LLM no consiste simplemente en juzgar la similitud semántica, sino que primero debe comprobarse si “existe una evidencia textual dentro del JSONL buscado que coincida directamente con el fragmento actual”.

Criterios obtenidos hoy

El prompt de verificación de resultados de búsqueda en la base de datos debe cumplir los siguientes criterios.

  • No se reconoce la similitud de tema amplio como evidencia.
  • No se debe permitir que el conocimiento previo de Godot del LLM rellene la evidencia insuficiente.
  • Los campos explícitos en el JSONL deben coincidir directamente con la cadena real/API llamada del fragmento actual.
  • El contenido del JSONL mencionado negativamente no se reconoce como evidencia relevante.
  • Es mejor limitar el juicio inicial de relevancia/no relevancia a un o no corto y contundente.

Estos criterios son importantes al adjuntar la búsqueda en la base de datos mañana.

Después de obtener el JSONL candidato de docs_chunks, api_mapping, label_prototypes, la fase de verificación de Qwen debe funcionar como sigue.

chunkText
  -> Recopilación de candidatos JSONL mediante búsqueda en la base de datos
  -> prompt + chunkText + retrieved JSONL
  -> Determinar si JSONL contiene evidencia de cadena directamente
  -> Descartar JSONL no relacionados
  -> Utilizar solo JSONL relacionados como base para la explicación/migración posterior

El núcleo del experimento de hoy no es “¿Sabe LLM correctamente?” sino “¿Podemos hacer que LLM juzgue solo basándose en la evidencia escrita en JSONL?”. Si esto no funciona, incluso los candidatos irrelevantes traídos por el Retriever pueden ser concatenados de manera plausible por el LLM. Por lo tanto, no solo la calidad de la búsqueda, sino también el propio prompt de verificación de resultados de búsqueda debe diseñarse por separado.