1C MCP RAG Search

Поисковый слой для выгрузки 1С, доступный LLM-агенту через MCP: находит нужную бизнес-логику по BSL-коду и по метаданным конфигурации, даже если точное имя неизвестно. Всё работает локально без внешних API, данные не покидают машину.

Внутри — retrieval с двумя независимыми сигналами (semantic + lexical), измеренный на собственном gold-set. В ходе проверки найден дефект BM25-токенизатора: после его исправления hybrid снова значимо впереди на dev-наборе, а прежний «сдвиг лидера» отклонён (ADR 0010; ADR 0009 — rejected).

Задача

Выгрузка 1С — это тысячи .bsl-модулей и XML-метаданные конфигурации. Разработчику нужно быстро найти, где реализована конкретная логика, а LLM-агенту — надёжный инструмент поиска вместо grep.

Проект решает две задачи:

1. протокол — MCP-сервер со стандартными инструментами для любого MCP-клиента;

2. качество — воспроизводимый retrieval-пайплайн с метриками и обоснованными архитектурными решениями, а не «поиск, который просто работает».

Related MCP server: Onec Platform Help MCP Server

Как это работает

flowchart LR
    Q[query] --> E[e5-small<br/>«query: »]
    E --> C[Chroma cosine<br/>top-N]
    Q --> B[BM25 индекс<br/>179 586 чанков<br/>code_proc + metadata_xml]
    B --> BT[BM25<br/>top-N]
    C --> R{RRF<br/>k=60}
    BT --> R
    C -->|mode=vector| OUT[top-k]
    R -->|mode=hybrid·текущий дефолт| OUT
    R -->|mode=hybrid_rerank| RR[flashrank<br/>ms-marco-MultiBERT-L-12]
    RR --> OUT

Два независимых сигнала — семантический (cosine по e5-small) и лексический (глобальный BM25 по 179 586 чанкам двух коллекций: code_proc + metadata_xml) — объединяются через Reciprocal Rank Fusion по рангам. Текущий дефолт — hybrid; после исправления BM25-токенизатора он значимо лучше vector на dev-наборе (0.442 против 0.331, p = 0.0037) и не хуже на v3 (0.217 против 0.208, p = 0.635), поэтому дефолт подтверждён (ADR 0010; ADR 0009 — rejected). Cross-encoder подключается опционально как второй этап.

Подробнее — docs/ARCHITECTURE.md.

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

git clone https://github.com/Smaturus/1c-mcp-rag-search.git
cd 1c-mcp-rag-search
py -3.12 -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -e ".[dev]"

# пути к локальным источникам и индексам (подробнее — в разделе «Индексация»)
$env:MCP_1C_STUDY_ROOT="D:\Study"                 # дерево .bsl
$env:MCP_1C_METADATA_XML_ROOT="D:\Study_XML"     # XML-выгрузка конфигурации
$env:MCP_1C_CHROMA_DIR="data\chroma_xml"          # код + метаданные
$env:MCP_1C_BM25_DIR="data\bm25_all"              # глобальный BM25

# 1) код: нарезка по процедурам → коллекция code_proc
python scripts\build_procedure_index.py --no-lock

# 2) метаданные: XML-выгрузка → коллекция metadata_xml (та же база)
python scripts\parse_config_xml.py --root $env:MCP_1C_METADATA_XML_ROOT
python scripts\build_metadata_index.py --reset

# 3) глобальный BM25 по обеим коллекциям
python scripts\build_bm25.py --chroma-dir data\chroma_xml --out data\bm25_all

# 4) проверка качества
python scripts\eval_pipeline.py --golden data\eval\gold_set_v2.jsonl --out-dir data\eval\code_proc

Первый запуск скачивает модель intfloat/multilingual-e5-small в кэш HuggingFace.

MCP-инструменты

Итого 9 инструментов. Стек: MCP Python SDK 2.x (MCPServer) + Chroma

• intfloat/multilingual-e5-small + собственный BM25/инвертированный индекс

