idea_world_labDEV JOURNAL
суббота, 27 июня 2026 г.

2026-06-27 Ретроспектива

Сегодня, кажется, я поставил цель улучшить согласованность документа о потоке ввода source-to-AST, который писал 26‑го числа.

До вчерашнего дня все уровни были разделены в голове, но в документе и коде оставались на слишком абстрактном этапе. Я мог различать такие термины, как AST, Retriever, проверка LLM, JSONL‑основания, но когда приходил реальный проект, не было конкретики: какие файлы раскрываются в каком порядке, какой текст попадает в AST‑парсер, какие куски (chunk) передаются Retriever‑у напрямую.

Я думал, что понимаю это в голове, но при попытке писать код возникало сильное ощущение, что реализовать всё так, как я хочу, будет сложно. Поэтому сегодня я сначала заново построил общую структуру и попытался спроектировать её в виде GUI, который человек может увидеть.

Почему требовалась конкретизация

Роли AST и Retriever действительно были различны.

Файлы .gd попадают в AST‑парсер и должны быть разбиты на функции или объявления. Retriever получает полученные фрагменты кода и ищет в базе связанные JSONL‑основания. Затем проверка LLM смотрит на запрос, текущий chunk и найденный JSONL, чтобы решить, действительно ли он релевантен.

Но если просто описать это словами, всё оставалось размытым. Особенно в реальном проекте файл сначала раскрывается в виде # <относительный‑путь>, ниже текст делится по файлам, конкретные функции или объявления в .gd становятся chunk‑ами, и только chunkText этих chunk‑ов передаётся Retriever‑у.

Я хотел увидеть этот поток чётко. Какой фрагмент какого файла стал каким chunk‑ом, действительно ли вход Retriever‑а совпадает с этим chunk‑ом, не смешались ли путь к файлу, номер строки или запрос с вводом поиска — всё это хотелось проверять непосредственно в веб‑интерфейсе.

Поэтому я решил не просто писать документацию, а создать инструмент с удобным GUI, где пользователь может увидеть всё визуально.

Source Flow Debugger

В результате, создав Source Flow Debugger, я смог отобразить поток от AST к Retriever на одном экране.

Сначала я пытался решить, как передать исходный код в AST, но в процессе добавил отображение AST‑chunk, direct‑chunk, ввод Retriever, кнопку поиска в БД и превью проверки Qwen — всё в один экран. Так получилась интегрированная структура AST, Retriever и проверки LLM, и она оказалась удобнее, чем я ожидал.

Главный момент — я не пытался сразу построить полностью готовую систему, а сделал наблюдательный инструмент. На текущем этапе мне нужен не «инструмент, автоматически выдающий правильный ответ», а средство, показывающее, движутся ли данные согласно задуманному потоку.

Сегодня я проверил следующее:

  • Godot‑проект раскрывается в виде # <относительный‑путь>.
  • Файлы .gd разбиваются на chunk‑и AST‑характеристики.
  • Текстовые ресурсы вроде .godot, .tscn разбиваются на direct‑chunk.
  • Файлы типа README.md исключаются из режима source‑analysis, причину исключения выводят на экран.
  • В ввод Retriever‑а не включаются путь к файлу, номер строки и запрос — только chunkText.
  • Под каждым chunk‑ом можно искать в таблицах docs_chunks, api_mapping, label_prototypes.
  • Затем проверка Qwen происходит по структуре prompt + chunkText + retrieved JSONL.

При загрузке небольшого Godot‑проекта я увидел разложение на 5 files, 14 chunks, AST 9, Direct 5. Похоже, разбиение на chunk‑и работает достаточно успешно.

Тест демонстрации GPT

Изначально я планировал собрать набор JSONL, найти соответствующий репозиторий на GitHub, клонировать его и протестировать.

Но потом понял, что не обязательно сразу искать реальный репозиторий. Сейчас меня интересует, «правильно ли LLM определяет, релевантен ли найденный JSONL текущему Godot‑chunk». Поэтому я решил сначала создать демо‑chunk Godot и соответствующие JSONL, а также полностью нерелевантные JSONL, и протестировать их с помощью GPT.

Для этого я специально создал chunk кода Godot 3, подготовил JSONL‑переходы Godot 3 → Godot 4 и набор полностью нерелевантных JSONL, а затем провёл тест.

Сначала я задал простой вопрос.

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

В результате и связанный JSONL, и несвязанный JSONL тоже получили 예.

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

Поэтому я усилил запрос.

Вы — система оценки соответствия 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.
- Ответ должен содержать только одно слово: «да» или «нет».

Так изменим: связанные JSONL — 예, несвязанные JSONL — 아니오.

Сегодня полученный критерий в этом эксперименте важен. Когда Retriever получает кандидаты JSONL и передаёт их LLM для проверки, нельзя полагаться на широкое семантическое сходство. Сначала нужно убедиться, что такие поля, как source_api, source_pattern, match_terms, required_when_seen_in_code, before_code в JSONL действительно соответствуют реальной строке/API‑вызову текущего чанка.

Завтра к выполнению

Завтра, кажется, понадобится создать больше наборов демо.

Нужно создать несколько связанных JSONL, несвязанных JSONL и чанков Godot, а затем многократно протестировать, как Qwen формирует ответы. Один‑два удачных случая ещё слишком рано принимать за окончательный критерий.

Особенно следует проверить следующие случаи.

  • Когда несколько связанных JSONL смешаны, правильно ли Qwen выбирает реальные основания.
  • Отбрасывает ли Qwen несвязные JSONL, когда только ключевые слова похожи, как 아니오.
  • Различает ли Qwen разницу между api_mapping и label_prototypes на основе строковых оснований.
  • Можно ли так же проверять JSONL типа docs_chunks, представляющие собой описательные документы.
  • Не выполняет ли произвольную миграцию, когда код выглядит как Godot 3, но оснований в JSONL нет.

Сегодня был день, когда абстрактную структуру вывели на реальный экран и поток ввода. То, что казалось уже понятным в голове, стало гораздо яснее, когда мы разложили всё на веб‑странице, разбили и отобразили в виде поискового ввода.

Теперь следующий шаг — многократно повторять поиск по базе данных и проверку Qwen, чтобы убедиться, что этот процесс остаётся стабильным.