DiffContext

Показывай AI-ассистенту для кода только тот код, который важен для вносимого изменения.

DiffContext — это компилятор контекста для LLM-агентов, пишущих код. Передайте ему Python-репозиторий и изменение — git-диф, ветку или имя одной функции — и он вернёт небольшой набор функций, который модели действительно нужен, чтобы безопасно внести это изменение: вызывающий код, который сломается, подклассы, которые переопределяют функцию, тесты, которые её покрывают. Он подгоняет результат под ваш лимит токенов и сообщает модели, что пришлось отбросить.

Инструмент создан для тех, кто встраивает LLM в настоящие кодовые базы: циклы агентов, боты для ревью PR, CI-проверки — везде, где приходится решать, что отправлять в промпт, а репозиторий слишком велик, чтобы пересылать его целиком.

И он оценивает сам себя: укажите ему свой репозиторий — он проанализирует вашу git-историю, прогонит поиск на реальных парах со-изменений и напечатает NULL RESULT, когда инструмент не подходит; узнать, что он не подходит, и есть фича.

Проблема

Попросите ассистента изменить одну функцию в проекте из 50 000 строк — и у вас есть три плохих варианта: вставить весь репозиторий (он не помещается, а модели работают хуже в очень больших контекстах), вставить только эту функцию (модель сломает три вызывающих места, которые она не видела) или поискать имя через grep (grep не найдёт подкласс, который переопределяет функцию, или обработчик, который получает её через functools.partial — мы замерили, что полнота grep «выходит на плато», сколько бы бюджета вы ему ни дали).

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

git change ──► changed functions ──► hybrid retrieval ──► token budget ──► LLM-ready context
                                      graph ∪ BM25 ∪ file      top-k + tokens

Related MCP server: Serena

Установка

pip install diffcontext

Ноль зависимостей времени выполнения, Python 3.9+.

Для интеграции через MCP (Claude Code / Cursor / Windsurf):

pip install "diffcontext[mcp]"

Описание конфигурации сервера: docs/MCP.md.

Из исходного кода для разработки:

git clone https://github.com/trakshan-mishra/Diffcontext.git
cd Diffcontext && pip install -e .

Быстрый старт

diffcontext index /path/to/project              # cold: seconds; warm: ~0.02s
diffcontext compile --ref HEAD~1 --max-tokens 8000
diffcontext verify --from-history 20 --calibrate

Больше команд: USAGE.md. Рецепты для продакшена: docs/USE_CASES.md.

Не доверяйте нашим бенчмаркам — прогоните свои (2 минуты)

diffcontext verify --from-history 20 --calibrate извлекает тестовые примеры из git-истории вашего репозитория и оценивает качество поиска на них — и печатает NULL RESULT вместо декоративной цифры, когда инструмент не подходит вашему репозиторию. Узнать, что он не подходит, и есть фича.

Становится ли модель лучше?

Да — измерено сквозным образом, а не по косвенным метрикам. На 128 задачах ContextBench на Python, проверенных собственными тестовыми наборами каждого репозитория (без LLM-судьи), контекст примерно вчетверо увеличивает pass@1: 5.5% → 25.8%, точный тест Макнемара p < 0.0001.

Две оговорки, обе в benchmarks/contextbench/RESULTS.md, раздел §6: (a) стартовые функции, которые получает каждая ветвь, — оракул — они извлечены из эталонного патча, так что здесь измеряется «если локализация дана верно, влияет ли качество контекста?», а не решение задачи от начала до конца (локализация достаётся каждой ветви бесплатно); (b) 121 из 128 валидных задач — это django, так что это в основном результат про django.

Честное дополнение: три варианта контекста (default / gap / depboost) статистически неразличимы между собой, p = 0.36–0.81. Выигрыш даёт контекст против отсутствия контекста, а не один селектор против другого. Полные результаты: benchmarks/contextbench/RESULTS.md.

Чем это не является

• Не генератор кода. Он отбирает и упаковывает контекст; модель пишет код.

• Не precision-first. Он забрасывает широкую сеть — средняя точность ниже 0.1 при стандартном top-k. Если вы платите за каждый токен, используйте --cutoff gap.