• flashrank (опция).

Маршрутизация запросов

Правила выбора инструмента — не текст промпта, а код с тестами: router.py + tests/test_router.py. При сомнении выбирается search_hybrid (безопасный дефолт).

Измерения (scripts/eval_router.py, отчёты data/eval/router_report.md и data/eval/part3_blind_report.md):

На новом корпусе политики маршрутизации проверены отдельно (один прогон): политика C (lexical→lexical, hybrid→vector) даёт nDCG@10 0.329 против 0.315 у fixed vector — лучше, но в пределах шума (±0,02). Поэтому маршруты не меняются до независимой выборки; смена лидера отклонена после фикса BM25 (ADR 0010), маршрутизация остаётся ADR 0006.

Вывод зафиксирован честно: маршрутизация не ухудшает качество, но и не даёт доказанного прироста. На gold-set v2 большая часть запросов — смысловые с точным именем и по контракту уходят в hybrid, поэтому routed-политика на прежнем корпусе совпала с fixed hybrid. Поэтому дефолт остаётся hybrid, а правила — ADR 0006. Регрессионные кейсы использовались при настройке правил, поэтому 100 % — проверка контракта, а не оценка обобщения. Единственная независимая проверка (blind Part-3, хэш зафиксирован) дала 75 % до правок — это ниже гейта; после правок нужен новый hold-out, чтобы заявлять ≥ 80 % обобщения (долг зафиксирован в ADR 0006).

Retrieval pipeline

Единая точка входа — search(query, top_k, mode) в src/mcp_1c_rag/search_modes.py.

Ключевые свойства:

• RRF по рангам, а не по сырым скорам: score(d) = Σ 1/(k_rrf + rank_i(d)), k_rrf = 60;

• глобальный BM25 по всем 179 586 чанкам двух коллекций (code_proc 154 560 + metadata_xml 25 026): собственный инвертированный индекс, ~57,6 МБ, локальный артефакт data/bm25_all, в git не входит;

• токенизация под 1С: кириллица, цифры, дефисные коды (НФ-001, НДС-18);

• префиксы e5 (query: / passage: ) сохраняются: запрос кодируется embed_query, документы — индексатором;

• reranker не заменяет e5-small, а переупорядочивает 20 кандидатов RRF;

• параметры (модель, top_k, k_rrf, max_length) — переменные окружения в config.py, без правки кода.

# собрать лексический индекс (один раз)
python scripts\build_bm25.py --chroma-dir data\chroma_xml --out data\bm25_all

# вызвать из кода
python -c "from mcp_1c_rag.search_modes import search; print(search('НДС с аванса', top_k=3, mode='hybrid'))"

Chunking по процедурам

Исходный чанкинг — символьные окна 1200/200. Проверка на полном индексе показала дефект (замер на прежнем корпусе): 32,1 % чанков длиннее лимита e5 в 512 токенов (у метаданных — 78 %), то есть хвост трети текста не участвует в эмбеддинге. См. Embedding model и data/eval/embedding_tokens.md.

Решение — нарезка .bsl по границам процедур/функций (chunking_procedures.py, ADR 0007):

Смоук на 800 реальных файлах (scripts/smoke_procedure_chunking.py):

Сборка идёт в отдельную коллекцию code_proc; в текущем корпусе она лежит вместе с metadata_xml в базе data/chroma_xml, исторические code/metadata не затрагиваются:

# смоук (300 файлов)
python scripts\build_procedure_index.py --files 300 --collection code_proc_smoke --reset

# полная сборка (возобновляемая, чекпоинт в data/procedure_index_progress.json)
$env:MCP_1C_CHROMA_DIR="data\chroma_xml"
python scripts\build_procedure_index.py --no-lock

# метаданные из XML — в ту же базу, отдельная коллекция
python scripts\parse_config_xml.py --root "<путь к XML-выгрузке>"
python scripts\build_metadata_index.py --reset

