Наблюдение за запросом сопоставления доказательств JSONL

Дата создания: 27 июня 2026 г.

Цель

Сегодня, перед тем как добавить реальный поиск в базе данных в Source Flow Debugger, я попросил GPT создать демонстрационный кусок кода Godot и кандидаты JSONL, а затем проверил, правильно ли LLM определяет их релевантность/нерелевантность, опираясь на этот JSONL.

Первоначальная мысль была простой.

SOURCE_CODE + JSONL кандидат
  -> Этот JSONL содержит содержание, соответствующее исходному коду?
  -> Да / Нет

Однако на самом деле этого вопроса было недостаточно. Было явление, когда LLM, вместо того чтобы опираться на прямые строковые доказательства в JSONL, использовал свои собственные знания о Godot или широкую тематическую схожесть, чтобы решить, что ответ «да».

Создание демонстрационных данных

Сначала я попросил GPT сгенерировать произвольный chunk Godot и связанные JSONL, а также несвязанные JSONL.

Цель запроса была следующей.

Создаём произвольный кусок Godot и произвольный JSONL.  
Кусок Godot специально делаем на коде Godot 3.  
JSONL создаём как содержащий основания для преобразования в Godot 4, так и совершенно не связанный с этим.  
Тестируем, проявится ли разница между связанным и несвязанным JSONL, когда бросаем их LLM.

Снимок:

Запрос демо GPT JSONL и кусок Godot 3

Связанное JSONL и несвязанное JSONL демо

Проблема начального запроса

Сначала я спросил так:

Это jsonl содержит содержимое, соответствующее исходному коду? Ответ только «да» или «нет».

В этом подходе, даже если ввести связанный JSONL, вывод будет 예, и даже при вводе несвязанного JSONL вывод также будет 예.

Результат связанного JSONL:

Слабый запрос — связанный JSONL

Результат несвязанного JSONL:

Слабый запрос — несвязанный JSONL

Проблема в том, что вопрос был слишком широким. Если спросить только «Содержит ли код исходный материал?», LLM может решить, что это связано, лишь увидев такие общие термины, как Godot, Godot3, Godot4, migration, 2D, physics.

В результате, даже если Retriever предоставит неправильный JSONL, LLM может заполнить пробелы своей базой знаний и ответить «да». Это не то подтверждение, которое нам нужно.

Изменённый запрос

Поэтому мы заменили запрос на механизм оценки соответствия по доказательствам.

Вы — система оценки соответствия JSONL.

Определите, содержит ли приведённый ниже JSONL прямые основания для преобразования относительно указанного ниже SOURCE_CODE.

Критерии оценки:
- Чтобы ответ был «да», один из элементов JSONL: source_api, source_pattern, match_terms, required_when_seen_in_code, before_code должен точно совпадать с реальной строкой или вызовом API в SOURCE_CODE.
- Простое совпадение широких слов, таких как Godot, Godot3, Godot4, migration, 2D, physics, не считается релевантным.
- Отрицательные формулировки в JSONL, такие как «does not describe», «not related», «unrelated», «does not apply», не считаются доказательством.
- Если JSONL относится к другому API, другому узлу или другой системе, ответ «нет».
- Не используйте свои знания о Godot, опирайтесь только на строки, указанные в JSONL.
- Ответ должен содержать только одно слово: «да» или «нет».

В этом запросе критерий оценки был сузён до «прямого строкового основания».

Особенно было ограничено, что одно из следующих полей должно точно соответствовать реальной строке/API вызову в SOURCE_CODE.

source_api
source_pattern
match_terms
required_when_seen_in_code
before_code

Также LLM не позволил делать выводы с помощью широких ключевых слов и своих знаний о Godot.

Результат после исправления

Соответствующий JSONL получился как 예.

Строгий запрос - связанный JSONL

JSONL без значения получился нет.

Строгий запрос - несвязанный JSONL

Этот результат показал, что этап проверки LLM после поиска в базе данных должен сначала проверять не простую оценку семантического сходства, а наличие в найденном JSONL прямых строковых доказательств, соответствующих текущему чанку.

Критерий, полученный сегодня

Промпт проверки результатов поиска в базе данных должен соответствовать следующим критериям.

Широкое сходство тем не признаётся в качестве доказательства.
Не следует заполнять недостаточные доказательства предзнанием LLM о Godot.
Явное поле в JSONL должно точно соответствовать реальной строке/вызову API текущего чанка.
Отрицательно упомянутый контент JSONL не признаётся в качестве релевантного доказательства.
Первичное определение релевантности/нерелевантности лучше ограничить коротким и решительным да или нет.

Этот критерий будет важен, когда завтра будет подключён поиск по базе данных.

После получения кандидатов JSONL из docs_chunks, api_mapping, label_prototypes, этап проверки Qwen должен работать следующим образом.

chunkText
  -> Сбор кандидатов JSONL через поиск в БД
  -> prompt + chunkText + полученный JSONL
  -> Оценка наличия прямых строковых доказательств в JSONL
  -> Удаление нерелевантных JSONL
  -> Использовать только релевантные JSONL в качестве основания для последующего объяснения/миграции

Сегодняшний эксперимент был сосредоточен не на том, «знает ли LLM правильно», а на том, «можно ли заставить LLM принимать решения, опираясь только на доказательства, записанные в JSONL». Если это не удастся, то даже нерелевантные кандидаты, полученные Retriever‑ом, LLM сможет связать в правдоподобный текст. Поэтому, помимо качества поиска, необходимо отдельно разрабатывать и подсказку для проверки результатов поиска.