commit 88b7e623b88a38b85bec8f950f912568323352a9 Author: emil28092005 Date: Wed Sep 16 02:44:54 2026 +0300 docs: add micro-scout research and experimental roadmap diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..19b6bfe --- /dev/null +++ b/.gitignore @@ -0,0 +1,28 @@ +# Local configuration and secrets +.env +.env.* +!.env.example + +# Python environments and caches +.venv/ +venv/ +__pycache__/ +*.py[cod] +.pytest_cache/ +.ruff_cache/ + +# Generated research and training artifacts +data/ +datasets/ +checkpoints/ +runs/ +logs/ +wandb/ +*.safetensors +*.gguf +*.pt +*.pth + +# Editor and OS files +.idea/ +.DS_Store diff --git a/README.md b/README.md new file mode 100644 index 0000000..cd0d33e --- /dev/null +++ b/README.md @@ -0,0 +1,42 @@ +# micro-scout + +Исследовательский проект быстрого локального скаута контекста для программного кода. + +Скаут должен находить полезные исходные фрагменты, учитывать связи между символами и передавать контекст большой модели через небольшой агентский harness — цикл управления моделью и инструментами. + +## Статус + +Подготовлены исследование и план экспериментов. Реализация, обученные веса и собственные результаты измерений пока отсутствуют. + +## Документация + +- [Исследование и план разработки](docs/RESEARCH_RU.md): существующие решения, Graphify, архитектура, данные, обучение, оценка пользы, ресурсы и восьминедельный план. +- Дата исследования: 16 сентября 2026 года. +- В текущей смете исключена оплата вызовов модели-учителя и основной модели; учитываются обучение своей модели и инфраструктура. + +## Предлагаемая архитектура + +```text +Репозиторий и текущие изменения + → граф символов и поисковые индексы + → поиск кандидатов + → маленькая модель отбора и выбора действий + → исходные фрагменты с проверенными адресами + → большая модель и проверка решения +``` + +Факты о репозитории хранятся во внешнем обновляемом индексе. Модель обучается выбирать полезный контекст и действия поиска на новых проектах. + +## Первые эксперименты + +1. Собрать минимальный harness с поиском, чтением символов и обходом графа. +2. Сравнить обычный поиск, графовый поиск и готовый ранжировщик на одинаковых задачах. +3. Измерить успешность решения, полную задержку, объём контекста и свежесть ссылок. +4. Проверить пользу собственного encoder и затем уменьшить его размер. +5. При подтверждённом эффекте обучать выбор действий и бюджета поиска. + +## Критерий полезности + +Сокращение времени решения при сохранении успешности на незнакомых репозиториях. Проверяются весь агентский цикл, дополнительные чтения и обновление индекса, а не только скорость отдельного вызова модели. + +Целевые размеры моделей, задержки и бюджеты в исследовании являются гипотезами для проверки, а не опубликованными результатами micro-scout. diff --git a/docs/RESEARCH_RU.md b/docs/RESEARCH_RU.md new file mode 100644 index 0000000..a617bc4 --- /dev/null +++ b/docs/RESEARCH_RU.md @@ -0,0 +1,580 @@ +# Микромодель-скаут для кода: исследование и план эксперимента + +**Дата: 16 сентября 2026.** Предмет: локальная быстрая модель поиска контекста, граф Graphify-Labs/graphify, собственный микро-harness и работа вместе с GPT‑6 Astra. + +Это исследование источников и проект эксперимента. Обучение и измерения на RTX 2080 Ti не проводились. Приведённые ниже целевые задержки, сроки разработки и бюджеты проекта — инженерные оценки; результаты чужих работ отмечены отдельно. + +**Уточнение бюджета:** по пожеланию пользователя стоимость вызовов модели-учителя и основной модели пока исключена. Считаем собственное обучение, GPU и инфраструктуру. Объём запросов и время проверок остаются частью плана. + +## 1. Вывод + +**Проект стоит пробовать. Наиболее обоснованный вариант — маленькая обучаемая система поиска и отбора контекста внутри собственного простого harness.** Граф репозитория хранится снаружи модели и обновляется после изменений. Большая модель получает выбранные исходные фрагменты и может запросить дополнительный поиск. + +Реалистичная цель: уменьшить время и стоимость поиска при сохранении доли решённых задач. Повышение качества возможно, особенно на задачах со связями между файлами, но его нельзя обещать до сравнительного эксперимента. + +Главные решения: + +- Начать с графа, обычного поиска и готового reranker — модели, которая переставляет найденные фрагменты по полезности. +- Проверить, помогает ли это Astra, до обучения своей сети. +- Затем обучить encoder около 150M параметров; при подтверждённом выигрыше сжать его до 30–80M. +- Сначала учить выбирать фрагменты. Позже — выбирать действия поиска и момент остановки. +- Измерять весь цикл решения задачи, включая повторный поиск, построение индекса, кэш и тесты. +- Диффузию и изменяемое число MoE-экспертов оставить отдельными исследовательскими ответвлениями. + +Само сочетание «маленький скаут + большая модель» уже существует. Потенциальное отличие проекта — работа локально на доступной GPU, свежий граф изменяемого кода, адаптивный бюджет поиска и открытая проверка реальной пользы. + +## 2. Что уже существует и что это доказывает + +| Работа / продукт | Что близко к идее | Как учитывать | +|---|---|---| +| **SWE-grep / SWE-grep-mini, Cognition** | Специализированная модель поиска, выдающая файлы и диапазоны строк основному агенту; обучение поиску с инструментами | Прямой аналог общей концепции. Авторы сообщают ускорение на собственной инфраструктуре; это не замер на 2080 Ti и не проверка с Astra. [Первичный источник](https://cognition.com/blog/swe-grep) | +| **FastCode, март 2026** | Гибридный поиск, структурный граф, поэтапное чтение и адаптивное управление расходами | Очень близкий аналог предлагаемой системы. Нужно сравниваться и с алгоритмическим поиском, а не только с обычным grep. [Статья](https://arxiv.org/html/2603.01012v1) | +| **LocAgent, ACL 2025** | Локализация кода через граф файлов, классов, функций и зависимостей | Подтверждает применимость графа для поиска места изменения. Его обученная модель значительно крупнее предполагаемой микромодели. [Статья](https://aclanthology.org/2025.acl-long.426/) | +| **Aider repo map** | Выбор значимых символов по графу в заданный токеновый бюджет | Обязательный дешёвый ориентир без собственного обучения. [Документация](https://aider.chat/docs/repomap.html) | +| **Repoformer, 2024** | Обучение выборочному использованию внешнего контекста | Полезный принцип: учить, когда поиск помогает. Исходная задача — дополнение кода; перенос на исправление багов требует проверки. [Статья](https://arxiv.org/abs/2403.10059) | +| **GraphCodeBERT, 2020** | Представления кода с использованием data-flow, то есть зависимостей значений | Обучение на структуре кода имеет давнюю историю. «Добавили граф» само по себе не научная новизна. [Статья](https://arxiv.org/abs/2009.08366) | +| **TinyAgent, 2024** | Специализированные малые модели для вызова функций | Поддерживает реалистичность узкого локального агента. Его задачи и результаты не равны поиску по репозиторию. [Статья](https://arxiv.org/abs/2409.00608) | +| **Agent Lightning v1.0, август 2026** | Обучение агента прямо в harness, используемом при работе | Подтверждает актуальность обучения вместе со средой выполнения. Это инфраструктура обучения, а не готовая микромодель-скаут. [Статья](https://arxiv.org/html/2608.17528v1) | + +### Самое сильное практическое свидетельство + +Cognition описывает SWE-grep как отдельного поискового помощника: ограниченное число раундов поиска, параллельные вызовы инструментов, выдача ссылок на исходный код. Компания сообщает, что в её эксперименте связка с Sonnet 4.5 решала тот же набор задач быстрее. Это подтверждает жизнеспособность разделения ролей, но остаётся отчётом разработчика на его конфигурации. Указанная высокая скорость генерации получена на Cerebras и не характеризует потребительскую GPU. [Описание экспериментов](https://cognition.com/blog/swe-grep) + +### Где ещё остаётся исследовательский вопрос + +**Может ли модель до 150M параметров, использующая внешний граф и ограниченный поиск, улучшить соотношение «успешность / задержка / стоимость» сильного агента на незнакомых и изменяемых репозиториях?** + +В таком виде вопрос достаточно конкретен, допускает отрицательный результат и не сводится к повторению интерфейса существующего продукта. Новизну будущей статьи всё равно потребуется проверить относительно работ, вышедших к моменту публикации. + +## 3. Насколько надёжны свидетельства Graphify + +### Что он даёт + +В Graphify-Labs/graphify структурный проход по коду использует tree-sitter; для него не требуется LLM. Инструмент строит граф, предоставляет поиск и работу со связями. Семантическая обработка документов и других материалов — отдельный механизм. Проект различает извлечённые, предполагаемые и неоднозначные связи; это происхождение ребра, а не вероятность его истинности. [Репозиторий Graphify](https://github.com/Graphify-Labs/graphify) + +### Что показывают его тесты + +В опубликованном BENCHMARKS.md от 5 июля 2026 тест по коду включает **6 вопросов по ERPNext**. Сообщается рост покрытия эталонных фактов с 70,8% до 82,0%. Это оценка ответов на вопросы, а не доля исправленных багов. Основные более крупные таблицы относятся к разговорной памяти. Такие результаты полезны как демонстрация, но их недостаточно для вывода о преимуществе на разных репозиториях или в связке с Astra. [Опубликованные условия и результаты](https://raw.githubusercontent.com/Graphify-Labs/graphify/v8/BENCHMARKS.md) + +### Как использовать его в нашем проекте + +Graphify следует рассматривать как источник внешней структуры и один из готовых вариантов поиска. Это **не алгоритм обучения нейросети**. + +Предлагаемое разделение: + +1. Парсер и языковые инструменты извлекают структуру. +2. Индекс хранит файлы, символы, связи и версии. +3. Обучаемая модель решает, какие фрагменты нужны для конкретной задачи. +4. Harness выполняет поиск, проверяет версии и формирует ответ. + +Не нужно обучать отдельные веса на каждом репозитории. Модель должна переносить навык выбора на новый код, а факты о текущем проекте получать из индекса. + +Статический граф неполон: динамический dispatch, reflection, dependency injection, конфигурация, SQL, шаблоны и сгенерированные файлы создают связи, которые трудно восстановить только из AST. Поэтому отсутствие ребра нельзя трактовать как отсутствие зависимости. Полезно хранить источник и надёжность каждого типа связи; для типизированных языков добавить информацию компилятора или LSP. + +Практическое условие интеграции: проверять существование символов, диапазоны строк и свежесть файлов при чтении. Номер строки — адрес внутри версии, а не вечный идентификатор. + +## 4. Что именно должна предсказывать модель + +Вход — задача пользователя, текущее состояние поиска, ограниченный набор кандидатов, признаки графа и оставшийся бюджет. Выход — оценки кандидатов и, позднее, выбор следующего действия. + +Плохая цель для обучения: «восстанови путь исправленного файла». Она поощряет запоминание имён и игнорирует контекст, нужный для правильного решения. + +Более полезная цель: **собери небольшой набор исходных фрагментов, с которым основная модель решит задачу с высокой вероятностью**. + +Пример задачи: «после отмены запроса повторная попытка всё равно запускается». Полезный набор может включать: + +- обработчик отмены; +- цикл повторных попыток; +- интерфейс токена отмены; +- вызывающую функцию; +- тест ожидаемого поведения. + +Файл с будущим исправлением — только часть этого набора. Два фрагмента могут быть полезны лишь вместе, поэтому независимый top-k по сходству не всегда достаточен. + +### Формат ответа + +Ниже условный пример протокола. JSON собирает обычный код, а модель выбирает существующие идентификаторы. + +```json +{ + "snapshot_id": "repo-state-42", + "hits": [ + { + "symbol_id": "retry-loop-17", + "path": "src/retry.py", + "start_line": 80, + "end_line": 123, + "content_hash": "sha256:...", + "role": "implementation", + "text": "...исходный код..." + } + ], + "next_action": "expand_callers", + "next_target_ids": ["retry-loop-17"], + "stop_reason": null, + "budget_remaining_tokens": 4200 +} +``` + +Внешний ответ обязательно включает содержимое или возможность немедленно прочитать его через инструмент. Одна ссылка на локальный путь не передаёт код облачной модели. + +Ранжирующий score не следует показывать как «95% уверенности, что контекста достаточно». Для такой вероятности нужен отдельный обученный и проверенный калибратор. На первом этапе достаточно явных причин остановки: закончился бюджет, нет новых кандидатов, запрошен дополнительный поиск. + +## 5. Рекомендуемая архитектура + +```mermaid +flowchart TD + A[Файлы и текущие правки] --> B[Парсер и проверка версий] + B --> C[Граф, текстовый индекс, векторы] + Q[Задача и бюджет] --> D[Дешёвый поиск кандидатов] + C --> D + D --> E[Маленькая модель отбора] + E --> F{Нужно продолжить поиск?} + F -->|Да| G[Чтение символов и соседей графа] + G --> E + F -->|Нет| H[Пакет исходных фрагментов] + H --> I[Большая модель] + I -->|Уточняющий запрос| D + I --> J[Изменение и проверка кода] +``` + +### 5.1. Индексирование + +Один раз разобрать репозиторий; затем обновлять изменившиеся файлы и затронутые связи. Хранить AST-границы, сигнатуры, содержимое, ссылки, тесты и метаданные. Не включать автоматически зависимости, сборки, минифицированные файлы и большие дубли. + +Для живого редактора нужен снимок с учётом незакоммиченных изменений. Если индекс старее файла, перепроверить его или читать актуальный файл напрямую. Для незавершённого синтаксиса использовать текстовый резервный поиск. + +### 5.2. Дешёвый поиск + +Сочетать точный поиск по идентификаторам, BM25 — поиск по словам с учётом их редкости — и векторное сходство. Объединить результаты, добавить ограниченное число соседей графа. Первые параметры для эксперимента: 100–300 кандидатов до фильтрации и 16–64 перед дорогой оценкой. Это гиперпараметры, а не доказанные оптимумы. + +Если необходимый фрагмент вообще не попал в кандидаты, reranker не сможет его восстановить. Поэтому полноту начального поиска нужно измерять отдельно. + +### 5.3. Два варианта нейронной части + +**Самый дешёвый:** заранее вычисленные векторы кода, вектор запроса и небольшая сеть, использующая также тип связи, расстояние в графе, текстовые совпадения и стоимость фрагмента. Здесь содержимое кода не прогоняется через большой encoder на каждом запросе. + +**Более точный:** cross-encoder читает запрос вместе с каждым из нескольких десятков фрагментов. Это дороже, но позволяет учитывать детали, потерянные в заранее вычисленном векторе. + +Практичный каскад: дешёвая оценка всех кандидатов → cross-encoder только для спорной верхушки → сборка контекста. В отчёте о размере системы нужно считать и encoder, и embedder, и ранжирующие головы. «Голова на 5M» поверх постоянно работающей модели на 600M не является всей моделью на 5M. + +### 5.4. Что взять для первых сравнений + +- **Qwen3-Reranker-0.6B** — готовый ориентир, поддерживающий много языков и код. Его пример оценки использует логиты ответа yes/no; длинная генерация рассуждений не обязательна. [Карточка и пример inference](https://huggingface.co/Qwen/Qwen3-Reranker-0.6B) +- **ModernBERT-base, 149M** — кандидат для собственного обучения оценки пар «запрос–код». Это предобученная основа, а не готовый идеальный поисковик. В предобучении присутствует код. [Карточка модели](https://huggingface.co/answerdotai/ModernBERT-base) +- После удачного fine-tuning — ученик на **30–80M**, обученный воспроизводить полезные оценки и решения более сильного учителя. Этот диапазон — проектная цель. + +Для русских запросов отдельно проверить качество и сравнить перевод запроса, смешанное обучение RU/EN и многоязычный reranker. Переводы одного задания должны попадать в один и тот же раздел датасета. + +### 5.5. Откуда берётся скорость + +Главный выигрыш ожидается от малого объёма повторной работы: не читать весь репозиторий при каждом запросе, не генерировать длинный ответ, кэшировать неизменный код, держать веса загруженными и пакетно оценивать короткие фрагменты. + +Для исходного опыта предлагаю целевую задержку тёплого поиска **100–300 мс по медиане и менее 1 секунды для 95% запросов** на заранее проиндексированном проекте. Это амбициозный критерий проверки, а не прогноз для любой конфигурации 2080 Ti. Холодный запуск и обновление индекса измеряются отдельно. + +Для encoder прямой PyTorch-сервис достаточен в качестве начала. Замена Ollama на vLLM сама по себе не решает эту задачу: сначала нужно выбрать архитектуру и измерить её inference. Сложный сервер генерации имеет смысл, если в системе действительно появляется генеративная модель и соответствующая нагрузка. + +## 6. Собственный микро-harness: зачем он нужен + +Harness — программа, которая хранит состояние, вызывает модель и инструменты, применяет ограничения и записывает результат. **Собственный harness полезен и для исполнения, и для получения обучающих траекторий.** + +Лучше начать с двух логических циклов в одном приложении: + +- внутренний: скаут ищет контекст, читает код и решает, что отдать; +- внешний: сильная модель анализирует задачу, меняет код и запускает проверки. + +Не обязательно иметь отдельные процессы или несколько разговаривающих друг с другом агентов. Важнее чёткий протокол между поиском и решением. + +Возможен и самостоятельный режим без большой модели: локальный инструмент находит символы, показывает зависимости, собирает контекст и предлагает связанные тесты. Это полезный первый продукт. Для самостоятельного редактирования кода потребуется отдельно учить и оценивать генерацию исправлений; успешный поисковик ещё не является надёжным решателем задач. + +### Минимальная среда скаута + +| Действие | Что делает обычный код | Что выбирает модель | +|---|---|---| +| `search` | Выполняет текстовый и векторный поиск | Вариант запроса из кандидатов; позже — уточнение запроса | +| `read_symbols` | Читает существующие диапазоны | Идентификаторы нужных символов | +| `expand_neighbors` | Извлекает связи заданного типа | Узлы, тип связи, глубину | +| `find_tests` | Находит доступные тесты по индексу | Какие кандидаты проверить | +| `emit_context` | Проверяет версии, объединяет фрагменты | Набор и порядок фрагментов | +| `request_fallback` | Возвращает управление основной модели | Когда бюджет скаута исчерпан или поиск бесполезен | + +Проверку путей, доступные действия, дедупликацию, токеновый бюджет, тайм-ауты и запись трассы следует реализовать детерминированно. На первом этапе скауту достаточно чтения: исправление кода и тесты остаются во внешнем цикле. + +Простейший вариант вообще не учит политику действий: harness всегда выполняет поиск, один проход соседей и ранжирование. Это необходимая контрольная версия. Обучаемая политика оправдана, только если она экономит время или повышает качество относительно такого фиксированного порядка. + +### Как обучать модель внутри него + +1. **Записать примеры.** Сильный учитель или человек проходит те же инструменты. Сохраняются наблюдения, выбранные ID, действия и результат. +2. **Обучить по примерам.** Начать с ранжирования и имитации успешных коротких траекторий. Не копировать весь многословный диалог учителя. +3. **Собрать ошибки ученика.** На состояниях, в которые попадает именно он, получить исправленные действия. Иначе ошибки поиска накапливаются после первого отклонения от примера. +4. **Добавить обучение по результату.** Сравнивать варианты набора контекста или поиска по полезности для решателя, времени и стоимости. +5. **Проверить перенос.** Другие репозитории, другая основная модель и хотя бы один другой harness. + +Если решение одно — например, выбрать бюджет или вариант поиска — сначала достаточно contextual bandit: обучаемого выбора действия с оценкой его результата. Для последовательности зависимых действий уже уместно полноценное reinforcement learning, RL. + +В обучение должны попадать только наблюдения, доступные модели в данный момент. Журнал обязан хранить версию репозитория и harness, допустимые действия, их аргументы, результаты и расходы. Сохранённая траектория описывает один пройденный путь; результат непосещённого действия нельзя получить из неё автоматически. Для сравнения альтернатив нужны новые прогоны или воспроизведение инструментов на том же snapshot. Обновление весов лучше проводить отдельными проверяемыми версиями, а не автоматически после каждого пользовательского запроса. + +Возможный критерий обучения: + +```text +полезность = успешность решения + − штраф за время + − штраф за стоимость + − штраф за устаревшие / неверные ссылки +``` + +Коэффициенты нужно подбирать на валидации. Более надёжная постановка для продукта: минимизировать задержку и стоимость **при ограничении на допустимое ухудшение успешности**. Один скалярный reward может скрыть потерю качества. + +Успех всей задачи — шумный и дорогой сигнал. Ошибка Astra не обязательно означает плохой контекст; хороший ответ не означает, что каждый переданный фрагмент был нужен. Поэтому сначала нужны дешёвые метрики поиска, затем выборочные парные запуски решателя. Astra можно оставить неизменной: обновляются только веса своего скаута, без градиентов через закрытую модель. + +### Насколько это подтверждено исследованиями + +mini-SWE-agent показывает, что полезный агентский цикл может быть очень простым; это хороший образец для исследовательской обвязки и воспроизводимых траекторий. Его результаты зависят от основной модели. [Репозиторий](https://github.com/SWE-agent/mini-swe-agent) + +В Agent Lightning v1.0 авторы обучают Qwen3.5-9B с mini-SWE-agent, сообщая рост SWE-bench Verified с 41,8% до 56,4% на своём протоколе. Использованы около 6 тысяч обучающих задач. Это свидетельство пользы обучения внутри harness, но не обещание аналогичного роста для скаута на 50M и не бюджет для одной 2080 Ti. [Статья и условия](https://arxiv.org/html/2608.17528v1) + +Для нашей классифицирующей модели не требуется сразу подключать всю RL-инфраструктуру. Простой цикл, журнал и PyTorch позволяют проверить большую часть гипотезы. Agent Lightning или похожий стек стоит подключать, когда нужны массовые траектории и обучение многошаговой генеративной политики. + +## 7. Данные: откуда брать и как генерировать + +### Готовые источники + +| Источник | Назначение в проекте | Ограничение | +|---|---|---| +| **SWE-smith** | Задачи с внесёнными ошибками, исправлениями и исполняемыми проверками; основа для создания поисковых траекторий | Искусственные ошибки не покрывают всё распределение реальных задач. Доступны десятки тысяч примеров; выбирать качественную часть. [Проект](https://swesmith.com/) | +| **CodeSearchNet** | Дополнительные пары описаний и функций для обучения семантическому соответствию | Поиск по описанию функции проще, чем собрать контекст межфайлового бага. [Датасет](https://github.com/github/CodeSearchNet) | +| **ContextBench** | Прежде всего независимая оценка извлечения контекста | Не смешивать его задачи и пересекающиеся репозитории с обучением. [Статья](https://arxiv.org/abs/2602.05892) | +| **Собственные разрешённые репозитории и реальные задачи** | Пользовательские формулировки, незакоммиченные изменения, ошибки поиска ученика | Сохранить отдельный набор проектов и задач, которого обучение не видит | + +ContextBench содержит 1 136 задач из 66 репозиториев на восьми языках с разметкой контекста. Авторы измеряют полноту, точность и использование найденного кода. Их результаты показывают, что усложнение обвязки не гарантирует улучшения поиска. Бенчмарк создан на основе существующих наборов задач, поэтому при смешивании источников нужно проверять пересечения. [Методика](https://arxiv.org/html/2602.05892v1) + +### Можно ли попросить нейросеть создать датасет? + +Да. Наиболее полезная синтетика привязана к **реально исполняемому коду и проверяемым изменениям**. Генерация выдуманных репозиториев и «правильных ссылок» создаёт слишком простые и часто неверные примеры. + +Предлагаемый конвейер: + +1. Выбрать snapshot реального проекта и задачу с проверяемым решением. +2. Построить индекс именно исходного, ещё не исправленного состояния. +3. Найти кандидатов несколькими способами, включая ложные совпадения. +4. Дать учителю задачу и те же инструменты, которые доступны ученику. +5. Получить набор нужных символов, полезные связи и короткую последовательность действий. +6. Проверить ID, диапазоны, версии и исполняемость тестов обычным кодом. +7. Для части примеров запустить решателя с этим контекстом; сравнить несколько наборов. +8. Вручную разобрать спорные случаи и систематические ошибки разметки. + +Исправленный diff допустим как вспомогательный источник разметки, но не как вход поиска. Учитель, которому показали решение, может подсказать недоступные при реальной работе имена и причинные связи. Такие подсказки нужно отделять от наблюдений ученика. + +### Три уровня качества меток + +**Дешёвые:** изменённые символы, найденные ссылки, соседние тесты. Это слабые метки: они не доказывают полезность для решения. + +**Средние:** учитель оценивает кандидатов, учитывая весь доступный контекст, и выбирает совместно полезные группы. Полученные оценки проверяются выборочно человеком. + +**Дорогие:** сравнение результата большой модели с разными наборами контекста. Можно удалять фрагменты по одному или группами и проверять изменение успешности. Это приближённая причинная проверка; из-за случайности генерации нужны повторения, а не один ответ учителя. + +Не стоит объявлять все невыбранные фрагменты отрицательными: часть из них может быть альтернативным правильным контекстом. Хранить «положительный», «проверенный отрицательный» и «неизвестный» полезнее, чем притворяться, что разметка полна. + +### Как использовать граф при обучении + +- Подавать типы связей, расстояния, роли узлов и надёжность извлечения как признаки. +- Делать вспомогательные задания на ссылки и отношения между символами. +- Учить выбор между реализацией, вызывающей функцией, тестом, конфигурацией и интерфейсом. +- Добавлять сложные отрицательные примеры: одноимённые функции, похожий модуль, устаревший вариант, сосед, который не помогает задаче. +- Проверять совместную полезность наборов: реализация без вызывающей стороны часто недостаточна. + +Основная метка должна отражать пользу для задачи. Обучение только воспроизводить соседство графа даст дорогую замену обходу графа. + +### Минимальный объём + +Для первого цикла предлагаю **5–20 тысяч различных задач обучения** с наборами кандидатов и **200–500 тщательно проверенных задач разработки и диагностики**, разделённых по назначению. Это стартовая оценка; необходимый объём определяется кривой качества при добавлении данных. + +Тысяча задач по 32 кандидата — это 32 тысячи пар, но всё ещё только тысяча независимых задач. Число строк датасета не заменяет разнообразие проектов. + +Финальный тест должен быть отдельным. Разделять нужно по репозиториям, семействам форков, задачам и времени; удалить почти одинаковый код между разделами. История git и доступ к будущему исправлению не должны раскрывать ответ. Для каждого примера сохранять происхождение и условия использования исходных данных и модели-учителя. + +## 8. Как доказать пользу в связке с Astra + +### Сравниваемые варианты + +| Вариант | Что проверяет | +|---|---| +| A. Сильная модель + обычные search/read | Практический исходный уровень | +| B. Та же модель + готовый графовый поиск без обучения | Вклад индекса и структуры | +| C. B + готовый reranker | Нужна ли вообще своя нейросеть | +| D. B + свой обученный encoder | Вклад специального обучения | +| E. D + обучаемая политика действий | Вклад адаптивного микро-harness | +| O. Эталонный контекст, проверенный человеком | Приближённая оценка того, сколько пользы вообще может дать идеальный поиск | + +Во всех вариантах фиксировать основную модель, её настройки, инструменты изменения кода, доступные исходники, ограничения времени и критерий успешности. Достаточно хорошая базовая система важнее красивого сравнения со слабым grep-подобным скриптом. + +Два режима оценки нужны отдельно: + +1. **Фиксированный контекст:** решатель получает только выбранные фрагменты. Удобно диагностировать потери поиска. +2. **Рабочий агент:** решатель может дочитать недостающее. Это главный практический тест; все дополнительные чтения и их стоимость учитываются. + +### Что измерять + +- **Полнота кандидатов:** попадает ли нужный код в начальный список. +- **Полнота и точность выбранных фрагментов:** сколько нужного найдено и сколько лишнего передано, в том числе в фиксированный токеновый бюджет. +- **Покрытие групп доказательств:** найдены ли совместно необходимые реализация, вызов, тест и конфигурация. +- **Успешность всей задачи:** исправление проходит независимые проверки; для вопросов ответы проверяются по исходникам. +- **Стоимость успешного решения:** общие расходы на все попытки, включая неудачные, делённые на число успешных задач. +- **Время до решения:** медиана и 95-й процентиль, отдельно поисковая часть и весь цикл. +- **Свежесть:** доля устаревших ссылок после правок, переименований и смены ветки. +- **Перенос:** новые репозитории, языки и другая сильная модель. + +Ранжирующая метрика сама по себе не доказывает пользу. И наоборот, чуть меньшая полнота может быть приемлемой, если основной агент быстро восполняет пропуски и решает задачи дешевле. При запрете дочитывания цена пропуска намного выше. + +### Как избежать ошибочного вывода + +На первых 50–100 задачах искать крупные ошибки и размер эффекта. Для заявления «качество почти не ухудшилось» нужен более крупный парный тест с доверительными интервалами; число задач зависит от частоты расхождений между вариантами. Сотня задач обычно не позволяет убедительно доказать разницу порядка одного процентного пункта. + +Использовать парное сравнение одинаковых задач, повторные запуски для шумных условий, анализ по репозиториям и bootstrap с группировкой по проекту. Публиковать не только среднее, но и список провалов. Не выбирать лучшую настройку на финальном тесте. + +### Предлагаемый критерий продолжения + +Это продуктовые цели эксперимента, не обещанные результаты. Пока стоимость вызовов модели исключена из расчётов, главным критерием служит время при сохранении успешности; денежную экономию можно оценить позднее: + +- хотя бы **20% экономии полной стоимости** или **15% сокращения полного времени**; +- ухудшение успешности не превышает заранее выбранную допустимую границу, например **2 процентных пункта**, с достаточной статистической уверенностью; +- выигрыш есть на нескольких незнакомых проектах; +- результат сохраняется при учёте кэша, индексации и повторных чтений. + +Если даже эталонный контекст почти не помогает, дорогой проект обучения скаута для этого сценария стоит остановить. Если граф без обучения уже достигает цели, его можно использовать как продукт, а нейронную часть обосновывать отдельным измерением. + +## 9. Сможет ли это помогать GPT‑6 Astra + +**Технически — да. Практическая величина выигрыша пока неизвестна.** Я не нашёл опубликованного сравнительного теста именно предлагаемого скаута с Astra. + +По текущей официальной документации Astra поддерживает вызов функций, structured outputs и MCP. Её можно подключить к инструменту, выдающему найденный код; дообучение самой Astra для этого не требуется. [Карточка модели](https://developers.openai.com/api/docs/models/gpt-6-astra) + +Два пути интеграции: + +- **Свой harness через API:** приложение получает запрос инструмента от Astra, вызывает локальный скаут и возвращает результат. [Function calling](https://developers.openai.com/api/docs/guides/function-calling) +- **Использование внутри Codex:** предоставить поиск через локальный MCP-сервер. Это даёт агенту дополнительный инструмент, а поведение и выбор момента вызова нужно проверять на практике. [Документация MCP](https://learn.chatgpt.com/docs/extend/mcp?surface=cli) + +Скаут особенно перспективен для больших проектов, повторных запросов к одному индексу и задач, где нужный код разбросан по зависимостям. Менее перспективен, когда пользователь уже указал точную функцию, проект мал или основное время уходит на размышление и долгие тесты. + +Наличие большого контекстного окна не делает поиск бесполезным: остаются расходы и время обработки. Но оно усиливает базовый вариант, с которым нужно честно сравнивать скаута. + +### Скорость поиска не равна скорости всей задачи + +Условный расчёт: поиск занимает 30% полного времени, его ускорили в 10 раз, остальное не изменилось. Итоговое ускорение: + +```text +1 / (0,70 + 0,30 / 10) = 1,37 раза +``` + +Это математический пример, а не измерение Astra. Он показывает, почему «поиск в десять раз быстрее» не означает «агент в десять раз быстрее». + +### Учитывать кэш + +Кэш повторно использует совпадающий префикс запроса. Изменение порядка старого контекста может уменьшить его повторное использование. Лучше добавлять новые результаты поиска последовательно и отдельно учитывать плату за запись и чтение кэша. [Официальное описание](https://developers.openai.com/api/docs/guides/prompt-caching) + +Поэтому сокращение входа на 80% не означает сокращение всего счёта на 80%: остаются output, reasoning, инструменты, повторные обращения и разная цена кэшированных токенов. + +## 10. Динамический MoE и диффузия + +### Что может означать «динамическое число экспертов» + +1. Имеется фиксированный набор весов, но для разных запросов включаются один, два или больше экспертов. +2. При обучении эксперты добавляются, удаляются или объединяются. +3. При работе новые эксперты создаются для новых проектов и дополнительно обучаются. + +Первые два варианта уже исследовались, в частности в DynMoE. Третий добавляет отдельные проблемы качества новых экспертов, данных, переключения версий и забывания. [DynMoE](https://arxiv.org/abs/2405.14297) + +Для маленького локального скаута маршрутизация и загрузка разных весов могут съесть экономию вычислений. Уменьшение числа активных параметров также не означает уменьшения суммарной памяти всех хранимых экспертов. + +Сначала разумнее сделать динамическим **объём работы**: число кандидатов, глубину обхода, необходимость cross-encoder и число раундов. Такой механизм проще проверить и привязать к реальной задержке. + +Если хочется именно эксперимента с MoE: общий текстовый encoder и 2–4 маленькие обучаемые головы для оценки разных отношений. Затем сравнить фиксированный выбор с адаптивным. Головы не станут «экспертом по БД» или «экспертом по авторизации» автоматически; специализацию надо измерить. При равных задержке и общей памяти сравнить с обычной плотной сетью. + +### Нужна ли диффузная модель + +Для выбора ID из уже найденного списка у генеративной диффузии нет очевидного преимущества: классификатор может оценить кандидатов одним проходом. Повторное уточнение набора возможно исследовать, но сначала нужно показать, что оно полезнее простого ранжирования или нескольких действий поиска. + +Графовое распространение оценок, например PageRank или message passing, — другой смысл слова «диффузия». Оно может быть полезным дешёвым компонентом поиска и не требует обучения языковой диффузной модели. + +Если цель — полезный инструмент на своём ПК, мой приоритет: **encoder → адаптивный поиск → при необходимости MoE**. Если цель — исследовать саму генеративную диффузию, это отдельный проект с другими метриками и данными. + +## 11. Ресурсы: что реально сделать на RTX 2080 Ti + +### Рабочие варианты + +| Работа | Оценка для 2080 Ti с 11 GB VRAM | +|---|---| +| Построение текстового индекса и графа | В основном задача CPU, RAM и диска | +| Inference encoder 30–150M на коротких фрагментах | Реалистичная стартовая цель; фактический batch и задержку измерить | +| Fine-tuning encoder около 150M | Реалистично при коротких последовательностях и небольшом batch; использовать накопление градиентов при необходимости | +| Обучение маленькой головы над готовыми векторами | Самый дешёвый вариант, возможен и без большой GPU | +| LoRA модели порядка 0,6–1B | Возможно при подходящих длине контекста и конфигурации; это не гарантия для произвольного стека | +| Полный AdamW fine-tuning 1B | Обычная конфигурация тесна для 11 GB ещё до активаций; лучше уменьшить модель или использовать адаптеры | +| Многошаговый RL с длинными генерациями | Для первого проекта неудобно: inference, rollout и обучение конкурируют за память и время | + +Эта таблица — оценка ресурсов, не выполненный тест. + +Для ориентира, только FP16-веса занимают примерно 2 байта на параметр: 50M ≈ 100 MB, 149M ≈ 298 MB, 1B ≈ 2 GB. При обучении добавляются градиенты, состояния оптимизатора, возможные копии весов и активации. Для стандартного обучения encoder статические состояния могут занимать порядка 12–20 байт на параметр в зависимости от реализации; активации считаются отдельно. + +2080 Ti относится к Turing. Использовать проверенный FP16-путь и не переносить автоматически BF16/FlashAttention-рецепты для H100. В текущей документации FlashAttention основной CUDA-путь FA2 рассчитан на более новые архитектуры; для Turing указан отдельный проект с подмножеством возможностей. [Совместимость](https://github.com/Dao-AILab/flash-attention) + +### RAM и диск + +Для пилота предлагаю **32 GB RAM** и **50–150 GB свободного SSD**, если скачивать только нужные проекты, веса и выбранные окружения. Для многочисленных контейнеров тестирования удобнее 64 GB RAM и 500 GB–1 TB SSD. Это запас под процесс разработки; конкретный набор окружений может потребовать больше. + +Сам векторный индекс часто намного меньше корпуса: 100 тысяч векторов по 384 FP16-компоненты — **76,8 MB сырых векторов**. К этому добавляются структура ANN-поиска, граф, метаданные, текст и дубли версий. Нельзя выдавать размер сырых векторов за размер всей системы. + +### Можно ли держать модель постоянно в памяти + +Да. Постоянный процесс загружает веса один раз, прогревает inference и обслуживает запросы. Между запросами занята память, но обучение не продолжается автоматически. Для encoder нет необходимости хранить огромный генеративный KV-кэш между независимыми заданиями. + +Граф и основной индекс удобно держать в RAM/на SSD, а GPU использовать для модели. Обновление репозитория меняет индекс; переобучать веса после каждого сохранения файла не требуется. + +### Нужно ли обучать всё с нуля + +Для первого результата — нет. Предобученный encoder уже умеет разбирать текстовые и кодовые закономерности; задача состоит в обучении полезному отбору. Маленькую голову или графовую сеть поверх готовых представлений можно обучать с нуля недорого. + +Предобучение языковой модели с нуля потребует отдельного корпуса, токенизации и множества экспериментов. Оно не нужно, чтобы исследовать уникальность политики поиска, и значительно затрудняет диагностику неудач. + +## 12. Деньги и сроки + +### Аренда GPU + +Цены публичной страницы Runpod на дату исследования, для раздела GPU Pods; наличие, конфигурации и сопутствующие расходы нужно проверять перед запуском: + +| GPU | VRAM | Указанная цена за час | 24 часа | +|---|---:|---:|---:| +| RTX A5000 | 24 GB | $0,27 | $6,48 | +| RTX 3090 | 24 GB | $0,50 | $12,00 | +| RTX 4090 | 24 GB | $0,74 | $17,76 | +| A100 | 80 GB | $1,59 | $38,16 | + +Это не сравнение скорости обучения. Более дешёвый час может дать более дорогой законченный эксперимент. Хранение и другие услуги считаются отдельно. [Тарифы Runpod](https://www.runpod.io/pricing) + +Для первого собственного encoder достаточно своей 2080 Ti. Аренда 24 GB GPU удобна для ускорения перебора конфигураций. A100 оправдана, если измерения показывают, что память или пропускная способность стали ограничением. + +### Как оценить длительность обучения + +Вместо обещания «натренируется за ночь» сначала прогнать 200–500 шагов и измерить реальную скорость с выбранными длинами и batch. + +Условный пример обучения на парах: + +```text +10 000 задач × 32 кандидата × 256 токенов × 3 эпохи += 245 760 000 обработанных токенов + +время ≈ токены / фактические токены в секунду +``` + +В 256 токенов здесь входят запрос, фрагмент и служебная разметка. Если фактическая длина больше или присутствует padding, объём возрастает. + +| Условно измеренная скорость | Чистое время | При тарифе $0,74/ч | +|---:|---:|---:| +| 2 000 токенов/с | 34,13 ч | $25,26 | +| 10 000 токенов/с | 6,83 ч | $5,05 | +| 30 000 токенов/с | 2,28 ч | $1,68 | + +**Это анализ чувствительности, а не результаты GPU-бенчмарка.** Ни одна строка не обещана для 2080 Ti или конкретной модели. Сверх этого оплачиваются подготовка, валидация, простои и повторные эксперименты. + +### Что сейчас включаем в бюджет + +Стоимость вызовов учителя и Astra исключена из текущей сметы. Это допущение о границах расчёта, а не утверждение, что эти вызовы бесплатны. Учитываем: + +- аренду GPU для обучения и локального inference; +- облачный диск и, при необходимости, CPU-окружения тестов; +- электричество при работе на своём ПК; +- время разработки, подготовки данных и проверки результатов — отдельно от денежных расходов. + +Объём проверки остаётся прежним: например, 100 задач × 2 системы × 3 повтора = 600 запусков. Оплата этих вызовов не учитывается, но длительность и доступная параллельность влияют на календарный срок. + +### Сценарии расходов на GPU + +Ниже — сценарии по выделенному числу GPU-часов, а не прогноз необходимого времени обучения. Использован тариф RTX 4090 $0,74/ч из таблицы выше. + +| Сценарий | Объём аренды | Расход на GPU | +|---|---:|---:| +| Прототип и первое обучение на своей 2080 Ti | 0 часов аренды | $0 за аренду; электричество отдельно | +| Короткая облачная проверка | 5–20 GPU-часов | $3,70–14,80 | +| Серия обучений и сравнений | 20–100 GPU-часов | $14,80–74,00 | +| Расширенный перебор или опыты с политикой поиска | 150–800 GPU-часов | $111–592 | + +Облачное хранение, дополнительные CPU и простои оплачиваются отдельно. Требуемое число GPU-часов станет известно после пробного обучения и выбора числа экспериментов. Последняя строка не является сметой полноценного RL крупной генеративной модели. + +### Плановый резерв и сроки + +Для первого цикла «микро-harness → данные → encoder → сравнение» разумно выделить **$50–200 на необязательную аренду и инфраструктуру**, сохранив возможность сделать его полностью на своей GPU. Это резерв, а не обязательная трата и не гарантированная верхняя граница. + +Календарный план не сокращается автоматически после исключения API-расходов: + +| Этап | Плановый срок одного разработчика | +|---|---| +| Проверка идеи без собственного обучения | 1–2 недели | +| Encoder, данные и парная оценка | Ещё 2–6 недель | +| Многошаговая политика и широкая оценка | Ещё 1–3 месяца при переходе к этому этапу | + +Основные ограничения теперь — качество разметки, разнообразие задач, время экспериментов и корректность сравнения. Учителя можно выбирать по качеству разметки, не оптимизируя его цену в этой смете. + +Сервисы аренды предоставляют вычисления; наборы вроде SWE-smith дают задачи и инструменты их создания. Основной интеллектуальный труд — постановка метрик, проверка данных и разбор ошибок. + +## 13. План первых восьми недель + +### Недели 1–2: проверить, есть ли полезный эффект + +- Начать с Python из-за доступности исполняемых SWE-данных; пользовательские языки добавить следующей независимой проверкой. +- Выбрать несколько проектов, создать контрольные snapshots и набор из 50–100 диагностических задач. +- Собрать микро-harness, графовый адаптер, текстовый поиск, чтение символов и журнал расходов. +- Сравнить обычный поиск, граф без обучения, готовый reranker и вручную подобранный контекст. +- Проверить обновления после правок и реальную задержку на своей GPU. + +**Решение по результату:** если идеальный или хороший ручной контекст не улучшает полезные показатели, уточнить сценарий до масштабирования обучения. + +### Недели 3–4: собрать данные и обучить первую модель + +- Подготовить начальные 5K задач, разнообразные кандидаты и сложные отрицательные примеры. +- Отдельно оставить проекты для настройки и финального теста. +- Обучить 149M encoder; сравнить с готовым reranker и простой головой над векторами. +- Проверить, помогает ли граф сверх текстовых признаков. +- Сохранить все версии данных, моделей и harness. + +**Решение по результату:** обученная модель должна давать пользу относительно готовых компонентов. Если её нет, использовать более простой вариант. + +### Недели 5–6: уменьшить задержку и проверить конечную пользу + +- Попробовать ученика 30–80M, укороченные представления, батчирование и подходящую квантизацию. +- Провести парные тесты с Astra, включая обычный дополнительный поиск. +- Измерить холодный запуск, тёплые запросы и обновление после изменений. +- Убедиться, что сокращение input не разрушает выигрыш от кэша. + +**Решение по результату:** принять или отвергнуть модель по полной стоимости и успешности; скорость отдельного слоя недостаточна. + +### Недели 7–8: учить выбор действий + +- Записать состояния, где фиксированный поиск тратит лишнее или пропускает контекст. +- Обучить выбор «прочитать / расширить / остановиться / передать управление». +- Проверить на новых проектах и с другой основной моделью. +- Добавить второй язык и сценарии живого редактирования. + +Полноценный RL, новые MoE-архитектуры и более широкая публикационная оценка могут выйти за эти восемь недель. При работе вечерами сроки увеличатся. + +## 14. Где искать своё отличие + +Самая перспективная для этого проекта формулировка: + +> Локальный скаут с небольшими весами, который выбирает достаточный контекст по живому графу кода и обучается расходовать поисковый бюджет внутри простого открытого harness. + +Четыре проверяемых направления: + +1. **Свежесть.** Работа с незавершёнными правками, переименованиями и сменой веток; тест на устаревшие рекомендации. +2. **Совместная полезность.** Выбор небольших групп «реализация + вызов + контракт + тест», а не только независимых похожих фрагментов. +3. **Обучаемый бюджет.** Простому вопросу — один поиск, сложному — несколько структурных шагов; оценивать фактическую стоимость решения. +4. **Доступное железо и воспроизводимость.** Открытые веса, данные, harness, замеры на 2080 Ti и сравнение с сильными стандартными средствами. + +Ни один пункт отдельно не гарантирует научную новизну. Ценность может быть в убедительно проверенной комбинации, качественном наборе данных и удобном работающем инструменте. + +## 15. Итоговое решение + +**Я бы начал проект с микро-harness и графового поиска, затем обучил небольшой encoder.** Такой порядок быстро покажет, где находится полезность: в индексе, в нейросети, в политике действий или в их сочетании. + +Связка с Astra технически реализуема и имеет правдоподобный путь к практической пользе. Прямых доказательств величины выигрыша именно для неё пока нет. Собственная 2080 Ti подходит для первых содержательных экспериментов. При исключённой оплате вызовов учителя и решателя основной денежный бюджет — необязательная аренда GPU и инфраструктура; главные ограничения — качество данных и время проверок. + +Первый результат, к которому стоит стремиться: **непереобучаемый на каждый проект локальный помощник, который на новых задачах измеримо сокращает время или расходы сильного агента при сохранении успешности**.