# глобальный BM25 по обеим коллекциям
python scripts\build_bm25.py --chroma-dir data\chroma_xml --out data\bm25_all

# сравнение нарезок на gold-set v2
python scripts\eval_chunking.py

Оценка качества

Основной набор — gold-set v2: 70 запросов в естественных формулировках (30 курируемых доменных вопросов + 40 по реальным объектам конфигурации; exact / semantic / trap). Релевантность — на уровне файла-источника, схлопывание повторных чанков перед расчётом метрик (ADR 0003–0005).

python scripts\make_goldset_v2.py
python scripts\eval_pipeline.py --golden data\eval\gold_set_v2.jsonl --out-dir data\eval\code_proc
# воспроизводимость: несколько прогонов + агрегатор mean ± std
python scripts\eval_stability.py --out-dir data\eval\code_proc
# парный тест vector vs hybrid по per-query значениям
python scripts\eval_paired.py

Замеры на текущем корпусе: mean ± std по 4 независимым прогонам (reranker — однократно из-за стоимости). Каждый прогон — новый процесс: HNSW пересобирается при старте, поэтому разброс показывает устойчивость метрики.

Латентность на текущем корпусе (CPU): vector ~35–100 мс, hybrid ~50–120 мс, hybrid_rerank ~2,4 с/запрос. Отчёт — data/eval/code_proc/report_pipeline.md и data/eval/code_proc/report_stability.md.

Парный тест: vector против hybrid

Разница между лидером и текущим дефолтом проверена парно по per-query значениям (4 прогона, n = 70 пар):

Метод — scripts/eval_paired.py: per-query значения сначала усредняются по прогонам, затем считаются Δ, bootstrap CI (10 000 ресемплингов, seed=42), paired t-test и bootstrap p-value; Wilcoxon — справочно (при большом числе нулевых Δ он занижает p и для вывода не используется). Отчёт — data/eval/code_proc/report_paired.md.

2×2 ablation: старые числа недействительны

Ablation 2×2 был снят до исправления токенизатора BM25. Его вывод «переворот лидера hybrid→vector объясняется нарезкой» отклонён вместе с ADR 0009: дефект токенизатора усиливался повторяющимися CamelCase-идентификаторами в процедурных чанках. После фикса (ADR 0010) hybrid снова впереди на процедурной нарезке (0.442 против 0.331 на v2), поэтому старые ячейки 0.339/0.301 нельзя использовать для объяснения смены лидера. Ячейка «текущая выгрузка × символьная нарезка» и metadata-замеры требуют повторного замера; файл data/eval/ablation_2x2.md сохранён как история.

Выводы:

1. Причина «смены лидера» — дефект токенизатора BM25, а не свойство нарезки: CamelCase-имена не совпадали с естественными запросами. После фикса lexical вырос с 0.116 до 0.426 (v2), hybrid — с 0.301 до 0.442; ADR 0009 отклонён.

2. hybrid значимо лучше vector на v2 (Δ −0.112, p = 0.0037); на v3 разница не значима (0.217 против 0.208, p = 0.635), но hybrid не хуже. Дефолт hybrid подтверждён и не меняется.

3. Pearson после фикса даёт 0.383 на v2 и 0.229 на v3 — competitive, но медленнее; оставлен baseline-режимом, не дефолтом.

4. Cross-encoder reranker (0.117) измерен старым индексом; после фикса не перезамерялся. Остаётся опцией (ADR 0002), не дефолтом.

5. Абсолютные значения выросли (nDCG@10 0.442 на v2, 0.217 на v3), но остаются скромными: e5-small не обучена на коде. Следующий кандидат — code-oriented embeddings, проверять только на dev и подтверждать на независимом наборе.

6. Методика eval прошла два внешних ревью: исправлен учёт повторных чанков (ADR 0004, цифры 0.378 → 0.199 на v1) и собран natural-набор (ADR 0005).

Независимый hold-out v3 (100 запросов)

