Первый вариант документа от 27‑го содержит много описаний объектов и их структуры, из‑за чего трудно отследить, как именно происходит поток ввода
Затем, опираясь на отзывы к PR, была скорректирована направленность документа
В форме # <относительный‑путь> теперь конкретно указывается, из какого файла и какой строки попадает код в AST‑парсер
Как в примере player.gd (E020‑E034), поток разбивается по реальному диапазону строк, а часть текста переходит к поиску Retriever и оценке LLM
Путь к файлу используется только для отслеживания; в поиске Retriever попадает лишь chunkText‑фрагмент кода/текста, что теперь зафиксировано
docs_chunks, api_mapping, label_prototypes обрабатываются без особых исключений тем же способом, а LLM повторно проверяет найденные варианты
Сегодняшняя работа была направлена на то, чтобы до начала реальной реализации зафиксировать в документе, как именно ввод и вывод соединяются, чтобы AI не менял диапазоны произвольно или не переходил к абстрактным описаниям структуры
На текущий момент разбиение на chunk‑ы считается частично успешным; дальше будет исследовано, как именно выполнять поиск в базе данных
Нужно проверить, какие JSONL‑кандидаты возвращаются из docs_chunks, api_mapping, label_prototypes только по chunkText
Также следует определить, как на этапе проверки Qwen решать, относится ли найденный JSONL к текущему chunk‑у и следует ли его отбрасывать
Прежде чем интегрировать поиск в БД, с помощью GPT созданы демонстрационные chunk‑ы Godot и связанные/несвязанные JSONL, чтобы протестировать запросы сопоставления
Сначала задавали вопрос типа «Содержит ли этот JSONL информацию, соответствующую исходному коду? Ответьте только «да» или «нет»», но получали «да» и для релевантных, и для нерелевантных JSONL
Затем ограничили ответ «да» только тем случаем, когда хотя бы одно из полей source_api, source_pattern, match_terms, required_when_seen_in_code, before_code точно совпадает с реальной строкой кода или вызовом API
Исключили оценку по широкой семантике или предвзятым знаниям LLM о Godot; теперь проверка опирается лишь на строковое совпадение, указанное в JSONL: релевантные JSONL получают «да», нерелевантные — «нет»
Этот эксперимент показал, что после поиска в БД этап проверки Qwen должен сначала проверять наличие точного строкового доказательства в найденном JSONL, а не «правдоподобную семантическую схожесть»
Завтра планируется создать несколько наборов демонстрационных chunk‑ов Godot с релевантными и нерелевантными JSONL и многократно протестировать, какие основания использует Qwen для вывода «да»/«нет»