• Еще не многолязычный. Python полностью поддерживается. TypeScript/JS (ESM) — рабочий прототип; CommonJS — измеренный провальный сценарий.

• Не замена чтению кода. У статического анализа есть слепые зоны — они перечислены ниже и в docs/BENCHMARKS.md.

Качество поиска (измерено, а не заявлено)

Эталонная истина извлекается из git-истории — разработчик изменил эти функции вместе в одном коммите; если показать ему одну, найдёт ли инструмент остальные? Измерено на 701 реальном коммите в 9 Python-репозиториях; при каждом пуше этот тест также прогоняется как CI-гейт, чтобы качество не могло незаметно деградировать.

Покомминные hit/recall по реальным парам со-изменений, гибридный поиск:

* валидационные репозитории, не использовались при настройке. Полная таблица по всем 9 репозиториям: benchmarks/README.md.

Сравнение один-на-один против grep при одинаковых лимитах токенов: grep выходит на плато на полноте 0.215 после 4k токенов, а DiffContext достигает 0.576 при 8k (в 2.7×). Честная оборотная сторона: средняя точность ниже 0.1 при стандартном top-k — большинство найденных символов это вспомогательный контекст, а не точный набор со-изменённых функций. --cutoff gap обрезает выборку в месте наибольшего падения оценки, даёт ~4× точность при затрате ~30% полноты (оверкой co-change; 2.2× / ~14% на ContextBench).

Я проверил свой собственный бенчмарк, и три моих утверждения не прошли

Продуть 2026-07 атаковала оценку, а не инструмент. Три опубликованные цифры не выжили:

• Калибровка — единственная цитируемая цифра (r=0.274, n≈25) была измерена на загрязнённом индексе. При повторном чистом замере на n=1,080 старая оценка даёт r=0.016 (p=0.60): связи нет вообще. Исправлено ужатием к «не знаю» → r=0.287 (p=0.0001) — сигнал, который ранжирует, а не вероятность.

• Веса смешивания — опубликованный [0.5, 0.35, 0.15] не прошёл leave-one-repo-out; каждое разбиение выбирало менее «графовый» вариант. Теперь [0.3, 0.5, 0.2].

• Плотный боратилон — TF-IDF-замена завышала плотный поиск (0.664, побеждала BM25 в 5 из 5). Настоящий энкодер MiniLM даёт 0.597 и побеждает BM25 только в 2 из 5. Два прежних вывода исправлены публично.

Подробный разбор: docs/auditing-my-own-benchmark.md · сырой отчёт: benchmarks/RIGOR_REPORT_2026-07.md.

Использование как библиотеки

from diffcontext.pipeline import index_repository, analyze_impact, compile

idx = index_repository("/path/to/repo")
impact = analyze_impact(idx, ["./src/auth.py:validate_jwt"])
ctx = compile(idx, impact, max_tokens=8000, top_k=20)
print(ctx.text)  # paste-ready, meta-header discloses what was dropped

Инкрементальный API (idx.update([...])), структурированный результат, подключаемый токенизатор: docs/ARCHITECTURE.md.

Поддержка языков

Известные ограничения (измерено, а не угадан)

У статического анализа есть потолок: тематические «соседи» без вызова между ними, кросс-подсистемные концептуальные связи (все методы дают 0/20) и динамическая диспетчеризация — это наши замеренные слепые зоны; полный список в docs/BENCHMARKS.md. Если сомневаетесь, проверьте: grep -rn "function_name(" --include="*.py" ., прежде чем полностью довериться ответу «вызывающие не найдены».

Далее

• docs/ARCHITECTURE.md — конвейер, карта модулей, API для агентов

• docs/BENCHMARKS.md — все цифры, метрика pass@1, ограничения

• docs/MCP.md — MCP-сервер для Claude Code / Cursor / Windsurf

• docs/ROADMAP.md — приоритетный план с обоснованием по результатам измерений

• diffcontext-service/ — FastAPI-сервис + веб-интерфейс

• observability/ — трассировка конвейера поиска

• CONTRIBUTING.md — окружение, CI-гейты, разработка адаптеров

Лицензия

MIT