Для честной проверки собран отдельный hold-out из 100 запросов (23 домена: 71 отвечается по BSL-коду, 5 — по XML-метаданным, 24 — вне корпуса: платформенные механизмы, регламентированная отчётность, РИБ, давальческое сырьё). Набор не использовался для настройки и не должен использоваться: v2 — для разработки, v3 — для финальной проверки.

Baseline на 71 code-запросе (3 прогона, k=10, mean ± std, после фикса BM25): lexical 0.218, vector 0.208 ± 0.020, pearson 0.229 ± 0.019, hybrid 0.217 ± 0.015. Δ(vector−hybrid) = −0.0097, CI [−0.0492; +0.0297], p = 0.635 — не значимо; hybrid не хуже vector. Роутер на всех 100 запросах: 58/100 (58 %), на 76 отвечаемых — 43/76; основная ошибка — lexical→hybrid (21 случай): правила требуют CamelCase/код, а естественные имена в кавычках уходят в безопасный hybrid. Это зафиксированный разрыв контракта, а не подгонка под hold-out. ADR 0009 отклонён; дефолт hybrid подтверждён (ADR 0010): на v2 он значимо лучше vector, на v3 — не хуже.

10 лексических «якорей» (короткие точные фразы) проверяются скриптом scripts/eval_anchors.py — сейчас 10/10 в top-3; это быстрый сигнал деградации точного поиска. Детали — отчёт data/eval/gold_set_v3_report.md, итог и решение — data/eval/v3_report.md, набор — data/eval/gold_set_v3_holdout.jsonl, якоря — data/eval/anchors_v3.jsonl.

Исторический корпус (прежняя нарезка)

Таблица ниже снята до исправления BM25-токенизатора (ADR 0010) и не сопоставима с текущими числами; сохранена как история. После фикса старые выводы о лидере недействительны.

На прежнем корпусе (символьные окна, 100 465 чанков кода) тот же gold-set v2 дал (mean ± std по 3 независимым прогонам; reranker — однократно):

Сравнение с первой версией набора (30 запросов, шаблонные формулировки):

Абсолютные значения на разных корпусах напрямую несопоставимы (разные выгрузка и нарезка); сопоставим только порядок режимов. На прежнем корпусе RRF-гибрид был лучшим по nDCG@10 (+19 % к cosine при сопоставимой латентности), а reranker ухудшал результат — отрицательные результаты сохранены в ADR 0002/0009.

Метаданные: объекты и реквизиты

Помимо кода сервер индексирует метаданные конфигурации — но не как сплошной текст отчёта, а из XML-выгрузки: один чанк — объект или одно поле (реквизит, таблица, измерение/ресурс, форма, команда, значение перечисления). Это устраняет обрезку чанков лимитом эмбеддера (в текстовом отчёте 78 % чанков были длиннее 512 токенов) и сохраняет структуру.

Замер на 300 кейсах со структурной истиной из самой выгрузки (типы attribute / enum / object / register; для обеих коллекций — одинаковый текстовый матч). Детали — ADR 0008 и data/eval/metadata_ab_report.md.

Качество новой коллекции по типам (top-3): attribute — vector 87,2 % / BM25 100 %; enum — 100 % / 100 %; object — 45,9 % / 96,5 %; register — 69,0 % / 95,2 %. Для структурированных метаданных лексический поиск сильнее, вектор помогает с перефразировками; гибрид BM25 + vector — следующий шаг. Выгрузка и производные артефакты (JSONL, словарь имён, индексы) остаются локальными и не коммитятся.

Воспроизводимость

Embedding model

Проверка лимита на реальном индексе. На текущем корпусе процедурной нарезки лимит выдержан: чанков длиннее 512 токенов — 0,3 %, токены p50/p99/max — 179 / 472 / 554 (гейты — в разделе «Chunking по процедурам» и data/eval/procedure_chunking_smoke.md). Исторический замер на символьном корпусе: 32,1 % чанков были длиннее лимита (у метаданных — 78 %), то есть хвост трети текста не участвовал в векторе — см. scripts/check_embedding_tokens.py и data/eval/embedding_tokens.md. Именно этот дефект стал аргументом за нарезку по процедурам (ADR 0007).

