Сегодня ставим цель выбрать, какой поток среди различных альтернатив поиска/валидации использовать
При сохранении chunkText как входных данных нужно решить, как комбинировать BM25, полнотекстовый поиск PostgreSQL, embedding, reranker и валидатор Qwen direct‑evidence
Сначала не было окончательного проекта, а лишь собранные материалы о плюсах и минусах каждого способа поиска, полученные через ChatGPT, а также примеры ответов «да»/«нет» для оценки
Затем, опираясь на симуляцию каждой альтернативы и сводную сравнительную таблицу, решили отдать приоритет стратегии F
Стратегия F представляет собой последовательность BM25 + embedding + reranker + Qwen direct‑evidence validator
То есть, оставляем chunkText как ввод для поиска, с помощью BM25 и embedding собираем широкий набор кандидатов, затем переупорядочиваем их reranker‑ом и, наконец, Qwen проверяет, действительно ли найденный JSONL соответствует текущему коду‑чанку
Следующая проверка будет выполнена Qwen‑ом: по 50 примеров из каждой таблицы docs_chunks, api_mapping, label_prototypes
В каждой таблице возьмём около 50 образцов, разделим их на релевантные и нерелевантные случаи и посмотрим, как будут различаться ответы «да» и «нет»
Этот тест проверяет не только то, что поиск работает, но и то, признаёт ли валидатор Qwen direct‑evidence найденный JSONL истинным доказательством соответствия коду‑чанку или отклоняет его
Поскольку работа ведётся вручную, объём реального тестирования оказался гораздо больше, чем ожидалось
Было создано 50 тестовых пунктов для Godot, и каждый пункт требует проверки всех трёх таблиц docs_chunks, api_mapping, label_prototypes
Если речь идёт о общей функции/синтаксисе, создаём один Godot‑чанк, формируем ожидаемые данные «да»/«нет» для каждой из трёх таблиц, затем комбинируем prompt + тестовый код + шесть наборов данных, чтобы увидеть, как меняется паттерн ответов
Если функция не общая, приходится делать отдельные версии кода для Godot 3 и Godot 4, что удваивает объём работы
Чтобы позже собрать метрику классификации (например, F1‑score), необходимо вручную фиксировать результат true/false для всех случаев
Поэтому было решено, что завершить все 50 пунктов за один день нереально; цель на сегодня – сократить их до 5 и выполнить
После выполнения пяти пунктов планируем не просто увеличивать количество тестов, а сначала проанализировать полученные паттерны ответов «да»/«нет»
Фактически, из 50 пунктов было выполнено 5
Уже после пяти пунктов заметили, что ответы различаются между JSONL, созданным на основе Godot 3, и JSONL, созданным на основе Godot 4
Особенно в коде с различиями версий: при проверке кода Godot 4 с помощью JSONL, построенного для Godot 3, могут появиться «да» из‑за общих строк или миграционных доказательств; наоборот, при проверке кода Godot 3 JSONL‑ом для Godot 4 результаты могут стать неоднозначными, если перемешаны строки source/target
Поэтому в следующих тестах будем не только смотреть, совпадают ли 6 ответов «да/нет», но и сначала разделять их по типу (общий синтаксис vs различия версий), а затем фиксировать отдельные параметры: «версия, по которой генерировался JSONL», и «версия проверяемого кода», записывая сырые ответы
Этот процесс показал, что проблема не только в корректировке промпта‑валидации, но и в необходимости изменить стратегии промптинга и сбора датасета
В дальнейшем при создании JSONL следует более чётко разделять критерии сбора/генерации, чтобы не смешивать общий синтаксис, доказательства, специфичные для Godot 3, специфичные для Godot 4 и двунаправленные миграционные доказательства
Кроме того, продолжается конверсия официальной документации из Markdown в JSONL: на сегодня из 1 570 Markdown‑файлов уже преобразовано около 600 в JSONL