Prompt de Observação de Correspondência de Evidência JSONL
Data de criação: 27 de junho de 2026
Propósito
Hoje, antes de conectar a pesquisa real no banco de dados no Source Flow Debugger, fiz o GPT gerar um trecho de código Godot de demonstração e candidatos JSONL, e verifiquei se o LLM avalia corretamente a relevância ou irrelevância com base nesses JSONL.
SOURCE_CODE + JSONL candidato
-> Este JSONL contém o conteúdo que corresponde ao código-fonte?
-> Sim / NãoMas, na prática, isso não foi suficiente. Houve um caso em que o LLM, em vez de usar a evidência direta em forma de string dentro do JSONL, utilizou seu próprio conhecimento sobre o Godot ou similaridades amplas de tópico para decidir que a resposta era “sim”.
Geração de Dados de Demonstração
Primeiro, pedimos ao GPT que criasse um chunk arbitrário do Godot junto com um JSONL relacionado e um JSONL irrelevante.
A intenção da solicitação era a seguinte.
Cria um chunk arbitrário do Godot e um JSONL arbitrário.
O chunk do Godot é deliberadamente feito em código Godot 3.
O JSONL cria tanto um que contém a base da conversão para Godot 4 quanto outro que não tem nenhuma relação.
Testa se, ao ser enviado para um LLM, a diferença entre o JSONL relevante e o JSONL irrelevante se torna evidente.Captura:


Problema do prompt inicial
No início, eu perguntei assim.
Isso jsonl contém conteúdo que corresponde ao código‑fonte? Responda apenas com **sim** / **não**.Neste método, ao inserir JSONL relevante, também aparece sim, e ao inserir JSONL irrelevante, também apareceu sim.
Resultado JSONL relevante:

Resultado JSONL irrelevante:

O problema é que a pergunta era muito ampla. Se você perguntar apenas “O conteúdo corresponde ao código‑fonte?”, o LLM pode considerar relevante apenas ao ver palavras amplas como Godot, Godot3, Godot4, migration, 2D, physics.
Assim, mesmo que o Retriever traga um JSONL inadequado, o LLM pode preenchê‑lo com seu próprio conhecimento e responder “sim”. Isso não é a verificação que desejamos.
Prompt modificado
Portanto, alteramos o prompt para um avaliador de correspondência de evidências.
Você é um avaliador de correspondência de evidências JSONL.
Determine se o JSONL abaixo contém evidência direta de conversão para o SOURCE_CODE abaixo.
Critérios de avaliação:
- É necessário que um dos campos source_api, source_pattern, match_terms, required_when_seen_in_code ou before_code do JSONL corresponda exatamente a uma string real ou chamada de API dentro do SOURCE_CODE para que a resposta seja "sim".
- Palavras genéricas como Godot, Godot3, Godot4, migration, 2D, physics não são consideradas relevantes.
- Conteúdos negativamente mencionados no JSONL, como "does not describe", "not related", "unrelated", "does not apply", não são reconhecidos como evidência relevante.
- Se o JSONL tratar de outra API, outro nó ou outro sistema, a resposta é "não".
- Não use seu conhecimento prévio sobre Godot; utilize apenas as evidências textuais presentes no JSONL.
- A resposta deve ser apenas "sim" ou "não".Neste prompt, o critério de julgamento foi restringido a “evidência de string direta”.
Especialmente, limitou‑se que um dos campos a seguir deve corresponder diretamente à string real/chamada de API do SOURCE_CODE.
source_api
source_pattern
match_terms
required_when_seen_in_code
before_codeTambém impediu que o LLM inferisse usando palavras‑chave amplas e seu conhecimento prévio de Godot.
Resultado após a correção
O JSONL relacionado saiu como sim.

O JSONL irrelevante saiu como não.

Com esse resultado, confirmamos novamente que a etapa de validação do LLM após a busca no banco de dados não deve ser apenas uma avaliação de similaridade semântica, mas sim verificar primeiro se “há uma evidência textual dentro do JSONL encontrado que corresponda diretamente ao chunk atual”.
Critérios obtidos hoje
O prompt de validação dos resultados da busca no banco de dados deve atender aos seguintes critérios:
- Similaridade temática ampla não é aceita como evidência.
- Não se deve permitir que o LLM preencha lacunas usando seu conhecimento prévio de Godot.
- O campo explícito no JSONL deve corresponder diretamente ao texto real/API call do chunk atual.
- Conteúdos do JSONL mencionados negativamente não são aceitos como evidência relevante.
- A primeira avaliação de relevância/irrelevância deve ser curta e enfática, limitada a
simounão.
Esses critérios serão importantes quando adicionarmos a busca no banco de dados amanhã.
Depois de obter os JSONLs candidatos de docs_chunks, api_mapping e label_prototypes, a etapa de validação do Qwen deve funcionar da seguinte forma.
chunkText
-> Coleta de candidatos JSONL por busca no DB
-> prompt + chunkText + JSONL recuperado
-> Determina se há evidência de string diretamente no JSONL
-> JSONL não relacionados são descartados
-> Apenas JSONL relacionados são usados como base para julgamento de explicação/migração subsequenteO ponto central do experimento de hoje não era “se o LLM sabe corretamente”, mas sim “se é possível fazer o LLM julgar apenas com base nas evidências escritas em JSONL”. Se isso não funcionar, o LLM poderá concatenar de forma plausível até mesmo candidatos irrelevantes trazidos pelo Retriever. Portanto, além da qualidade da busca, o próprio prompt de verificação dos resultados da busca também precisa ser projetado separadamente.