Требования и установка

• Windows / Linux / macOS, Python 3.11–3.12 (на 3.14 может не быть колёс для torch / chromadb).

• Локальные источники (пути задаются env):

  • выгрузка конфигурации — дерево с .bsl (MCP_1C_STUDY_ROOT);

  • XML-выгрузка конфигурации — каталог Documents/, Catalogs/, … (MCP_1C_METADATA_XML_ROOT);

  • исторический источник метаданных — текстовый отчёт .txt (MCP_1C_STUDY_REPORT_ROOT, только для старой коллекции metadata).

• 2+ ГБ на модель и индекс; для полной индексации — 6–8 ГБ RAM.

cd <корень-репозитория>
py -3.12 -m venv .venv
.\.venv\Scripts\Activate.ps1
python -m pip install -U pip
pip install -e ".[dev]"

Индексация

$env:MCP_1C_STUDY_ROOT="D:\Study"                 # дерево .bsl
$env:MCP_1C_METADATA_XML_ROOT="D:\Study_XML"     # XML-выгрузка конфигурации
$env:MCP_1C_CHROMA_DIR="data\chroma_xml"          # текущий корпус: code_proc + metadata_xml
$env:MCP_1C_BM25_DIR="data\bm25_all"              # глобальный BM25

python scripts\build_procedure_index.py           # code_proc, возобновляемо
python scripts\parse_config_xml.py --root $env:MCP_1C_METADATA_XML_ROOT
python scripts\build_metadata_index.py --reset    # metadata_xml
python scripts\build_bm25.py --chroma-dir data\chroma_xml --out data\bm25_all

Legacy-индексатор (символьные окна code + текстовый отчёт metadata, база data/chroma) остаётся для ablation-ячейки и истории:

$env:MCP_1C_STUDY_ROOT="D:\Study"
$env:MCP_1C_STUDY_REPORT_ROOT="D:\Study_Report"
python -m mcp_1c_rag.indexer --reset
python scripts\build_bm25.py --chroma-dir data\chroma --out data\bm25

Smoke-режим (ограничить объём):

python -m mcp_1c_rag.indexer --target code --reset --limit 30 --max-chunks 200
python -m mcp_1c_rag.indexer --target metadata --reset --max-chunks 200

Индексы: data/chroma_xml/ (в .gitignore), BM25 — data/bm25_all/. Другие переменные: MCP_1C_CHROMA_DIR, MCP_1C_BM25_DIR, MCP_1C_EMBED_BATCH_SIZE.

Подключение к клиенту

В mcp.json (Cursor) или mcp.servers (ZCode) добавить сервер:

"1c-mcp-rag-search": {
  "command": "D:\\path\\to\\repo\\.venv\\Scripts\\python.exe",
  "args": ["-m", "mcp_1c_rag"]
}

Перезапустить клиент — появятся все 9 tools: search, search_1c_metadata, search_knowledge_base, search_hybrid, route_query, index_stats, codesearch, metadatasearch, evaluate_retrieval.

Проверка без клиента:

python -c "from mcp_1c_rag.search import codesearch, metadatasearch; print(codesearch('Провести', 3)); print(metadatasearch('Справочник', 3))"

Архитектурные решения

Полный список — в docs/adr/.

Инженерные принципы: одно изменение → замер

Проект ведётся по циклу PDCA/kaizen: гипотеза → минимальное изменение → измерение → стандартизация результата. Это не декларация, а способ, которым принимались все решения в репозитории.

Два принципа, без которых цикл ломается:

1. Сначала стабилизируй измерение. До эксперимента проверяется сама метрика: найдены и исправлены дубликаты в nDCG (ADR 0004), синтетический набор заменён natural-набором (ADR 0005). Оптимизировать шум дороже, чем не оптимизировать.

