Initial import NDC_1C

2026-03-26 10:38:25 +03:00
commit a162d77ef7
2943 changed files with 3615871 additions and 0 deletions
@@ -0,0 +1,413 @@
+TZ_LLM_Normalizer_v1.1.1.md
+
+Да, ты правильно понимаешь.
+
+Сейчас у вас набор **типизированный и управляемый**:
+
+* кейсы уже разложены по классам;
+* видно, где именно остаточные промахи;
+* промахи уже не системные, а **пограничные**;
+* значит, текущий этап — это именно **шлифовка на известных типах**, а не поиск всей правды о мире.
+
+Именно поэтому сейчас есть смысл делать **v1.1.1 polish**:
+не большой новый этап, а аккуратную доводку по 3–5 остаточным паттернам, с минимальным риском деградации и минимальным бюджетом.
+
+---
+
+# Главное про риск деградации
+
+Риск деградации тут **есть**, но он уже локальный, не катастрофический.
+
+## Откуда риск
+
+Сейчас normalizer уже хорошо держит:
+
+* schema,
+* route,
+* causal semantics,
+* cross-entity.
+
+Если начать слишком агрессивно править prompt’ы, можно:
+
+* случайно сломать уже хорошие `cross_entity`;
+* ухудшить `route_hint_accuracy`;
+* вернуть лишние переэскалации;
+* попортить confidence-policy.
+
+## Поэтому правильный режим такой
+
+Нужно делать не “ещё один большой тюнинг”, а:
+
+* **не трогать то, что уже даёт 100%**
+* править только:
+
+  * `period_close_risk` vs `heavy_analytical`
+  * `drilldown_explain` vs лишний `needs_cross_entity_join`
+  * `anomaly_probe` vs лишний `batch_refresh_then_store`
+
+То есть это именно **surgical patch**, а не новая версия всего normalizer’а.
+
+---
+
+# ТЗ для Codex: Normalizer v1.1.1 Polish
+
+## 1. Цель этапа
+
+Провести точечную доводку `normalizer_v1_1` до `normalizer_v1_1_1`, чтобы улучшить остаточные показатели **без деградации уже работающих классов** и без дорогих повторных прогонов.
+
+Цели:
+
+* убрать оставшиеся пограничные mismatch’и;
+* улучшить согласованность `intent_class` и `requires`;
+* уменьшить лишнюю route escalation;
+* сохранить текущие сильные результаты:
+
+  * `schema_validation_pass_rate = 100`
+  * `route_hint_accuracy = 96.67`
+  * `cross_entity = 100%`
+  * `high_confidence_error_rate = 0`
+
+---
+
+## 2. Scope этапа
+
+### В scope входит
+
+* точечный forensic-аудит остаточных mismatch’ов;
+* минимальная правка taxonomy logic;
+* минимальная правка few-shot и developer prompt;
+* контрольный микро-прогон на узком наборе кейсов;
+* оценка риска деградации относительно v1.1.
+
+### В scope не входит
+
+* новый большой eval на 30+ новых кейсах;
+* переписывание всей схемы;
+* переписывание всего prompt manager;
+* новая архитектура normalizer;
+* массовый prompt sweep;
+* расширение доменного словаря во все стороны.
+
+---
+
+## 3. Что именно надо чинить
+
+## Паттерн 1. `period_close_risk` уезжает в `heavy_analytical`
+
+### Симптом
+
+Вопросы про предзакрытие/конец периода/что взорвётся в последний день:
+
+* понимаются по route правильно;
+* но получают `intent_class = heavy_analytical` вместо `period_close_risk`.
+
+### Что нужно сделать
+
+Уточнить taxonomy:
+
+Если вопрос содержит смысл:
+
+* предзакрытие,
+* конец периода,
+* перед сдачей отчетности,
+* в последний день,
+* что взорвётся,
+* что критично перед закрытием,
+* где опасные хвосты перед закрытием,
+
+то primary intent должен быть:
+
+* `period_close_risk`
+
+Даже если при этом:
+
+* нужен обзор,
+* нужна приоритизация,
+* нужен batch route.
+
+### Важно
+
+`period_close_risk` не должен исчезать внутрь `heavy_analytical`.
+`heavy_analytical` — это обзорный/рейтинговый класс.
+`period_close_risk` — это специальный предметный класс с периодной угрозой.
+
+---
+
+## Паттерн 2. В точечном drilldown лишне поднимается `needs_cross_entity_join = true`
+
+### Симптом
+
+Для вопросов вида:
+
+* “покажи документ №... и связанную проводку”
+* “покажи карточку конкретной операции и связанную проводку”
+
+маршрут правильный:
+
+* `live_mcp_drilldown`
+
+intent тоже правильный:
+
+* `drilldown_explain`
+
+Но в `requires` появляется лишнее:
+
+* `needs_cross_entity_join = true`
+
+### Что нужно сделать
+
+Уточнить правило:
+
+Если вопрос:
+
+* про **один конкретный объект**
+* и у него есть идентификатор / номер / ref / карточка / конкретная операция / конкретный документ,
+* и задача — точечно показать source-of-record / связанную проводку / один связанный объект,
+
+то:
+
+* `needs_exact_object_trace = true`
+* `needs_runtime_truth = true`
+* `needs_cross_entity_join = false`
+
+Даже если в вопросе упоминается “связанная проводка”.
+
+### Логика
+
+Связанный объект в точечном drilldown — это ещё не multi-entity join в смысле causal report.
+
+---
+
+## Паттерн 3. `anomaly_probe` местами переэскалирует в `batch_refresh_then_store`
+
+### Симптом
+
+Есть вопрос уровня:
+
+* “где по июню выглядит подозрительно, но без точечного документа, просто дай зоны риска”
+
+Ожидание:
+
+* `anomaly_probe`
+* `store_feature_risk`
+
+Факт:
+
+* `anomaly_probe`
+* но route уходит в `batch_refresh_then_store`
+
+### Что нужно сделать
+
+Уточнить правило route hint:
+
+Если:
+
+* вопрос аномальный / риск-ориентированный,
+* не требует ranking,
+* не требует whole-company overview,
+* не требует full prioritized review,
+* не требует batch-scale summary,
+
+то:
+
+* route должен оставаться `store_feature_risk`
+
+Даже если:
+
+* есть `needs_period_cut = true`
+* есть общая риск-лексика.
+
+### Логика
+
+Сам по себе “июнь” или “зоны риска” не должен автоматически толкать всё в batch.
+
+---
+
+## 4. Что надо поменять в prompt’ах
+
+## 4.1 Developer prompt
+
+Нужно добавить 3 точечных блока правил:
+
+### Блок A. `period_close_risk`
+
+```text
+Если вопрос явно относится к предзакрытию, закрытию периода, сдаче отчетности, концу месяца или рискам последнего дня, primary intent_class должен быть period_close_risk, а не heavy_analytical, даже если требуется обзор или приоритизация.
+```
+
+### Блок B. exact drilldown
+
+```text
+Если вопрос относится к одному конкретному документу, операции, номеру, ref или объекту и просит показать связанную проводку или источник, это exact object trace. В таком случае needs_cross_entity_join не поднимается, если не требуется анализ множества сущностей или нескольких кейсов.
+```
+
+### Блок C. anomaly without heavy batch
+
+```text
+Если вопрос просит показать зоны риска, подозрительные случаи или аномалии без рейтинга, без full overview и без company-wide aggregation, route_hint должен быть store_feature_risk, а не batch_refresh_then_store.
+```
+
+---
+
+## 4.2 Few-shot
+
+Добавить **ровно 3 новых few-shot**:
+
+### Few-shot 1
+
+`period_close_risk` vs `heavy_analytical`
+
+Пример:
+
+* “Перед закрытием периода что у нас может взорваться в последний день?”
+  Ожидание:
+* `intent_class = period_close_risk`
+* `route_hint = batch_refresh_then_store`
+
+### Few-shot 2
+
+точечный drilldown без `needs_cross_entity_join`
+
+Пример:
+
+* “Покажи документ №TRX-88 и связанную проводку по 51”
+  Ожидание:
+* `intent_class = drilldown_explain`
+* `needs_exact_object_trace = true`
+* `needs_cross_entity_join = false`
+* `route_hint = live_mcp_drilldown`
+
+### Few-shot 3
+
+anomaly without batch escalation
+
+Пример:
+
+* “Где по июню выглядит подозрительно, просто дай зоны риска без детального разбора”
+  Ожидание:
+* `intent_class = anomaly_probe`
+* `route_hint = store_feature_risk`
+
+---
+
+## 5. Что нельзя трогать
+
+Codex запрещено:
+
+* ухудшать cross-entity rules;
+* переписывать causal language interpretation;
+* менять schema;
+* трогать confidence logic, если это не требуется точечно;
+* добавлять много новых few-shot;
+* делать большие перестройки domain prompt.
+
+Сильные зоны v1.1:
+
+* `cross_entity`
+* `heavy_analytical`
+* `rule_based_account_control`
+* общий `route_hint`
+  Их надо **сохранять**, а не “переосмыслять”.
+
+---
+
+## 6. Прогоны и бюджет
+
+### Режим
+
+Только **микро-проверка**, очень экономно.
+
+### Лимит
+
+* максимум **5 API-вызовов** на весь этап polish;
+* один кейс = один запрос;
+* без повторов, кроме технического fail;
+* `temperature = 0`
+
+### Контрольный набор
+
+Проверить только эти кейсы:
+
+1. `NQ-008`
+2. `V11-DD-005`
+3. `V11-OT-003`
+4. `V11-OT-004`
+5. `V11-OT-005`
+
+### Зачем именно они
+
+Они покрывают все три остаточных паттерна:
+
+* drilldown overspecification,
+* taxonomy drift,
+* route over-escalation.
+
+---
+
+## 7. Что должен выдать Codex
+
+### Артефакты
+
+1. `docs/normalizer_v1_1_1_patch_notes.md`
+2. обновлённый:
+
+   * `prompts/developer/normalizer_v1_1_1.txt`
+   * `prompts/fewshot/normalizer_fewshot_v1_1_1.txt`
+3. `reports/normalizer_v1_1_1_micro_eval.json`
+4. `reports/normalizer_v1_1_1_micro_eval.md`
+
+### В patch notes обязательно указать
+
+* что именно было изменено;
+* какие 3 паттерна лечили;
+* почему изменения безопасны;
+* сколько API-вызовов реально потрачено;
+* были ли ретраи;
+* что улучшилось;
+* что осталось как есть.
+
+---
+
+## 8. Критерии приёмки
+
+Этап считается принятым, если:
+
+1. не превышен лимит в 5 запросов;
+2. schema validation остаётся 100;
+3. `NQ-008` и `V11-DD-005` больше не поднимают лишний `needs_cross_entity_join`;
+4. `V11-OT-003` и `V11-OT-005` получают `intent_class = period_close_risk`;
+5. `V11-OT-004` получает `route_hint = store_feature_risk`;
+6. не возникает деградации на уже сильных классах;
+7. patch описан прозрачно и без “магических” неясных изменений.
+
+---
+
+## 9. Честная цель этапа
+
+Не надо ставить задачу “добить всё до 99”.
+
+Правильная цель этого этапа:
+
+* подчистить остаточные пограничные ошибки,
+* не поломать working core,
+* зафиксировать устойчивую v1.1.1,
+* после этого уже собирать **новую пачку других кейсов** на следующем этапе.
+
+То есть сейчас:
+**не расширение мира, а полировка известной карты.**
+
+---
+
+## 10. Короткая версия для Codex
+
+Сделать v1.1.1 patch:
+
+* точечно поправить `period_close_risk` vs `heavy_analytical`,
+* убрать лишний `needs_cross_entity_join` в точечном drilldown,
+* убрать лишнюю batch-эскалацию для мягкого anomaly-probe,
+* добавить 3 few-shot,
+* сделать микро-прогон на 5 кейсах,
+* не потратить больше 5 запросов,
+* не трогать сильные части модели.
+
+