docs: translate research to English and outline Luna teacher workflow
This commit is contained in:
emil28092005
@@ -1,42 +1,44 @@
|
||||
# micro-scout
|
||||
|
||||
Исследовательский проект быстрого локального скаута контекста для программного кода.
|
||||
A research project for a fast, local code-context scout.
|
||||
|
||||
Скаут должен находить полезные исходные фрагменты, учитывать связи между символами и передавать контекст большой модели через небольшой агентский harness — цикл управления моделью и инструментами.
|
||||
The scout is designed to find useful source snippets, account for relationships between symbols, and pass context to a larger model through a small agent harness: the loop that manages the model and its tools.
|
||||
|
||||
## Статус
|
||||
## Status
|
||||
|
||||
Подготовлены исследование и план экспериментов. Реализация, обученные веса и собственные результаты измерений пока отсутствуют.
|
||||
The research report and experiment plan are available. Implementation, trained weights, and project-specific benchmark results are not available yet.
|
||||
|
||||
## Документация
|
||||
## Documentation
|
||||
|
||||
- [Исследование и план разработки](docs/RESEARCH_RU.md): существующие решения, Graphify, архитектура, данные, обучение, оценка пользы, ресурсы и восьминедельный план.
|
||||
- Дата исследования: 16 сентября 2026 года.
|
||||
- В текущей смете исключена оплата вызовов модели-учителя и основной модели; учитываются обучение своей модели и инфраструктура.
|
||||
- [Research and development plan](docs/RESEARCH.md): related work, Graphify, architecture, data, training, evaluation, resources, and an eight-week roadmap.
|
||||
- Research date: September 16, 2026.
|
||||
- The current budget excludes calls to the teacher and main models. It covers training the scout and the supporting infrastructure.
|
||||
|
||||
## Предлагаемая архитектура
|
||||
## Proposed architecture
|
||||
|
||||
```text
|
||||
Репозиторий и текущие изменения
|
||||
→ граф символов и поисковые индексы
|
||||
→ поиск кандидатов
|
||||
→ маленькая модель отбора и выбора действий
|
||||
→ исходные фрагменты с проверенными адресами
|
||||
→ большая модель и проверка решения
|
||||
Repository and working-tree changes
|
||||
→ symbol graph and search indexes
|
||||
→ candidate retrieval
|
||||
→ small model for selection and action choice
|
||||
→ source snippets with verified locations
|
||||
→ larger model and solution verification
|
||||
```
|
||||
|
||||
Факты о репозитории хранятся во внешнем обновляемом индексе. Модель обучается выбирать полезный контекст и действия поиска на новых проектах.
|
||||
Repository facts live in an external, updatable index. The model learns to select useful context and search actions for unfamiliar projects.
|
||||
|
||||
## Первые эксперименты
|
||||
One proposed training setup uses GPT-5.6 Luna to generate examples for the local scout, then evaluates the scout with GPT-6 Astra as the main solver. The research report describes how to check whether the learned retrieval behavior transfers between them.
|
||||
|
||||
1. Собрать минимальный harness с поиском, чтением символов и обходом графа.
|
||||
2. Сравнить обычный поиск, графовый поиск и готовый ранжировщик на одинаковых задачах.
|
||||
3. Измерить успешность решения, полную задержку, объём контекста и свежесть ссылок.
|
||||
4. Проверить пользу собственного encoder и затем уменьшить его размер.
|
||||
5. При подтверждённом эффекте обучать выбор действий и бюджета поиска.
|
||||
## Initial experiments
|
||||
|
||||
## Критерий полезности
|
||||
1. Build a minimal harness with search, symbol reading, and graph traversal.
|
||||
2. Compare conventional search, graph search, and an existing reranker on the same tasks.
|
||||
3. Measure task success, end-to-end latency, context size, and reference freshness.
|
||||
4. Evaluate a custom encoder, then reduce its size.
|
||||
5. If the benefit is confirmed, train action selection and search-budget allocation.
|
||||
|
||||
Сокращение времени решения при сохранении успешности на незнакомых репозиториях. Проверяются весь агентский цикл, дополнительные чтения и обновление индекса, а не только скорость отдельного вызова модели.
|
||||
## Success criterion
|
||||
|
||||
Целевые размеры моделей, задержки и бюджеты в исследовании являются гипотезами для проверки, а не опубликованными результатами micro-scout.
|
||||
Reduce time to solution while maintaining task success on unfamiliar repositories. Evaluation covers the full agent loop, additional reads, and index updates, as well as individual model-call latency.
|
||||
|
||||
Model sizes, latency targets, and budgets in the report are hypotheses to test. They are not measured micro-scout results.
|
||||
|
||||
@@ -0,0 +1,595 @@
|
||||
# A Small Code-Context Scout: Research and Experiment Plan
|
||||
|
||||
**Date: September 16, 2026.** Scope: a fast local context-retrieval model, Graphify-Labs/graphify, a custom minimal harness, and collaboration with GPT-6 Astra.
|
||||
|
||||
This document reviews sources and proposes experiments. No training or measurements on an RTX 2080 Ti have been performed. Latency targets, development timelines, and project budgets below are engineering estimates; findings from other projects are identified separately.
|
||||
|
||||
**Budget scope:** calls to the teacher and main models are currently excluded at the user's request. The budget covers training the scout, GPU resources, and infrastructure. Request volume and evaluation time remain part of the plan.
|
||||
|
||||
## 1. Conclusion
|
||||
|
||||
**The project is worth testing. The strongest starting point is a small, trainable context-retrieval and selection system inside a simple custom harness.** The repository graph lives outside the model and is updated as code changes. The larger model receives selected source snippets and can request further searches.
|
||||
|
||||
A realistic goal is to reduce retrieval time and cost while maintaining the task success rate. Quality improvements are possible, particularly for tasks involving relationships across files, but require a comparative experiment before any claim can be made.
|
||||
|
||||
Key decisions:
|
||||
|
||||
- Start with a graph, conventional search, and an existing reranker: a model that orders retrieved snippets by usefulness.
|
||||
- Check whether this helps Astra before training a custom network.
|
||||
- Then train an encoder with roughly 150M parameters; if the benefit is confirmed, compress it to 30–80M.
|
||||
- First train snippet selection. Later, train search actions and stopping decisions.
|
||||
- Measure the full task-solving loop, including repeated searches, index construction, caching, and tests.
|
||||
- Keep diffusion and a variable number of MoE experts as separate research branches.
|
||||
|
||||
The combination of a small scout and a larger model already exists. Potential distinguishing features are local execution on an affordable GPU, a fresh graph of changing code, an adaptive search budget, and open evaluation of practical benefits.
|
||||
|
||||
## 2. Existing Work and What It Establishes
|
||||
|
||||
| Work / product | Connection to the idea | Implications |
|
||||
|---|---|---|
|
||||
| **SWE-grep / SWE-grep-mini, Cognition** | A specialized retrieval model that returns files and line ranges to the main agent; trained to search using tools | A direct precedent for the overall concept. The authors report speedups on their infrastructure, not measurements on a 2080 Ti or with Astra. [Primary source](https://cognition.com/blog/swe-grep) |
|
||||
| **FastCode, March 2026** | Hybrid retrieval, a structural graph, progressive reading, and adaptive cost management | A close precedent for the proposed system. Compare against algorithmic retrieval as well as basic grep. [Paper](https://arxiv.org/html/2603.01012v1) |
|
||||
| **LocAgent, ACL 2025** | Code localization through a graph of files, classes, functions, and dependencies | Supports using graphs to locate code that needs changes. Its trained model is substantially larger than the proposed scout. [Paper](https://aclanthology.org/2025.acl-long.426/) |
|
||||
| **Aider repo map** | Graph-based selection of important symbols within a token budget | An essential low-cost baseline that requires no custom training. [Documentation](https://aider.chat/docs/repomap.html) |
|
||||
| **Repoformer, 2024** | Learning to use external context selectively | A useful principle: learn when retrieval helps. The original task is code completion; transfer to bug fixing needs evaluation. [Paper](https://arxiv.org/abs/2403.10059) |
|
||||
| **GraphCodeBERT, 2020** | Code representations that incorporate data flow, or dependencies between values | Learning from code structure has a long history. Adding a graph alone does not establish research novelty. [Paper](https://arxiv.org/abs/2009.08366) |
|
||||
| **TinyAgent, 2024** | Specialized small models for function calling | Supports the feasibility of a narrowly scoped local agent. Its tasks and results are different from repository retrieval. [Paper](https://arxiv.org/abs/2409.00608) |
|
||||
| **Agent Lightning v1.0, August 2026** | Training an agent directly inside its deployment harness | Supports the relevance of training with the execution environment. It is training infrastructure, not a ready-made small scout model. [Paper](https://arxiv.org/html/2608.17528v1) |
|
||||
|
||||
### Strongest practical evidence
|
||||
|
||||
Cognition describes SWE-grep as a separate search assistant with bounded search rounds, parallel tool calls, and references to source code. The company reports that its combination with Sonnet 4.5 solved the same task set faster. This supports the viability of separating these roles, but remains a developer report on its own configuration. The reported high generation throughput was achieved on Cerebras and does not characterize consumer GPUs. [Experiment description](https://cognition.com/blog/swe-grep)
|
||||
|
||||
### The remaining research question
|
||||
|
||||
**Can a model with at most 150M parameters, an external graph, and bounded search improve a strong agent's tradeoff between success, latency, and cost on unfamiliar repositories and changing code?**
|
||||
|
||||
This question is specific, allows for a negative result, and goes beyond reproducing an existing product's interface. Any future paper would still need to establish novelty relative to work available at publication time.
|
||||
|
||||
## 3. Assessing the Evidence for Graphify
|
||||
|
||||
### What it provides
|
||||
|
||||
Graphify-Labs/graphify uses tree-sitter for its structural pass over code, which requires no LLM. It builds a graph and provides retrieval and relationship exploration. Semantic processing of documents and other materials is a separate mechanism. The project distinguishes extracted, inferred, and ambiguous relationships; these labels describe edge provenance, not calibrated probabilities of correctness. [Graphify repository](https://github.com/Graphify-Labs/graphify)
|
||||
|
||||
### What its evaluations show
|
||||
|
||||
The published BENCHMARKS.md dated July 5, 2026 includes **6 code questions about ERPNext**. It reports an increase in reference-fact coverage from 70.8% to 82.0%. This measures answers to questions, not the share of bugs fixed. Its larger main tables concern conversational memory. These results are useful demonstrations, but insufficient to establish an advantage across repositories or with Astra. [Published setup and results](https://raw.githubusercontent.com/Graphify-Labs/graphify/v8/BENCHMARKS.md)
|
||||
|
||||
### How to use it in this project
|
||||
|
||||
Treat Graphify as a source of external structure and an existing retrieval option. It is **not a neural-network training algorithm**.
|
||||
|
||||
Proposed responsibilities:
|
||||
|
||||
1. The parser and language tools extract structure.
|
||||
2. The index stores files, symbols, relationships, and versions.
|
||||
3. The trainable model decides which snippets are needed for the current task.
|
||||
4. The harness executes searches, checks versions, and assembles the response.
|
||||
|
||||
There is no need to train separate weights for every repository. The model should transfer its selection skill to new code and obtain facts about the current project from the index.
|
||||
|
||||
A static graph is incomplete: dynamic dispatch, reflection, dependency injection, configuration, SQL, templates, and generated files introduce relationships that are difficult to recover from the AST alone. An absent edge therefore cannot establish the absence of a dependency. Store the provenance and reliability of relationship types; add compiler or LSP information for typed languages.
|
||||
|
||||
An integration requirement is to verify symbol existence, line ranges, and file freshness when reading. A line number is an address within a version, not a permanent identifier.
|
||||
|
||||
## 4. What the Model Should Predict
|
||||
|
||||
Inputs are the user's task, current search state, a bounded candidate set, graph features, and remaining budget. Outputs are candidate scores and, later, the next action.
|
||||
|
||||
A weak training objective is to recover the path of the patched file. It encourages memorizing names and ignores context required to solve the task correctly.
|
||||
|
||||
A more useful objective is to **assemble a small set of source snippets that gives the main model a high probability of solving the task**.
|
||||
|
||||
For example, consider a task where a retry still starts after a request is cancelled. Useful context might include:
|
||||
|
||||
- the cancellation handler;
|
||||
- the retry loop;
|
||||
- the cancellation-token interface;
|
||||
- the calling function;
|
||||
- a test of the expected behavior.
|
||||
|
||||
The file containing the eventual fix is only part of that set. Two snippets may be useful only together, so independent top-k selection by similarity is not always sufficient.
|
||||
|
||||
### Response format
|
||||
|
||||
The following is an illustrative protocol. Ordinary code constructs the JSON; the model selects existing identifiers.
|
||||
|
||||
```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": "...source code..."
|
||||
}
|
||||
],
|
||||
"next_action": "expand_callers",
|
||||
"next_target_ids": ["retry-loop-17"],
|
||||
"stop_reason": null,
|
||||
"budget_remaining_tokens": 4200
|
||||
}
|
||||
```
|
||||
|
||||
The external response must include content or an immediate way to read it through a tool. A local path alone does not transmit code to a cloud model.
|
||||
|
||||
A ranking score should not be presented as 95% confidence that the context is sufficient. That probability requires a separately trained and evaluated calibrator. Initially, explicit stopping reasons are enough: the budget is exhausted, there are no new candidates, or further search has been requested.
|
||||
|
||||
## 5. Recommended Architecture
|
||||
|
||||
```mermaid
|
||||
flowchart TD
|
||||
A[Files and working-tree changes] --> B[Parser and version checks]
|
||||
B --> C[Graph, text index, and vectors]
|
||||
Q[Task and budget] --> D[Low-cost candidate retrieval]
|
||||
C --> D
|
||||
D --> E[Small selection model]
|
||||
E --> F{Continue searching?}
|
||||
F -->|Yes| G[Read symbols and graph neighbors]
|
||||
G --> E
|
||||
F -->|No| H[Source context package]
|
||||
H --> I[Larger model]
|
||||
I -->|Follow-up query| D
|
||||
I --> J[Code changes and verification]
|
||||
```
|
||||
|
||||
### 5.1. Indexing
|
||||
|
||||
Parse the repository once, then update changed files and affected relationships. Store AST boundaries, signatures, content, references, tests, and metadata. Avoid automatically indexing dependencies, build outputs, minified files, and large duplicates.
|
||||
|
||||
A live editor needs a snapshot that includes uncommitted changes. If the index is older than a file, revalidate it or read the current file directly. Use text search as a fallback for incomplete syntax.
|
||||
|
||||
### 5.2. Low-cost retrieval
|
||||
|
||||
Combine exact identifier search, BM25, which weights words by their rarity, and vector similarity. Merge results and add a bounded number of graph neighbors. Initial experimental settings: 100–300 candidates before filtering and 16–64 before expensive scoring. These are hyperparameters to test, not established optima.
|
||||
|
||||
If a required snippet never enters the candidate set, the reranker cannot recover it. Measure initial retrieval recall separately.
|
||||
|
||||
### 5.3. Two neural-component options
|
||||
|
||||
**Lowest cost:** precomputed code vectors, a query vector, and a small network that also uses relationship type, graph distance, lexical matches, and snippet cost. This avoids passing source code through a large encoder for every query.
|
||||
|
||||
**Higher accuracy:** a cross-encoder reads the query together with each of a few dozen snippets. This costs more but can account for details lost in a precomputed vector.
|
||||
|
||||
A practical cascade is cheap scoring of all candidates, followed by a cross-encoder for the uncertain top candidates, then context assembly. Report the encoder, embedder, and ranking heads when stating system size. A 5M head on top of a resident 600M model does not make the entire system a 5M model.
|
||||
|
||||
### 5.4. Initial comparison models
|
||||
|
||||
- **Qwen3-Reranker-0.6B** is a ready-made baseline supporting multiple languages and code. Its scoring example uses yes/no logits; lengthy reasoning generation is not required. [Model card and inference example](https://huggingface.co/Qwen/Qwen3-Reranker-0.6B)
|
||||
- **ModernBERT-base, 149M** is a candidate for training a custom query–code scorer. It is a pretrained backbone, not a ready-made ideal search model. Its pretraining includes code. [Model card](https://huggingface.co/answerdotai/ModernBERT-base)
|
||||
- After successful fine-tuning, train a **30–80M** student to reproduce useful scores and decisions from a stronger teacher. This range is a project target.
|
||||
|
||||
For Russian queries, evaluate quality separately and compare query translation, mixed RU/EN training, and a multilingual reranker. Translations of the same task must stay in the same dataset split.
|
||||
|
||||
### 5.5. Where speed comes from
|
||||
|
||||
The main expected gain comes from reducing repeated work: avoid reading the entire repository on each query, avoid generating long responses, cache unchanged code, keep weights loaded, and score short snippets in batches.
|
||||
|
||||
For the initial experiment, the proposed warm-retrieval target is a **100–300 ms median and under 1 second for 95% of requests** on an already indexed project. This is an ambitious evaluation target, not a forecast for every 2080 Ti configuration. Measure cold starts and index updates separately.
|
||||
|
||||
A direct PyTorch service is a sufficient starting point for an encoder. Replacing Ollama with vLLM does not resolve the design question: first choose the architecture and measure its inference. A more complex generation server becomes relevant if the system actually uses a generative model with an appropriate workload.
|
||||
|
||||
## 6. Why Build a Minimal Custom Harness?
|
||||
|
||||
A harness is the program that maintains state, calls the model and tools, enforces limits, and records outcomes. **A custom harness is useful for both execution and collecting training trajectories.**
|
||||
|
||||
Start with two logical loops in one application:
|
||||
|
||||
- The inner loop lets the scout retrieve context, read code, and decide what to return.
|
||||
- The outer loop lets the stronger model analyze the task, change code, and run checks.
|
||||
|
||||
Separate processes or multiple conversational agents are optional. A clear protocol between retrieval and problem solving matters more.
|
||||
|
||||
A standalone mode without the larger model is also possible: a local tool can find symbols, show dependencies, assemble context, and suggest related tests. This is a useful initial product. Autonomous code editing would require separate training and evaluation of patch generation; retrieval success does not establish reliable problem solving.
|
||||
|
||||
### Minimal scout environment
|
||||
|
||||
| Action | Responsibility of ordinary code | Model decision |
|
||||
|---|---|---|
|
||||
| `search` | Execute text and vector retrieval | Choose a candidate query; later, refine the query |
|
||||
| `read_symbols` | Read existing ranges | Select symbol identifiers |
|
||||
| `expand_neighbors` | Retrieve relationships of a given type | Select nodes, relationship type, and depth |
|
||||
| `find_tests` | Find available tests through the index | Select candidates to inspect |
|
||||
| `emit_context` | Check versions and merge snippets | Select and order snippets |
|
||||
| `request_fallback` | Return control to the main model | Decide when the scout budget is exhausted or search is unproductive |
|
||||
|
||||
Implement path validation, available actions, deduplication, token budgets, timeouts, and tracing deterministically. The initial scout only needs read access; code changes and test execution remain in the outer loop.
|
||||
|
||||
The simplest baseline has no learned action policy: the harness always runs retrieval, one neighbor-expansion pass, and reranking. This is an essential control. A learned policy is justified only if it saves time or improves quality over this fixed sequence.
|
||||
|
||||
### Training inside the harness
|
||||
|
||||
1. **Record demonstrations.** A strong teacher or a person uses the same tools. Store observations, selected IDs, actions, and outcomes.
|
||||
2. **Learn from examples.** Start with ranking and imitation of successful short trajectories. Avoid copying the teacher's entire verbose conversation.
|
||||
3. **Collect student errors.** Obtain corrected actions for states the student actually visits. Otherwise, search errors accumulate after the first deviation from a demonstration.
|
||||
4. **Add outcome-based learning.** Compare context sets or retrieval strategies by usefulness to the solver, time, and cost.
|
||||
5. **Evaluate transfer.** Use other repositories, another main model, and at least one other harness.
|
||||
|
||||
For a single decision, such as selecting a budget or search strategy, a contextual bandit is initially sufficient: learn an action choice from its outcome. A sequence of dependent actions is a setting for full reinforcement learning, or RL.
|
||||
|
||||
Training must use only observations available to the model at that moment. Logs need repository and harness versions, available actions, arguments, results, and resource usage. A stored trajectory describes one visited path; it does not automatically reveal the result of an unvisited action. Comparing alternatives requires new runs or replaying tools on the same snapshot. Update weights through separately evaluated versions rather than automatically after each user request.
|
||||
|
||||
One possible training objective:
|
||||
|
||||
```text
|
||||
utility = task success
|
||||
− time penalty
|
||||
− cost penalty
|
||||
− penalty for stale or invalid references
|
||||
```
|
||||
|
||||
Tune coefficients on validation data. A more reliable product objective is to minimize latency and cost **subject to a limit on acceptable degradation in task success**. A single scalar reward can conceal a loss of quality.
|
||||
|
||||
End-to-end task success is a noisy and expensive signal. An Astra failure does not necessarily imply poor context; a correct answer does not establish that every supplied snippet was needed. Start with cheap retrieval metrics, then run selected paired solver evaluations. Astra can remain unchanged: only the scout's weights are updated, with no gradients through the closed model.
|
||||
|
||||
### Research support
|
||||
|
||||
mini-SWE-agent shows that a useful agent loop can be very simple. It provides a good reference for a research harness and reproducible trajectories. Its results depend on the main model. [Repository](https://github.com/SWE-agent/mini-swe-agent)
|
||||
|
||||
In Agent Lightning v1.0, the authors train Qwen3.5-9B with mini-SWE-agent and report an increase on SWE-bench Verified from 41.8% to 56.4% under their protocol, using about 6,000 training tasks. This is evidence for training inside a harness, not a promise of similar gains for a 50M scout or a resource estimate for one 2080 Ti. [Paper and setup](https://arxiv.org/html/2608.17528v1)
|
||||
|
||||
The proposed classification model does not require a full RL infrastructure at the outset. A simple loop, logs, and PyTorch can test much of the hypothesis. Add Agent Lightning or a similar stack when large-scale trajectory collection and training a multi-step generative policy become necessary.
|
||||
|
||||
## 7. Data Sources and Generation
|
||||
|
||||
### Existing sources
|
||||
|
||||
| Source | Role in the project | Limitation |
|
||||
|---|---|---|
|
||||
| **SWE-smith** | Tasks with injected bugs, fixes, and executable checks; a basis for generating retrieval trajectories | Synthetic bugs do not cover the full distribution of real tasks. Tens of thousands of examples are available; select a high-quality subset. [Project](https://swesmith.com/) |
|
||||
| **CodeSearchNet** | Additional description–function pairs for learning semantic alignment | Retrieving a function from its description is easier than assembling context for a bug spanning files. [Dataset](https://github.com/github/CodeSearchNet) |
|
||||
| **ContextBench** | Primarily independent evaluation of context retrieval | Keep its tasks and overlapping repositories out of training. [Paper](https://arxiv.org/abs/2602.05892) |
|
||||
| **Authorized repositories and real tasks from our own work** | User phrasing, uncommitted changes, and the student's retrieval errors | Reserve a separate set of projects and tasks that training never sees |
|
||||
|
||||
ContextBench contains 1,136 tasks from 66 repositories across eight languages, with context annotations. Its authors measure recall, precision, and use of retrieved code. Their results show that a more complex harness does not guarantee better retrieval. The benchmark builds on existing task datasets, so check for overlap when combining sources. [Methodology](https://arxiv.org/html/2602.05892v1)
|
||||
|
||||
### Can a model generate the dataset?
|
||||
|
||||
Yes. The most useful synthetic data is grounded in **executable code and verifiable changes**. Invented repositories and supposedly correct references produce overly simple and often incorrect examples.
|
||||
|
||||
Proposed pipeline:
|
||||
|
||||
1. Select a real project snapshot and a task with a verifiable solution.
|
||||
2. Index the original, unfixed state.
|
||||
3. Retrieve candidates using several methods, including false matches.
|
||||
4. Give the teacher the task and the same tools available to the student.
|
||||
5. Collect required symbols, useful relationships, and a short action sequence.
|
||||
6. Validate IDs, ranges, versions, and test executability with ordinary code.
|
||||
7. For a subset of examples, run the solver with this context and compare several context sets.
|
||||
8. Manually review ambiguous cases and systematic labeling errors.
|
||||
|
||||
The fix diff can be an auxiliary labeling source, but must not be a retrieval input. A teacher shown the solution may reveal names and causal relationships unavailable during real use. Keep these hints separate from the student's observations.
|
||||
|
||||
### Luna as a teacher, Astra as the solver
|
||||
|
||||
One proposed experiment is to use **GPT-5.6 Luna to generate training examples**, train the local scout on those examples, and deploy the scout as a retrieval tool for **GPT-6 Astra**. The teacher and downstream solver do not have to be the same model. Luna supports function calling and structured outputs, which can help collect search demonstrations and candidate judgments in a consistent format. [Luna documentation](https://developers.openai.com/api/docs/models/gpt-5.6-luna)
|
||||
|
||||
This trains **our scout**, using teacher outputs as supervision. It does not require fine-tuning Luna, accessing its weights, or propagating gradients through either hosted model. Supervised training on these examples is distillation; it is not by itself reinforcement learning.
|
||||
|
||||
Suggested experiment:
|
||||
|
||||
1. Let Luna inspect real task snapshots through the harness and propose relevant symbol IDs, candidate preferences, and short search trajectories.
|
||||
2. Validate locations and snapshot versions, run available checks, and retain uncertainty instead of turning every omission into a negative label.
|
||||
3. Review a sample of labels and difficult cases with a person or Astra. Keep those judgments separate from independent final evaluation.
|
||||
4. Train the scout, freeze its version, and compare Astra with and without it on held-out repositories under matched tool and context budgets.
|
||||
|
||||
The main uncertainty is **whether the learned retrieval behavior transfers**. Context that helps Luna may be incomplete or redundant for Astra, and the scout may inherit Luna's search mistakes. Luna's ratings alone therefore cannot establish an improvement for Astra. If the transfer is weak, use Astra feedback on separate training or development tasks to refine the data or ranking objective, then evaluate on a fresh held-out set. Teacher and solver call charges remain outside the current budget scope.
|
||||
|
||||
### Three levels of label quality
|
||||
|
||||
**Low cost:** changed symbols, discovered references, and nearby tests. These are weak labels; they do not establish usefulness for solving the task.
|
||||
|
||||
**Medium cost:** a teacher evaluates candidates using all available context and selects groups that are useful together. A person reviews a sample of these judgments.
|
||||
|
||||
**High cost:** compare the larger model's results under different context sets. Remove snippets individually or in groups and measure changes in success. This approximates a causal check; generation variability requires repeated trials rather than a single teacher response.
|
||||
|
||||
Do not label every unselected snippet as negative: some may be valid alternative context. Keeping positive, verified-negative, and unknown labels is more useful than assuming the annotations are complete.
|
||||
|
||||
### Using the graph during training
|
||||
|
||||
- Supply relationship types, distances, node roles, and extraction reliability as features.
|
||||
- Add auxiliary tasks involving references and relationships between symbols.
|
||||
- Train selection among implementations, callers, tests, configuration, and interfaces.
|
||||
- Include hard negatives: functions with the same name, a similar module, an outdated version, or a neighbor that does not help the task.
|
||||
- Evaluate the usefulness of sets: an implementation without its caller is often insufficient.
|
||||
|
||||
The primary label should reflect utility for the task. Learning only to reproduce graph adjacency would create an expensive replacement for graph traversal.
|
||||
|
||||
### Initial data volume
|
||||
|
||||
For the first cycle, the proposed starting point is **5,000–20,000 distinct training tasks** with candidate sets and **200–500 carefully reviewed development and diagnostic tasks**, separated by purpose. This is an initial estimate; the required volume should be determined by the quality curve as data is added.
|
||||
|
||||
A thousand tasks with 32 candidates each produce 32,000 pairs, but still only a thousand independent tasks. Dataset row count does not replace project diversity.
|
||||
|
||||
Keep the final test set separate. Split by repository, fork family, task, and time; remove near-duplicate code across splits. Git history and access to future fixes must not reveal the answer. Store the provenance and usage terms of source data and teacher models for each example.
|
||||
|
||||
## 8. Demonstrating Value with Astra
|
||||
|
||||
### Systems to compare
|
||||
|
||||
| Variant | What it tests |
|
||||
|---|---|
|
||||
| A. Strong model with conventional search/read | Practical baseline |
|
||||
| B. Same model with existing graph retrieval and no custom training | Contribution of indexing and structure |
|
||||
| C. B with an existing reranker | Whether a custom neural model is needed |
|
||||
| D. B with a custom trained encoder | Contribution of task-specific training |
|
||||
| E. D with a learned action policy | Contribution of an adaptive minimal harness |
|
||||
| O. Human-verified reference context | Approximate potential benefit of ideal retrieval |
|
||||
|
||||
Hold the main model, settings, code-editing tools, available source, time limits, and success criteria fixed across variants. A competent baseline matters more than a flattering comparison against a weak grep-like script.
|
||||
|
||||
Evaluate two modes separately:
|
||||
|
||||
1. **Fixed context:** the solver receives only the selected snippets. This helps diagnose retrieval losses.
|
||||
2. **Working agent:** the solver can read missing information. This is the primary practical test; account for all additional reads and their resource use.
|
||||
|
||||
### Metrics
|
||||
|
||||
- **Candidate recall:** whether the required code reaches the initial candidate list.
|
||||
- **Selected-context recall and precision:** how much relevant material is found and how much irrelevant material is supplied, including under a fixed token budget.
|
||||
- **Evidence-group coverage:** whether jointly required implementations, calls, tests, and configuration are retrieved together.
|
||||
- **End-to-end task success:** patches pass independent checks; answers to questions are verified against source code.
|
||||
- **Cost per successful solution:** total expenditure on all attempts, including failures, divided by the number of successful tasks.
|
||||
- **Time to solution:** median and 95th percentile, separately for retrieval and the full loop.
|
||||
- **Freshness:** the rate of stale references after edits, renames, and branch switches.
|
||||
- **Transfer:** performance on new repositories, languages, and another strong model.
|
||||
|
||||
A ranking metric alone does not establish practical value. Conversely, slightly lower recall may be acceptable if the main agent quickly recovers omissions and solves tasks more cheaply. Missing context has a much higher cost when additional reading is prohibited.
|
||||
|
||||
### Avoiding misleading conclusions
|
||||
|
||||
Use the first 50–100 tasks to identify major failures and estimate effect size. Claiming that quality barely deteriorates requires a larger paired evaluation with confidence intervals; the number of tasks depends on how often the variants disagree. A hundred tasks usually cannot convincingly establish a difference of about one percentage point.
|
||||
|
||||
Use paired comparisons on identical tasks, repeated runs under noisy conditions, analysis by repository, and bootstrap resampling grouped by project. Publish failure cases alongside averages. Do not select the best configuration using the final test set.
|
||||
|
||||
### Proposed criteria for continuing
|
||||
|
||||
These are product targets for the experiment, not promised results. While model-call costs are excluded from the budget, time at a maintained success rate is the main criterion; monetary savings can be evaluated later:
|
||||
|
||||
- at least **20% lower total cost** or **15% less end-to-end time**;
|
||||
- no decline in success beyond a predefined tolerance, such as **2 percentage points**, with sufficient statistical confidence;
|
||||
- benefits on several unfamiliar projects;
|
||||
- benefits persist after accounting for caching, indexing, and repeated reads.
|
||||
|
||||
If even reference context offers little benefit, stop the expensive scout-training effort for that scenario. If an untrained graph system already meets the target, it can serve as the product; justify any neural component through a separate measurement.
|
||||
|
||||
## 9. Can It Help GPT-6 Astra?
|
||||
|
||||
**Integration is technically feasible. The size of the practical benefit is unknown.** This review did not find a published comparative evaluation of the proposed scout with Astra.
|
||||
|
||||
At the time of this review, official documentation lists function calling, structured outputs, and MCP support for Astra. It can use a tool that returns retrieved code without fine-tuning Astra itself. [Model documentation](https://developers.openai.com/api/docs/models/gpt-6-astra)
|
||||
|
||||
Two integration paths:
|
||||
|
||||
- **Custom harness through the API:** the application receives Astra's tool request, calls the local scout, and returns the result. [Function calling](https://developers.openai.com/api/docs/guides/function-calling)
|
||||
- **Use inside Codex:** expose retrieval through a local MCP server. This gives the agent another tool; its behavior and decisions about when to call it need practical evaluation. [MCP documentation](https://learn.chatgpt.com/docs/extend/mcp?surface=cli)
|
||||
|
||||
The scout is especially promising for large projects, repeated requests against the same index, and tasks whose required code is scattered across dependencies. It is less promising when the user already identifies the exact function, the project is small, or reasoning and long-running tests dominate execution time.
|
||||
|
||||
A large context window does not eliminate the value of retrieval: processing time and cost still matter. It does, however, strengthen the baseline against which the scout must be compared fairly.
|
||||
|
||||
### Retrieval speed versus total task time
|
||||
|
||||
Illustrative calculation: retrieval accounts for 30% of total time, it becomes ten times faster, and everything else stays unchanged. The overall speedup is:
|
||||
|
||||
```text
|
||||
1 / (0.70 + 0.30 / 10) = 1.37 times
|
||||
```
|
||||
|
||||
This is a mathematical example, not an Astra measurement. It shows why a tenfold retrieval speedup does not imply a tenfold agent speedup.
|
||||
|
||||
### Account for caching
|
||||
|
||||
Caching reuses a matching prompt prefix. Reordering earlier context can reduce reuse. Prefer appending new retrieval results and account separately for cache-write and cache-read charges. [Official documentation](https://developers.openai.com/api/docs/guides/prompt-caching)
|
||||
|
||||
Reducing input by 80% therefore does not imply an 80% reduction in the total bill: output, reasoning, tools, repeated calls, and different cached-token rates remain relevant.
|
||||
|
||||
## 10. Dynamic MoE and Diffusion
|
||||
|
||||
### Possible meanings of a dynamic expert count
|
||||
|
||||
1. A fixed pool of weights exists, but different requests activate one, two, or more experts.
|
||||
2. Experts are added, removed, or merged during training.
|
||||
3. New experts are created and trained for new projects during use.
|
||||
|
||||
The first two options have already been studied, including in DynMoE. The third introduces additional problems involving new-expert quality, data, version switching, and forgetting. [DynMoE](https://arxiv.org/abs/2405.14297)
|
||||
|
||||
For a small local scout, routing and loading different weights may consume the expected compute savings. Fewer active parameters also do not imply less total memory for all stored experts.
|
||||
|
||||
First make the **amount of work** adaptive: candidate count, traversal depth, whether a cross-encoder is needed, and the number of rounds. This is easier to evaluate against actual latency.
|
||||
|
||||
For an MoE-specific experiment, use a shared text encoder with 2–4 small trainable heads that score different relationships. Compare fixed and adaptive selection. Heads do not automatically become database or authorization experts; measure specialization. Compare against a dense network at equal latency and total memory.
|
||||
|
||||
### Is a diffusion model needed?
|
||||
|
||||
Generative diffusion has no obvious advantage when selecting IDs from an existing candidate list: a classifier can score candidates in one pass. Iterative refinement of a set is a possible research topic, but first show that it outperforms simple ranking or a few retrieval actions.
|
||||
|
||||
Graph-based score propagation, such as PageRank or message passing, uses a different meaning of diffusion. It may be a useful low-cost retrieval component and does not require training a diffusion language model.
|
||||
|
||||
For a useful tool on a personal computer, the recommended order is **encoder, adaptive retrieval, then MoE if needed**. Researching generative diffusion itself would be a separate project with different metrics and data.
|
||||
|
||||
## 11. Resources: What Is Feasible on an RTX 2080 Ti?
|
||||
|
||||
### Practical options
|
||||
|
||||
| Workload | Assessment for a 2080 Ti with 11 GB VRAM |
|
||||
|---|---|
|
||||
| Text-index and graph construction | Primarily a CPU, RAM, and disk workload |
|
||||
| Inference with a 30–150M encoder on short snippets | A realistic starting target; measure actual batch size and latency |
|
||||
| Fine-tuning an encoder of about 150M | Realistic with short sequences and small batches; use gradient accumulation where needed |
|
||||
| Training a small head over existing vectors | The cheapest option; possible without a large GPU |
|
||||
| LoRA for a model of roughly 0.6–1B | Possible with suitable context length and configuration; not guaranteed for an arbitrary stack |
|
||||
| Full AdamW fine-tuning of a 1B model | A conventional configuration is tight for 11 GB even before activations; use a smaller model or adapters |
|
||||
| Multi-step RL with long generations | Inconvenient for the first project: inference, rollouts, and training compete for memory and time |
|
||||
|
||||
This table is a resource estimate, not a completed benchmark.
|
||||
|
||||
For reference, FP16 weights alone take about 2 bytes per parameter: 50M is approximately 100 MB, 149M about 298 MB, and 1B about 2 GB. Training adds gradients, optimizer state, possible weight copies, and activations. Static state for conventional encoder training may take roughly 12–20 bytes per parameter, depending on the implementation; activations are additional.
|
||||
|
||||
The 2080 Ti is a Turing GPU. Use a validated FP16 path rather than assuming BF16 or FlashAttention recipes for an H100 will transfer. At the time of this review, the main FlashAttention-2 CUDA path targets newer architectures; its documentation points to a separate Turing project with a subset of features. [Compatibility](https://github.com/Dao-AILab/flash-attention)
|
||||
|
||||
### RAM and disk
|
||||
|
||||
For the pilot, the proposed starting point is **32 GB RAM** and **50–150 GB of free SSD space**, downloading only the projects, weights, and selected environments needed. For numerous test containers, 64 GB RAM and a 500 GB–1 TB SSD are more convenient. These are development allowances; a particular environment collection may need more.
|
||||
|
||||
The vector index alone is often much smaller than the corpus: 100,000 vectors with 384 FP16 components require **76.8 MB of raw vectors**. ANN search structures, the graph, metadata, text, and duplicate versions add to that total. Raw vector size is not the size of the entire system.
|
||||
|
||||
### Keeping the model resident
|
||||
|
||||
Yes. A persistent process can load weights once, warm up inference, and serve requests. Memory stays allocated between requests, but training does not continue automatically. An encoder does not need a large generative KV cache between independent tasks.
|
||||
|
||||
Keep the graph and main index in RAM or on SSD, and use the GPU for the model. Repository updates change the index; weights do not need retraining after each file save.
|
||||
|
||||
### Is training from scratch necessary?
|
||||
|
||||
Not for the initial result. A pretrained encoder already captures text and code patterns; the task is to teach useful selection. A small head or graph network over existing representations can be trained from scratch inexpensively.
|
||||
|
||||
Pretraining a language model from scratch requires a separate corpus, tokenization, and many experiments. It is unnecessary for investigating a novel retrieval policy and makes failures harder to diagnose.
|
||||
|
||||
## 12. Budget and Timeline
|
||||
|
||||
### GPU rental
|
||||
|
||||
Prices from Runpod's public GPU Pods page as of the research date. Check availability, configurations, and associated charges before launching a job:
|
||||
|
||||
| GPU | VRAM | Listed hourly price | 24 hours |
|
||||
|---|---:|---:|---:|
|
||||
| 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 |
|
||||
|
||||
This is not a training-throughput comparison. A cheaper hour can lead to a more expensive completed experiment. Storage and other services are additional. [Runpod pricing](https://www.runpod.io/pricing)
|
||||
|
||||
An existing 2080 Ti is sufficient to start with a custom encoder. Renting a 24 GB GPU can make configuration sweeps more convenient. An A100 is justified if measurements show that memory or throughput has become the bottleneck.
|
||||
|
||||
### Estimating training duration
|
||||
|
||||
Before promising overnight training, run 200–500 steps and measure throughput at the chosen sequence lengths and batch size.
|
||||
|
||||
Illustrative pairwise-training workload:
|
||||
|
||||
```text
|
||||
10,000 tasks × 32 candidates × 256 tokens × 3 epochs
|
||||
= 245,760,000 processed tokens
|
||||
|
||||
time ≈ tokens / measured tokens per second
|
||||
```
|
||||
|
||||
The 256 tokens include the query, snippet, and formatting. Longer actual sequences or padding increase the workload.
|
||||
|
||||
| Hypothetical measured throughput | Training time alone | At $0.74/hour |
|
||||
|---:|---:|---:|
|
||||
| 2,000 tokens/s | 34.13 hours | $25.26 |
|
||||
| 10,000 tokens/s | 6.83 hours | $5.05 |
|
||||
| 30,000 tokens/s | 2.28 hours | $1.68 |
|
||||
|
||||
**This is a sensitivity analysis, not a GPU benchmark.** None of these rows is promised for a 2080 Ti or a particular model. Preparation, validation, idle time, and repeated experiments add to the cost.
|
||||
|
||||
### Current budget scope
|
||||
|
||||
Calls to the teacher and Astra are excluded from the current estimate. This defines the scope of the calculation; it does not imply those calls are free. Included items are:
|
||||
|
||||
- GPU rental for training and local inference;
|
||||
- cloud storage and, where needed, CPU environments for tests;
|
||||
- electricity when using a personal computer;
|
||||
- development, data preparation, and evaluation time, recorded separately from monetary expenses.
|
||||
|
||||
Evaluation volume is unchanged: for example, 100 tasks × 2 systems × 3 repetitions equals 600 runs. Their model-call charges are excluded, but duration and available parallelism still affect the calendar schedule.
|
||||
|
||||
### GPU spending scenarios
|
||||
|
||||
These scenarios allocate GPU hours; they do not predict required training time. They use the RTX 4090 rate of $0.74/hour from the table above.
|
||||
|
||||
| Scenario | Rental allocation | GPU cost |
|
||||
|---|---:|---:|
|
||||
| Prototype and initial training on an existing 2080 Ti | 0 rented hours | $0 rental; electricity is additional |
|
||||
| Short cloud experiment | 5–20 GPU-hours | $3.70–14.80 |
|
||||
| A series of training runs and comparisons | 20–100 GPU-hours | $14.80–74.00 |
|
||||
| Extended sweeps or search-policy experiments | 150–800 GPU-hours | $111–592 |
|
||||
|
||||
Cloud storage, additional CPUs, and idle time are extra. The required GPU hours will become clearer after a training pilot and selection of the experiment count. The final row is not an estimate for full RL training of a large generative model.
|
||||
|
||||
### Planning allowance and timeline
|
||||
|
||||
For the first cycle of minimal harness, data, encoder, and comparison, a reasonable allowance is **$50–200 for optional rental and infrastructure**, while retaining the option to run entirely on an existing GPU. This is a reserve, not a required expenditure or a guaranteed upper bound.
|
||||
|
||||
Excluding API expenses does not automatically shorten the schedule:
|
||||
|
||||
| Stage | Planning estimate for one developer |
|
||||
|---|---|
|
||||
| Test the idea without custom training | 1–2 weeks |
|
||||
| Encoder, data, and paired evaluation | Another 2–6 weeks |
|
||||
| Multi-step policy and broad evaluation | Another 1–3 months if this stage is pursued |
|
||||
|
||||
The main constraints are now annotation quality, task diversity, experiment time, and valid comparisons. Under this budget assumption, select the teacher for annotation quality without optimizing its price.
|
||||
|
||||
Rental services provide compute; datasets such as SWE-smith provide tasks and tools to create them. The central intellectual work is defining metrics, validating data, and analyzing failures.
|
||||
|
||||
## 13. Roadmap for the First Eight Weeks
|
||||
|
||||
### Weeks 1–2: establish whether there is a useful effect
|
||||
|
||||
- Start with Python because executable software-engineering data is available; add the user's other languages in a subsequent independent evaluation.
|
||||
- Select several projects, create controlled snapshots, and assemble 50–100 diagnostic tasks.
|
||||
- Build a minimal harness, graph adapter, text search, symbol reading, and resource-usage logging.
|
||||
- Compare conventional search, an untrained graph system, an existing reranker, and manually selected context.
|
||||
- Check updates after edits and measure actual latency on the available GPU.
|
||||
|
||||
**Decision:** if ideal or well-curated context does not improve useful metrics, refine the target scenario before scaling training.
|
||||
|
||||
### Weeks 3–4: prepare data and train the first model
|
||||
|
||||
- Prepare an initial 5K tasks, diverse candidates, and hard negatives.
|
||||
- Hold out separate projects for tuning and the final test.
|
||||
- Train a 149M encoder; compare it with an existing reranker and a simple head over vectors.
|
||||
- Check whether graph information adds value beyond text features.
|
||||
- Version all datasets, models, and harness configurations.
|
||||
|
||||
**Decision:** the trained model must offer value over existing components. If it does not, use the simpler option.
|
||||
|
||||
### Weeks 5–6: reduce latency and evaluate end-to-end value
|
||||
|
||||
- Try a 30–80M student, shorter representations, batching, and suitable quantization.
|
||||
- Run paired evaluations with Astra, including normal follow-up retrieval.
|
||||
- Measure cold starts, warm queries, and updates after code changes.
|
||||
- Check that reducing input does not undermine caching benefits.
|
||||
|
||||
**Decision:** accept or reject the model based on total cost and task success; the speed of one layer is insufficient.
|
||||
|
||||
### Weeks 7–8: learn action selection
|
||||
|
||||
- Record states where fixed retrieval wastes resources or misses context.
|
||||
- Train the choice between reading, expanding, stopping, and returning control.
|
||||
- Evaluate on new projects and with another main model.
|
||||
- Add a second language and live-editing scenarios.
|
||||
|
||||
Full RL, new MoE architectures, and broader evaluation suitable for publication may extend beyond these eight weeks. Part-time development will take longer.
|
||||
|
||||
## 14. Potential Differentiators
|
||||
|
||||
The most promising formulation for this project is:
|
||||
|
||||
> A local scout with small model weights that selects sufficient context from a live code graph and learns to allocate its retrieval budget inside a simple, open harness.
|
||||
|
||||
Four testable directions:
|
||||
|
||||
1. **Freshness.** Handle incomplete edits, renames, and branch switches; evaluate stale recommendations.
|
||||
2. **Joint utility.** Select small groups containing implementation, caller, contract, and test, rather than relying only on independently similar snippets.
|
||||
3. **Learned budgets.** Use one search for a simple question and several structural steps for a harder one; evaluate actual solution cost.
|
||||
4. **Accessible hardware and reproducibility.** Release weights, data, and the harness, with 2080 Ti measurements and comparisons against strong standard tools.
|
||||
|
||||
No individual item guarantees research novelty. Value may come from a convincingly evaluated combination, a high-quality dataset, and a useful working tool.
|
||||
|
||||
## 15. Final Recommendation
|
||||
|
||||
**Start with a minimal harness and graph retrieval, then train a small encoder.** This sequence will reveal whether the benefit comes from the index, neural model, action policy, or their combination.
|
||||
|
||||
Integration with Astra is technically feasible and has a plausible path to practical value. Direct evidence of the size of the benefit for Astra is still missing. An existing 2080 Ti is suitable for initial substantive experiments. With teacher and solver calls excluded, the main cash budget covers optional GPU rental and infrastructure; data quality and evaluation time are the primary constraints.
|
||||
|
||||
The first result to aim for is **a local assistant that needs no retraining for each repository and measurably reduces a strong agent's time or resource use on new tasks while maintaining task success**.
|
||||
@@ -1,580 +0,0 @@
|
||||
# Микромодель-скаут для кода: исследование и план эксперимента
|
||||
|
||||
**Дата: 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 и инфраструктура; главные ограничения — качество данных и время проверок.
|
||||
|
||||
Первый результат, к которому стоит стремиться: **непереобучаемый на каждый проект локальный помощник, который на новых задачах измеримо сокращает время или расходы сильного агента при сохранении успешности**.
|
||||
Reference in New Issue
Block a user