2. Стандартизируй достигнутое. Улучшение закрепляется кодом и тестами: регрессия на дедупликацию метрик, ADR на каждое решение. Следующая итерация начинается от этой стандартной работы, а не с нуля.

Плюс два «предохранителя»: CI (ruff + mypy + гейт сложности + pytest) не даёт незаметно сломать проект, а публикация отрицательного результата (reranker, ошибка метрики, незначимая Δ лидера) работает как «андон» — остановиться и разобраться, вместо того чтобы тянуть дальше.

Разработка и качество

pip install -e ".[dev]"

pytest -q        # 74 unit-теста (ML-стек не требуется: импорты ленивые)
ruff check .     # линтер
mypy             # проверка типов (22 модуля)
python scripts\check_complexity.py   # гейт сложности (radon)
pytest -q --cov=src/mcp_1c_rag       # покрытие

CI (.github/workflows/ci.yml): ruff + mypy + гейт цикломатической сложности + pytest с покрытием на Python 3.11 и 3.12 — на GitHub последний прогон зелёный. Тяжёлые зависимости (Chroma, sentence-transformers, flashrank) импортируются лениво, поэтому CI быстрый и не тянет ML-стек.

Quality gates и текущие значения

Гейт сложности — ratcheting: известные функции зафиксированы в baseline, любой новый блок сложнее 20 или рост существующего ломает сборку. Baseline можно только сокращать: после рефакторинга запись удаляется вместе с кодом.

Структура репозитория

pyproject.toml, README.md, CHANGELOG.md, LICENSE
src/mcp_1c_rag/      22 модуля
  server.py         MCP-сервер и 9 tools (включая index_stats)
  search_modes.py   vector / hybrid (RRF) / hybrid_rerank / pearson / lexical
  bm25.py           токенизация + BM25Okapi + глобальный Bm25Index
  rrf.py            Reciprocal Rank Fusion
  rerank.py         flashrank cross-encoder (опция)
  router.py         маршрутизация lexical / vector / hybrid (ADR 0006)
  chunking_procedures.py  нарезка BSL по процедурам (ADR 0007)
  chunking.py, indexer.py  символьная нарезка и legacy-индексатор (ablation, история)
  embeddings.py, store.py, hybrid.py, metrics.py, eval_metrics.py, models.py,
  index_guard.py    single-writer lock
scripts/
  build_procedure_index.py  сборка коллекции code_proc (возобновляемая)
  parse_config_xml.py       XML-выгрузка → структурные чанки метаданных
  build_metadata_index.py   сборка коллекции metadata_xml
  build_bm25.py             глобальный BM25 по обеим коллекциям (179 586 чанков)
  smoke_procedure_chunking.py  смоук нарезки: покрытие и токены
  eval_chunking.py          сравнение code vs code_proc на gold-set v2
  eval_pipeline.py          сравнение конфигураций
  eval_stability.py         mean ± std по нескольким прогонам
  eval_paired.py            парный тест vector vs hybrid (bootstrap CI + t-test)
  validate_goldset_v3.py    валидация hold-out v3 и лексических якорей
  eval_anchors.py           регрессия точного поиска на 10 якорях
  eval_router_v3.py         точность роутера на hold-out v3
  eval_metadata_xml.py      A/B XML-метаданных против текстового отчёта
  eval_router.py            точность роутера
  check_embedding_tokens.py проверка лимита 512 токенов
  check_complexity.py       гейт цикломатической сложности (CI)
  make_goldset_v2.py        natural-набор: 70 запросов
  make_goldset.py           генерация gold-set v1 (исторический)
  bench.py                  латентность p50/p95
