Перейти к содержимому
Отчёты
MCP-сервер topcontrol — глубокое тестирование (8 сценариев)

MCP-сервер topcontrol — глубокое тестирование (8 сценариев)

Запись интерактивной сессии Claude Code (TUI) с MCP-сервером topcontrol на tc-mcp.gpu.local-xyz.ru. Проверены все 3 tools (search_docs, get_article, list_articles), 2 resources (tc://taxonomy, tc://article/{slug}), 1 prompt (/mcp__topcontrol__analyze_topic), а также MCP Elicitation — серверный запрос дополнительных данных у клиента в middle-of-call.

Дата: 2026-05-20 · Окружение: Claude Code v2.1.145, Opus 4.7, Claude Max · Backend: Qdrant 1.18.0 + Qwen3-Embedding-8B + BM25 ru-stemmer + RRF fusion.

Вопрос 1. BRT-метод (Willemain) — что это и какие tools используются

Через MCP topcontrol найди статью про BRT-метод (Willemain) и кратко объясни в чём суть. Покажи использованные tools.

Использованные инструменты

  1. ToolSearch — загрузил схемы deferred-инструментов: mcp__topcontrol__search_docs, mcp__topcontrol__get_article, mcp__topcontrol__list_articles.
  2. mcp__topcontrol__search_docs — гибридный поиск по запросу «BRT метод Willemain прогнозирование спроса». Топ-результат — brt-metod-pri-zakaze-postavshhiku (score 0.83).
  3. mcp__topcontrol__get_article — полный текст статьи по этому slug.

Источник

BRT-метод (Метод Willemain) ПРИ ЗАКАЗЕ ПОСТАВЩИКУ — Алексей Север, курс «Управление закупками» (infostena).

Суть BRT-метода

Задача. Рассчитать объём заказа поставщику для товаров с редкими и нестабильными продажами (запчасти, диваны, стройматериалы, генераторы и т. п.), где обычная среднедневная продажа даёт абсурдный результат — занижает заказ в разы, потому что мало дней с продажами делится на большое окно.

Происхождение. Метод предложил в 1994 году американский математик Томас Виллемейн (Willemain) под названием bootstrap («pull oneself over a fence by one’s bootstraps»). В ТопКонтроль используется адаптированная версия под названием BRT.

Алгоритм (на примере: окно поставки 10 дней, история — 31 день октября):

  1. Скользящее окно. По истории продаж пройти окном длиной = «срок поставки + срок продаж» со сдвигом 1 день. Получить все возможные суммы продаж за 10-дневный интервал (1–10 окт = 13 шт; 2–11 окт = 13 шт; 3–12 окт = 14 шт; … — итого 22 интервала).
  2. Эмпирическое распределение. Отсортировать суммы по возрастанию и посчитать частоту каждой суммы. Поделить на общее число интервалов → получить вероятность каждого исхода (13 шт встретилось 3 раза из 22 → 14%, и т. д.).
  3. Накопительная вероятность = уровень сервиса. Считаем нарастающим итогом. Получаем таблицу «объём заказа ↔ % покрытия потенциального спроса».
  4. Выбор объёма. Закупщик задаёт целевой уровень сервиса (например, 85%) и из таблицы читает соответствующее количество. Среднедневная в примере давала 15 шт = 45% сервиса, а для 85% сервиса нужно везти 21 шт; 100% — 24 шт.

Идея в одном предложении. Вместо «средней температуры по больнице» использовать саму эмпирическую функцию распределения сумм за интересующий горизонт — и явно выбирать точку на ней через уровень сервиса.

Управленческий смысл уровня сервиса:

  • Матричные/высокоприбыльные товары → 95% (страшнее дефицит, чем неликвид).
  • Рабочие → 85%.
  • Товары-лузеры → 65–70% (страшнее неликвид).

Главный «косяк». Считать BRT по всему ассортименту вручную в Excel или 1С нереально — нужна автоматизация (в ТопКонтроль это столбец «Уровень сервиса» + параметр «Интервал BRT» в настройках отчёта Заказа поставщику; для смешанных заказов есть «Автовыбор метода», который сам разделяет стабильный/нестабильный спрос).

Вопрос 2. List_articles с фильтром по курсу

Через MCP topcontrol покажи 5 статей курса assortiment с их title и slug.

Использован инструмент mcp__topcontrol__list_articles с фильтром course=assortiment, limit=5.

5 статей курса assortiment

#: 1 Title: Ассортиментная стратегия — выбор и применение Slug: assortimentnaya-strategiya ──────────────────────────────────────── #: 2 Title: Показатели АВС-анализа, какие нужны и зачем Slug: pokazateli-abc-analiza-kakie-nuzhny-i-zachem ──────────────────────────────────────── #: 3 Title: Статусы актуальности товаров Slug: statusy-aktualnosti-tovarov ──────────────────────────────────────── #: 4 Title: Робот в помощь! Идеальное управление ассортиментом, запасами, закупками Slug: robot-v-pomoshh-idealnie-assortimentom-zapasi-zakupki ──────────────────────────────────────── #: 5 Title: Введение в товарный анализ Slug: vvedenie-v-tovarnyj-analiz

Все из источника infostena (методология Алексея Севера).

Вопрос 3. Чтение MCP-ресурса tc://taxonomy

Прочитай ресурс tc://taxonomy на topcontrol и выведи компактно — какие источники и курсы доступны. “contents”: [ { … +8 lines (ctrl+o to expand)

Использован ReadMcpResourceTool (server=topcontrol, uri=tc://taxonomy).

Источники и курсы

┌────────────┬────────────────────────────────────────────────────────────┐
│  Источник  │                           Курсы                            │
├────────────┼────────────────────────────────────────────────────────────┤
│ bscontrol  │ — (без курсов)                                             │
├────────────┼────────────────────────────────────────────────────────────┤
│ infostena  │ assortiment, prodazhi, raznoe, upravlenie, zakupki, zapasy │
├────────────┼────────────────────────────────────────────────────────────┤
│ topcontrol │ — (без курсов)                                             │
└────────────┴────────────────────────────────────────────────────────────┘

Курсы существуют только в infostena (методология Алексея Севера); bscontrol и topcontrol — плоские каталоги без разбиения.

Вопрос 4. Adversarial / out-of-domain — «квантовая хромодинамика»

Через MCP topcontrol search_docs запрос “квантовая хромодинамика мезоны” limit=3. Покажи scores и сделай вывод о релевантности.

Использован mcp__topcontrol__search_docs с запросом «квантовая хромодинамика мезоны», limit=3. (Задача одношаговая — TaskCreate здесь излишен.)

Результаты и scores

┌─────┬──────────────────────────────────────────┬─────────────────┬───────┐
│  #  │                   Slug                   │ Source / Course │ Score │
├─────┼──────────────────────────────────────────┼─────────────────┼───────┤
│ 1   │ my-v-telege-s-nas-insajty-s-vas-podpiska │ infostena /     │ 0.500 │
│     │                                          │ raznoe          │       │
├─────┼──────────────────────────────────────────┼─────────────────┼───────┤
│ 2   │ otrasli                                  │ topcontrol / —  │ 0.333 │
├─────┼──────────────────────────────────────────┼─────────────────┼───────┤
│ 3   │ biznes-processy                          │ topcontrol / —  │ 0.250 │
└─────┴──────────────────────────────────────────┴─────────────────┴───────┘

Вывод о релевантности

Результаты нерелевантны. KB ТопКонтроль покрывает розницу/закупки/запасы — физики там нет, поэтому ни одна статья на запрос про QCD и мезоны не отвечает.

Что показывают сами scores:

  • Все три хита — chunks с одной картинкой и пустым текстом (баннер, group-15.png, group-1577.png). Совпадение идёт по «шуму» embedding’а, а не по содержанию.
  • Топовый score 0.5 — это RRF-fusion ранг, а не косинусная близость. Для сравнения, релевантный запрос про BRT в прошлом вопросе давал 0.83 на in-topic статье. Здесь же даже лучший результат — на полпорядка хуже и сидит в курсе raznoe («разное»).
  • Падение 0.50 → 0.33 → 0.25 — характерная форма «1/k» от RRF при отсутствии настоящего сигнала: фьюжн просто отдаёт верхушку рангов, ни один из источников не голосует уверенно.

Практический вывод: при out-of-domain запросе search_docs всё равно вернёт limit результатов — пустого ответа не бывает. Чтобы отсекать такие случаи, нужен порог по score (эмпирически: <~0.5 на этой KB = почти наверняка off-topic) либо проверка, что top-hit это содержательный chunk, а не баннерная картинка.

Вопрос 5. Multi-step prompt /mcp__topcontrol__analyze_topic

/mcp__topcontrol__analyze_topic нормализация аномальных продаж

Запускаю исследование темы согласно шагам команды.

Топ-1 (normalizaciya-anomalnyx-prodazh-pri-zakaze-postavshhiku, score 1.0) — точное попадание. #2 и #3 — обзорные с упоминанием нормализации. #4 (uchet-nulevyx-ostatkov…, 0.325) релевантен как «вторая сторона» темы (отрицательные выбросы из-за OOS). #5 (страховой запас) почти не релевантен — отсекаю. Тяну полные тексты top-3 + смежный OOS + листинг курса параллельно.

Использованные инструменты

┌─────┬──────────────────────┬─────────────────────────────────────────────┐
│ Шаг │      Инструмент      │                  Параметры                  │
├─────┼──────────────────────┼─────────────────────────────────────────────┤
│ 1   │ mcp__topcontrol__sea │ query="нормализация аномальных продаж       │
│     │ rch_docs             │ выбросы", limit=5                           │
├─────┼──────────────────────┼─────────────────────────────────────────────┤
│ 2a  │ mcp__topcontrol__get │ slug=normalizaciya-anomalnyx-prodazh-pri-za │
│     │ _article             │ kaze-postavshhiku (top-1, score 1.0)        │
├─────┼──────────────────────┼─────────────────────────────────────────────┤
│ 2b  │ mcp__topcontrol__get │ slug=zakaz-postavshhiku-step-by-step-upravl │
│     │ _article             │ enie-zakupkami (top-3)                      │
├─────┼──────────────────────┼─────────────────────────────────────────────┤
│     │ mcp__topcontrol__get │ slug=uchet-nulevyx-ostatkov-out-of-stock-pr │
│ 2c  │ _article             │ i-zakaze-postavshhiku (top-4 — обязательная │
│     │                      │  парная статья)                             │
├─────┼──────────────────────┼─────────────────────────────────────────────┤
│ 3   │ mcp__topcontrol__lis │ course=zakupki, limit=30 (смежный курс)     │
│     │ t_articles           │                                             │
└─────┴──────────────────────┴─────────────────────────────────────────────┘

Шаг 5 (открыть BRT) пропустил — статья brt-metod-pri-zakaze-postavshhiku уже была прочитана ранее в этом диалоге, повторно тянуть не нужно. Top-2 (zakupka-tovara-pri-v2v-…) — обзорная, ничего нового по теме, тоже отсёк. Top-5 (страховой запас, score 0.09) — упоминается мимоходом, не релевантен.

Что такое «нормализация» в управлении закупками

Определение из [uchet-nulevyx-ostatkov-…]:

▎ Выброс данных в динамике продаж — это значимое отклонение ежедневной продажи ▎ от среднедневной за выбранный период, не связанное с сезонными колебаниями ▎ спроса и любыми другими явно прогнозируемыми событиями прошлого.

Нормализация — это очистка ряда продаж перед тем, как считать заказ поставщику. Цель — сделать прошлый ряд максимально похожим на ожидаемое будущее: убрать то, что не повторится, и достроить то, чего не хватает (продажи, которых не было из-за отсутствия товара).

Алексей Север делит выбросы на два направления — и они нормализуются по-разному:

Выбросы вниз (источник: [uchet-nulevyx-ostatkov-out-of-stock-pri-zakaze-postavshhiku])

┌──────────────────────────────────────────┬──────────────────────────────┐
│                   Тип                    │          Что делать          │
├──────────────────────────────────────────┼──────────────────────────────┤
│ Отрицательные (возвраты > продаж за      │ НЕ нормализовать — могут     │
│ день)                                    │ повториться                  │
├──────────────────────────────────────────┼──────────────────────────────┤
│ Неадекватно низкие                       │ НЕ нормализовать — спрос     │
│                                          │ реально мог быть таким       │
├──────────────────────────────────────────┼──────────────────────────────┤
│ Нулевые «нет покупателя — нет продаж»    │ НЕ нормализовать             │
├──────────────────────────────────────────┼──────────────────────────────┤
│ Нулевые «нет остатка — нет продаж» (OOS) │ Обязательно нормализовать —  │
│                                          │ это упущенная выручка        │
├──────────────────────────────────────────┼──────────────────────────────┤
│ Крупный незапланированный возврат,       │ Исключить вручную через      │
│ попавший в окно расчёта без сопряжённой  │ фильтр документа/клиента     │
│ продажи                                  │                              │
└──────────────────────────────────────────┴──────────────────────────────┘

Алгоритм нормализации OOS (формула из статьи):

  1. дни_OOS = общий_период − дни_наличия
  2. виртуальные_продажи = дни_OOS × среднедневная_по_календарю
  3. нормализованная_средняя = (факт_продажи + виртуальные) / общий_период
  4. заказ = нормализованная_средняя × горизонт

Пример: 2 000 факт. продаж за 90 дней, товар лежал 4 дня. Без нормализации: 22 шт/день. По «дням наличия»: 500 шт/день → 15 000 шт заказа = неликвид. С нормализацией OOS на 100% от средней: 43 шт/день → 1 304 шт заказа.

ТопКонтроль добавляет тюнинг «% от среднего» (default 100%) — если кажется, что средняя занижена, ставим 150–250%. Для очень разношёрстного ассортимента есть альтернативный механизм — «норматив надёжности» (надёжных дней на складе / дней продаж), но это закрытый алгоритм.

Выбросы вверх (источник: [normalizaciya-anomalnyx-prodazh-pri-zakaze-postavshhiku])

Три причины:

  • Клиентский — единичный клиент выгреб запас (например, через фильтр документа реализации убираем «ООО Сытый депутат»).
  • Акционный — разовые промо.
  • Внешний фактор — погода, паника, новостной всплеск.

Объединяет всё одно: уникальность и маловероятность повторения.

Три способа поиска и нейтрализации:

  1. Глазометрический — лучший по точности, не масштабируется на 100+ SKU.
  2. Ручное исключение — фильтр «Номер документа» или «Клиент» в Отчёте закупщика. Хорошо, если факт известен.
  3. Автоматический — метод Тьюки (Tukey, 1940-е) с авторской доработкой:

Q1 = 25-й перцентиль ряда продаж Q3 = 75-й перцентиль IQR = Q3 − Q1 ← межквартильный диапазон граница = Q3 + k × IQR ← k — «коэффициент жёсткости»

  • Классический k = 1.5; в ТопКонтроль default k = 3 (мягче, режет только сильные пики).
  • Чем выше k, тем выше граница и меньше точек попадает в выбросы.
  • Ключевая особенность реализации: выброс не обнуляется, а приравнивается к ближайшему значению ряда ниже границы. В примере: 400 шт и 204 шт заменены на 100 шт.

Граница включается галочкой «Нормализация продаж методом Тьюке» и видна на графике зелёной линией.

В каких отраслях применимо

  • Розница и опт — основной кейс из статей (стройматериалы, FMCG, аптеки, B2B).
  • Снабжение производства — нормализуется не «продажа», а «расход» сырья/материалов (прямо упомянуто в uchet-nulevyx-ostatkov-…).
  • Особенно критично для редко- и нестабильно продающихся товаров — нормализация работает в связке с BRT-методом ([brt-metod-pri-zakaze-postavshhiku]): сначала очищаем ряд, потом строим эмпирическое распределение под уровень сервиса.

Не применимо:

  • На сводных продажах (группы, категории, бренды) — нормализованный агрегат нельзя пересчитать в заказ конкретной SKU. Исключение — товары-аналоги под одним сводным наименованием.
  • На многомерных временных рядах — для них Север отсылает к книге Дж. Формана «Много данных» и ГОСТ 16269-4-2017.

Соседние статьи курса zakupki, замыкающие тему

Из листинга — нормализация это часть 11–12 курса; до и после неё в цепочке:

  • [zakaz-postavshhiku-step-by-step-upravlenie-zakupkami] (ч. 3) — общая пошаговая схема; нормализация — отдельный шаг между «выбором метода» и «расчётом объёма».
  • [brt-metod-pri-zakaze-postavshhiku] — метод для нестабильных продаж; в zakupka-tovara-pri-v2v-… явно сказано, что BRT + нормализация = «the best of the best».
  • [avtovybor-metoda-rascheta-v-zakaze-postavshhiku-upravlenie-zakupkami] — автовыбор между среднедневной и BRT; нормализация применяется до выбора метода.
  • [straxovoj-zapas-pri-zakaze-postavshhiku-vid-primenenie-rashet] (ч. 8) — нормализация чистит прошлое, страховой запас компенсирует неопределённость будущего: «Очищенные продажи Прошлого ≠ продажам Будущего».
  • [sezonnost-prodazh-v-zakupkax-uchet-i-raschet] (ч. 7) — сезонные колебания не считаются выбросом (исключение прямо в определении), для них отдельный механизм.

Сухой остаток

Нормализация — это двусторонняя чистка ряда продаж: достроить то, что недопроизошло из-за пустого склада (вверх), и срезать единичные пики, которые не повторятся (вниз). Down — формула «виртуальные продажи» с настройкой % от среднего; Up — метод Тьюки с коэффициентом жёсткости, заменяющий пик ближайшим неэкстремальным значением. Без неё расчёт от среднедневной либо занижает заказ (упущенные продажи в OOS), либо завышает (разовый пик размазывается на средний период), и оба сценария ведут либо к дефициту, либо к неликвиду.

✻ Sautéed for 2m 5s

Вопрос 6. Русский стеммер — три падежа одного запроса

Проверь стеммер: сделай 3 search_docs запроса с одной темой в разных падежах — “страховой запас”, “страхового запаса”, “о страховом запасе”. Покажи top-1 + score каждого. Совпали ли результаты?

Тест одношаговый — три параллельных вызова search_docs, TaskCreate здесь не нужен.

Результаты

#: 1 Запрос: страховой запас (Им. п.) Top-1 slug: straxovoj-zapas-pri-zakaze-postavshhiku-vid-primenenie-rashet chunk_index: 5 Score: 1.0 ──────────────────────────────────────── #: 2 Запрос: страхового запаса (Род. п.) Top-1 slug: straxovoj-zapas-pri-zakaze-postavshhiku-vid-primenenie-rashet chunk_index: 5 Score: 1.0 ──────────────────────────────────────── #: 3 Запрос: о страховом запасе (Предл. п.) Top-1 slug: straxovoj-zapas-pri-zakaze-postavshhiku-vid-primenenie-rashet chunk_index: 5 Score: 1.0

Вывод

Результаты совпали полностью — тот же slug, тот же chunk, тот же score 1.0 во всех трёх падежах.

Что это говорит:

  • Русский стеммер на BM25-плече работает корректно. страховой / страхового / страховом все сводятся к одной основе, запас / запаса / запасе — тоже. Иначе падежная форма «о страховом запасе» (где две формы из трёх вообще не дословно совпадают с заголовком статьи) дала бы заметно более низкий score.
  • Dense embedding (Qwen3-Embedding-8B) тоже инвариантен к падежу — что ожидаемо для современного многоязычного эмбеддера. Падежи в русском не меняют семантику term’а, и эмбеддер это знает.
  • RRF-fusion стабильно ставит ту же статью на top-1, что подтверждает: обе ветви (sparse + dense) голосуют одинаково.
  • Незначимый момент: score 1.0 — это нормализованный RRF, а не косинусная близость. На запросах с очень узкой релевантностью (одна статья в KB прицельно по теме) RRF почти всегда даёт 1.0 top-1, потому что один и тот же документ оказывается первым и в BM25-, и в dense-ранжировании. Для оценки качества важнее, что chunk совпал тоже — это уже признак того, что внутренние ранжирования действительно сошлись.

Падежная нормализация на этой KB работает — можно не «выпрямлять» запросы вручную перед поиском.

Вопрос 7. Кросс-источниковый синтез: ABC-анализ в infostena vs bscontrol

Сравни как ABC-анализ описан в источниках infostena и bscontrol. Найди по одной статье из каждого, прочитай и выпиши: (1) общие моменты, (2) что говорит infostena чего нет в bscontrol, (3) что говорит bscontrol чего нет в infostena.

Лучшие кандидаты: в infostena — pokazateli-abc-analiza-kakie-nuzhny-i-zachem (score 0.83), в bscontrol — spr-r4-8-1-abc-metody-granic (0.67, методичка про границы) и upravlenie-assortimentom (про модуль). Беру первые две + дополнительно справочник по модулю, чтобы покрыть bscontrol-сторону шире.

Использованные инструменты

  • mcp__topcontrol__search_docs x2 — параллельно с фильтрами source=infostena и source=bscontrol по запросу «ABC-анализ показатели».
  • mcp__topcontrol__get_article x3 — pokazateli-abc-analiza-kakie-nuzhny-i-zachem (infostena), spr-r4-8-1-abc-metody-granic + upravlenie-assortimentom (bscontrol).

Выбор статей:

  • infostena: pokazateli-abc-analiza-kakie-nuzhny-i-zachem (score 0.83) — основная методологическая статья по теме.
  • bscontrol: spr-r4-8-1-abc-metody-granic (0.67) — главная справка по ABC + контекстный upravlenie-assortimentom (0.75) для покрытия модуля целиком.

(1) Общие моменты

Признаваемое обоими: ABC-анализ — базовый инструмент управления ассортиментом Где звучит: infostena: пример «Сухие смеси»; bscontrol: модуль «Управление ассортиментом» ──────────────────────────────────────── Признаваемое обоими: Стандартное число групп — 3 (A/B/C), но можно вводить дополнительные AA и CC Где звучит: bscontrol: явно в spr-r4-8-1-…; infostena: упоминается в смежной avs-analiz-vam-ne-nuzhen-6-prichin ──────────────────────────────────────── Признаваемое обоими: Границы по Парето (80/95) — лишь один из вариантов, есть и другие методы Где звучит: infostena: «Парето — примитив, в большинстве случаев не работает»;

bscontrol: даёт 4 метода как равноправные ──────────────────────────────────────── Признаваемое обоими: ABC нужно совмещать с XYZ (и опционально с Тренд / БКГ) Где звучит: infostena: «AB + XYZ + Тренд» (в avs-analiz-vam-ne-nuzhen-6-prichin); bscontrol: модуль умеет ABC + XYZ + ABC+XYZ + Тренд + БКГ ──────────────────────────────────────── Признаваемое обоими: Источник один — система ТопКонтроль Где звучит: infostena — методология Алексея Севера; bscontrol — справка той же

программы

(2) Что есть в infostena и нет в bscontrol

  1. Методология подбора показателей. Прямо названо «минимум 5 обязательных» (выручка ₽, валовая прибыль ₽, % наценки, количество документов/клиентов, остатки ₽) + 2 дополнительных (отпускная/закупочная цена, количество уникальных SKU). У bscontrol в справке про показатели нет — только ссылка на Pokazateli_TopKontrol.xls.
  2. Бизнес-логика «зачем каждый показатель». На кейсах:
  • Цемент — группа A по выручке/прибыли, но C по наценке → не самый ценный товар.
  • Соль/Сода/Спички — A по количеству документов при низкой марже → нельзя выкидывать, это якорь трафика.
  • Высокая выручка по одному документу одному клиенту → не повод закупать впрок.
  1. Применение ABC к ценовому сегментированию. ABC по отпускной цене = автоматическое деление на топ/средний/эконом.
  2. Применение ABC к балансировке ассортимента. Соотношение «доля категории в выручке» vs «доля в количестве SKU» подсказывает, где расширять матрицу, где резать (пример: цемент даёт 21% выручки одной SKU — кандидат на расширение; затирка — 0.5% продаж при 12% SKU — кандидат на сокращение).
  3. Критика и подводные камни. Отдельная статья «ABC-анализ ВАМ НЕ НУЖЕН — 6 причин»: новинки и товары «под заказ» искажают результат, нельзя смешивать неоднородные категории, нельзя строить ABC по одному показателю.
  4. Объяснение разницы «количество документов» vs «количество клиентов» и почему первое точнее отражает частоту спроса.

(3) Что есть в bscontrol и нет в infostena

  1. Конкретные численные границы по умолчанию:
  • Эмпирический: A < 80%, 80% < B < 95%, C > 95%.
  • Метод сумм: шкала 0–200%, границы A=100%, B=145%, C=200%.
  1. Формальное математическое описание методов разбиения:
  • Эмпирический — границы задаются вручную / по умолчанию.
  • Метод сумм — суммируется доля объектов + доля показателя, даёт более гибкое разбиение.
  • Метод 1-й касательной — геометрия: прямая OK через края кривой ABC, параллельная касательная даёт точку M (граница A/B), затем по MK — точку N (граница B/C).
  • Метод 2-й касательной — рекурсивное применение касательных для очень пологих кривых; «выкидываем неважное, из остального выделяем самое важное».
  1. Атрибуция авторов методов: Лукинский В. С. (1-я касательная, ссылка на adviss.ru), Андрей Фишер (2-я касательная, ссылка на форум закупщиков).
  2. Прямая связь с другими аналитическими модулями программы:
  • XYZ через коэффициент вариации (отдельная справка Spr_R4_8_2).
  • Алгоритм тренда (отдельный Excel metodtrend.xls).
  • Характеристика совмещённых групп ABC+XYZ (Spr_R4_8_3).
  • Матрица БКГ + стратегии для каждого сектора (Spr_R4_8_4, Spr_R4_8_5).
  • Кросс-анализ.
  1. Технические артефакты: скачиваемые таблицы (Pokazateli_TopKontrol.xls, metodtrend.xls) — то, чего инфостена принципиально не даёт.

Сухой остаток

Два источника дополняют друг друга, а не конкурируют:

  • infostena отвечает на вопрос «какие показатели выбрать и зачем» — методология, бизнес-кейсы, типичные ошибки.
  • bscontrol отвечает на вопрос «как технически разделить ряд на группы» — формулы, методы границ, авторские алгоритмы и связи с соседними модулями (XYZ, тренд, БКГ).

Замечание про корпус: в pokazateli-… (infostena) нет описания методов границ, но они подробно разобраны в другой статье того же курса — ustanovka-granic-grupp-v-avs-analize-opisanie-i-analiz-metodov (засветилась в поиске со score 0.54). То есть инфостена эти методы тоже даёт, но разносит знания по урокам, а bscontrol — собирает в один справочный документ.

Вопрос 8. Elicitation — короткий запрос «abc»

Вызови mcp__topcontrol__search_docs с параметром query=“abc” (и больше ничего — никаких фильтров). Это коротко достаточно чтобы сервер сработал по Elicitation. Покажи ответ.

Ответ сервера

Никакого Elicitation не пришло. Сервер молча выполнил запрос с дефолтным limit=5 и вернул обычный список — ни запроса уточнения, ни специального флага. С точки зрения MCP-протокола topcontrol сервер на короткий запрос не реагирует особым образом — он просто проксирует поисковую выдачу.

Top-5 результатов

┌─────┬────────────────────────────────────────────────────┬────────┬─────┐
│     │                                                    │ Source │ Sco │
│  #  │                        Slug                        │   /    │ re  │
│     │                                                    │ Course │     │
├─────┼────────────────────────────────────────────────────┼────────┼─────┤
│     │                                                    │ infost │     │
│ 1   │ nesnizhaemyj-ostatok-i-maksimalnyj-zapas-v-zakupke │ ena /  │ 0.5 │
│     │ -tovarov                                           │ zakupk │ 00  │
│     │                                                    │ i      │     │
├─────┼────────────────────────────────────────────────────┼────────┼─────┤
│     │                                                    │ infost │     │
│ 2   │ brt-metod-pri-zakaze-postavshhiku                  │ ena /  │ 0.3 │
│     │                                                    │ zakupk │ 33  │
│     │                                                    │ i      │     │
├─────┼────────────────────────────────────────────────────┼────────┼─────┤
│     │                                                    │ infost │     │
│ 3   │ raspredelenie-tovara-s-raspredelitelnogo-sklada-na │ ena /  │ 0.2 │
│     │ -torgovye-tochki                                   │ zakupk │ 00  │
│     │                                                    │ i      │     │
├─────┼────────────────────────────────────────────────────┼────────┼─────┤
│     │                                                    │ infost │     │
│ 4   │ postavka-i-raspredelenie-zapasov                   │ ena /  │ 0.1 │
│     │                                                    │ zakupk │ 67  │
│     │                                                    │ i      │     │
├─────┼────────────────────────────────────────────────────┼────────┼─────┤
│     │                                                    │ infost │     │
│ 5   │ zakupka-tovara-pri-v2v-prodazhax-i-prodazhax-pod-z │ ena /  │ 0.1 │
│     │ akazy-klientov                                     │ zakupk │ 25  │
│     │                                                    │ i      │     │
└─────┴────────────────────────────────────────────────────┴────────┴─────┘

Что это говорит

  • Топ-1 не про ABC. Это про неснижаемый остаток и максимальный запас. Текст chunk’а вообще не содержит слова «ABC».
  • Семантика «abc» не угадана. На запрос «ABC-анализ» сервер до этого уверенно ставил pokazateli-abc-analiza-… (score 0.83) и spr-r4-8-1-abc-metody-granic (0.67). Здесь же ни одной из этих статей в top-5 нет вообще.
  • Латиница против русского корпуса. Запрос abc — три латинских символа. BM25-плечо с русским стеммером трактует это как незнакомый токен; dense-эмбеддинг от тоже трёх символов даёт расплывчатый вектор. RRF фактически выдаёт «случайный» топ среди статей с высокими общими весами в курсе zakupki.
  • Распределение scores 0.50→0.33→0.20→0.17→0.13 — характерная «1/k» от RRF без сильного сигнала. Тот же паттерн я отмечал в out-of-domain тесте про QCD. Это сервер так показывает «реально хороших совпадений нет».
  • Сервер ничего не валидирует. Минимальной длины запроса, проверки языка, требования уточнить — нет. С точки зрения клиента нужно самому отсекать такие запросы или поднимать порог по score (~0.5 на этой KB — это уже почти «шум»).

Краткое практическое следствие

Чтобы найти ABC корректно, надо подавать запрос на языке корпуса и с осмысленным словосочетанием — «ABC-анализ», «АВС-анализ показатели», либо ставить фильтр source. Голый трёхбуквенный латинский токен сервер не «допросит» пользователя — он просто отдаст релевантный шум.

✻ Baked for 1m 8s