tests/              unit-тесты: 72 (bm25, rrf, rerank, metrics, router, chunking)
docs/               ARCHITECTURE.md, ADR 0001–0009
docs/presentation/   RU-презентация (12 слайдов)
docs/presentation/en/  EN-слайды (pptx/pdf), SPEECH_EN.md, ONE_PAGER_EN.pdf
data/eval/          gold-set v2 и отчёты (в git только gold-set и отчёты)
  code_proc/        новый корпус: report_pipeline.md, report_stability.md, report_paired.md
  symbolic_ablation/  ablation-ячейка «текущая выгрузка × символьные окна»
  gold_set_v3_holdout.jsonl  независимый hold-out v3: 100 запросов
  anchors_v3.jsonl           10 лексических якорей (регрессия точного поиска)
  gold_set_v3_report.md      состав hold-out v3, baseline и ограничения
  v3_report.md               итог v3: 3 прогона, paired, роутер, решение ADR 0009
  v3_router.md, v3_anchors.md  отчёты роутера и якорей
  v3_code/, v3_metadata/     агрегаты и paired-отчёты по scope
  ablation_2x2.md   2×2 ablation: выгрузка × нарезка
  v2/, report_pipeline.md, router_report.md, part3_blind_report*.md, bench.md
data/               локальные артефакты: chroma_xml/, bm25_all/, metadata_xml/, lexicon/

Ограничения

• HNSW не персистится при hnsw:sync_threshold=1000000 (защита от chroma#7090): старт процесса пересобирает индекс из sqlite (~60–70 с на текущем корпусе, 179 586 чанков).

• Один писатель на индекс: параллельная индексация не поддерживается.

• Инкрементального обновления нет: после изменения выгрузки индекс пересобирается целиком (--reset); прерванную сборку можно возобновить (--resume), но изменившиеся файлы не досчитываются выборочно.

• Gold-set частично синтетический — абсолютные метрики скромные, сравнение конфигураций корректно.

• Выгрузки 1С и векторные индексы в репозиторий не попадают: каждый строит индекс у себя.

• Старая выгрузка недоступна: для 2×2 «выгрузка × нарезка» сохранились только производные метрики прежнего корпуса; после ADR 0010 старые клетки недействительны, нужен перезамер исправленным токенизатором (см. data/eval/ablation_2x2.md).

• «Смена лидера» (vector против hybrid) отклонена: это был дефект BM25- токенизатора. Дефолт hybrid подтверждён на v2 (p = 0.0037) и не хуже на v3 (p = 0.635); см. ADR 0010.

Roadmap

• MCP stdio tools + локальный индекс (e5 + Chroma)

• Глобальный BM25 и RRF-гибрид

• Cross-encoder reranker как опция + замеры

• Eval-контур: file-level метрики, mean ± std, ADR

• Явная маршрутизация запросов lexical / vector / hybrid (ADR 0006)

• Gold-set 60–100 естественных запросов (70 запросов, ADR 0005)

• Chunking по процедурам/функциям + путь файла в тексте чанка (ADR 0007)

• Метаданные из XML-выгрузки (ADR 0008) и двухуровневый корпус

• Парный тест vector vs hybrid и 2×2 ablation (ADR 0009; interaction-ячейка не измерима — старая выгрузка утрачена)

• Независимый hold-out v3 собран (100 запросов) и baseline снят (data/eval/gold_set_v3_report.md); набор не использовался для настройки

• Подтвердить смену лидера на v3 / независимом hold-out (ADR 0009 → accepted)

• Код-ориентированная embedding-модель и новый baseline

• Опциональный режим RRF с весами источников и его сравнение

• English README (README.en.md)

Документация

Лицензия

MIT — см. LICENSE.

Контакты

Sergey Matyukhin — Technology Executive | Enterprise AI & RAG Architecture

Профиль: технологическое руководство и практическая реализация AI/RAG-решений для enterprise — от выбора архитектуры и экономики решения до эксплуатационных ограничений и передачи команде. Этот репозиторий — референсная реализация: прототип доведён до состояния, в котором у каждого решения есть измерение, ADR и публично зафиксированные ограничения.

• GitHub: @Smaturus

• Email: smaturus@gmail.com

В репозитории нет выгрузок 1С, личных данных и готовых индексов — только код, тесты и документация.