Этап 4 / Волна 18 закрытие блокеров по времени, доменной полярности и допуску доказательной базы
This commit is contained in:
parent
7eb1410501
commit
d7e145010b
|
|
@ -0,0 +1,483 @@
|
|||
ssistant_runtime_ground_truth_audit.md
|
||||
|
||||
## Независимый архитектурно-процессный аудит фактического runtime-поведения assistant pipeline
|
||||
|
||||
## Цель: не чинить, а сделать подтверждённый рентген текущего механизма
|
||||
|
||||
### 1. Контекст
|
||||
|
||||
Проект находится в состоянии, где:
|
||||
|
||||
* архитектурный baseline уже поднят;
|
||||
* Stage 4 формально удержан в `P0-only` режиме;
|
||||
* на Chat20 достигался green по продуктовым метрикам;
|
||||
* но live-path ранее требовал отдельной дочистки, а в follow-up уже зафиксирована необходимость финального live-rerun и consolidated acceptance note.
|
||||
|
||||
Текущая проблема: есть риск, что команда продолжает локально улучшать answer behavior, purity, wording, leakage и отдельные guards, **не имея подтверждённой картины того, как реально работает весь pipeline после пользовательского вопроса**.
|
||||
|
||||
Нужен не очередной fix-wave, а **объективный аудит фактического процесса**, основанный на:
|
||||
|
||||
* коде,
|
||||
* конфигурации,
|
||||
* реальных тестовых прогонах,
|
||||
* debug/runtime traces,
|
||||
* подтверждённых артефактах.
|
||||
|
||||
---
|
||||
|
||||
## 2. Главная цель задания
|
||||
|
||||
Нужно **полностью восстановить и доказательно описать реальный end-to-end цикл**:
|
||||
|
||||
**пользовательский вопрос → normalizer/router → route → retrieval → snapshot/live access → graph/problem-unit/evidence layers → answer composer → итоговый ответ**
|
||||
|
||||
Нужно не пересказывать старые отчёты, а:
|
||||
|
||||
* проверить, что реально происходит;
|
||||
* показать, какие этапы действительно существуют в runtime;
|
||||
* показать, какие этапы только декларируются;
|
||||
* показать, где именно строится гипотеза;
|
||||
* показать, существует ли вообще обязательный этап добычи доказательной базы под вопрос пользователя;
|
||||
* показать, на каких реальных данных строится ответ.
|
||||
|
||||
---
|
||||
|
||||
## 3. Жёсткие ограничения задания
|
||||
|
||||
### Что делать нельзя
|
||||
|
||||
1. Не выполнять в этом задании архитектурный redesign.
|
||||
2. Не вносить большие изменения в код как часть “исправления”.
|
||||
3. Не подменять аудит выводами из старых md-отчётов без фактической проверки.
|
||||
4. Не считать Stage 4 report источником истины — использовать его только как reference map.
|
||||
5. Не ограничиваться unit-тестами без runtime traces.
|
||||
6. Не делать “оптимистичный” вывод, если нет подтверждающих артефактов.
|
||||
|
||||
### Что делать можно
|
||||
|
||||
1. Добавлять временное логирование/трассировку.
|
||||
2. Добавлять временные probe/debug hooks.
|
||||
3. Делать controlled test runs.
|
||||
4. Создавать отчёты, matrices, trace dumps, snapshot inventories, diagrams и служебные md/json файлы в `docs/ARCH`.
|
||||
|
||||
---
|
||||
|
||||
## 4. Базовый исследовательский вопрос аудита
|
||||
|
||||
Нужно ответить на главный вопрос:
|
||||
|
||||
### **Что именно реально делает система после пользовательского вопроса, и на каком основании она формирует вывод?**
|
||||
|
||||
Подвопросы, на которые аудит обязан дать подтверждённые ответы:
|
||||
|
||||
1. Какие этапы реально проходят всегда, а какие — опциональны?
|
||||
2. Есть ли отдельный обязательный шаг:
|
||||
|
||||
* формулировки claim,
|
||||
* адресного похода за доказательствами,
|
||||
* проверки обязательных звеньев цепочки,
|
||||
* сборки verdict?
|
||||
3. Или система сейчас в основном работает как:
|
||||
|
||||
* hypothesis-first,
|
||||
* signal-first,
|
||||
* snapshot-first,
|
||||
* partial live probe,
|
||||
* answer synthesis?
|
||||
4. Какие именно данные реально используются:
|
||||
|
||||
* какие snapshot файлы,
|
||||
* какого они размера,
|
||||
* какого типа данные в них лежат,
|
||||
* какая глубина и полнота этих данных,
|
||||
* хватает ли их для восстановления цепочек?
|
||||
5. Что реально делает MCP/live:
|
||||
|
||||
* какие вызовы идут,
|
||||
* когда идут,
|
||||
* с какими аргументами,
|
||||
* что возвращают,
|
||||
* являются ли они доказательной базой или только дополнительным слабым сигналом?
|
||||
6. Где и как рождаются:
|
||||
|
||||
* route,
|
||||
* semantic profile,
|
||||
* graph traversal,
|
||||
* domain purity,
|
||||
* problem units,
|
||||
* evidence,
|
||||
* confidence,
|
||||
* limitations?
|
||||
7. На каком шаге система впервые делает интерпретацию?
|
||||
8. До или после сбора фактов?
|
||||
9. Есть ли в runtime механизм, который запрещает ответу звучать уверенно при неполной доказательной базе?
|
||||
10. Что в pipeline реально является фундаментом ответа:
|
||||
|
||||
* факт,
|
||||
* сигнал,
|
||||
* эвристика,
|
||||
* graph hint,
|
||||
* snapshot artifact,
|
||||
* live lookup,
|
||||
* LLM interpretation?
|
||||
|
||||
---
|
||||
|
||||
## 5. Что именно нужно проверить в коде и рантайме
|
||||
|
||||
### A. Runtime process map
|
||||
|
||||
Нужно построить фактическую карту pipeline:
|
||||
|
||||
* входной user message;
|
||||
* normalizer;
|
||||
* decomposition/fragments/requirements;
|
||||
* route selection;
|
||||
* retrieval backend(s);
|
||||
* snapshot access;
|
||||
* live MCP access;
|
||||
* graph logic;
|
||||
* domain guardrails;
|
||||
* problem-unit assembly;
|
||||
* evidence packaging;
|
||||
* answer composer;
|
||||
* debug/export behavior.
|
||||
|
||||
Для каждого шага указать:
|
||||
|
||||
* модуль/файл/функцию;
|
||||
* вход;
|
||||
* выход;
|
||||
* обязательность шага;
|
||||
* где принимается решение;
|
||||
* deterministic это или LLM-mediated;
|
||||
* есть ли logging/trace.
|
||||
|
||||
### B. Snapshot reality audit
|
||||
|
||||
Нужно провести отдельный аудит snapshot-слоя:
|
||||
|
||||
1. Какие snapshot-источники реально участвуют в Stage 4.
|
||||
2. Где они лежат.
|
||||
3. Какие размеры файлов.
|
||||
4. Какие сущности/поля/таблицы/срезы содержат.
|
||||
5. На какие вопросы они вообще способны отвечать.
|
||||
6. Какие вопросы они принципиально не могут закрыть без live access.
|
||||
7. Есть ли разрыв между “в документах написано heavy/deep snapshots” и фактической полнотой snapshot-data.
|
||||
|
||||
### C. Live MCP reality audit
|
||||
|
||||
Нужно проверить:
|
||||
|
||||
1. Какие MCP/live методы реально вызываются на контрольных вопросах.
|
||||
2. На каком шаге pipeline это происходит.
|
||||
3. Какие аргументы реально передаются.
|
||||
4. Идут ли вызовы на:
|
||||
|
||||
* адресный сбор доказательств,
|
||||
* восстановление цепочки,
|
||||
* сверку договора/объекта расчётов,
|
||||
* closure/tax/book/register verification,
|
||||
или live используется только как ограниченный дополнительный сигнал.
|
||||
5. Есть ли ситуации, где:
|
||||
|
||||
* `matched_rows = 0`,
|
||||
* account scope не применён,
|
||||
* live не подтвердил claim,
|
||||
* но ответ всё равно строится как содержательный grounded answer.
|
||||
Это уже наблюдалось в traces и должно быть отдельно проверено.
|
||||
|
||||
### D. Evidence contract audit
|
||||
|
||||
Нужно проверить, существует ли в системе реальный слой:
|
||||
|
||||
* claim verification,
|
||||
* evidence admissibility,
|
||||
* proof verdict.
|
||||
|
||||
Нужно установить:
|
||||
|
||||
1. Есть ли отдельный этап “сначала собрали факты, потом интерпретировали”.
|
||||
2. Или фактически происходит наоборот:
|
||||
|
||||
* сначала формируется hypothesis/problem unit,
|
||||
* потом под неё подбираются supporting signals.
|
||||
3. Какие типы evidence реально существуют:
|
||||
|
||||
* hard evidence,
|
||||
* weak mapping,
|
||||
* graph hint,
|
||||
* problem signal,
|
||||
* partial support,
|
||||
* inadmissible noise.
|
||||
4. Есть ли gate, который вырезает нерелевантное evidence.
|
||||
5. Если такого gate нет — это нужно зафиксировать как structural gap.
|
||||
|
||||
### E. Answer truthfulness audit
|
||||
|
||||
Нужно проверить, что именно уходит наружу:
|
||||
|
||||
* гипотеза,
|
||||
* доказанный факт,
|
||||
* partial coverage,
|
||||
* explain mode,
|
||||
* limitation-first answer,
|
||||
* pseudo-grounded answer.
|
||||
|
||||
Нужно установить:
|
||||
|
||||
1. Умеет ли система различать:
|
||||
|
||||
* “доказано”,
|
||||
* “опровергнуто”,
|
||||
* “недостаточно данных”.
|
||||
2. Или наружу в основном уходит “похоже / есть признаки / часть цепочки подтверждена”.
|
||||
3. Где answer composer теряет честность или, наоборот, слишком рано интерпретирует слабый сигнал как почти доказанный вывод.
|
||||
|
||||
---
|
||||
|
||||
## 6. Обязательный контрольный набор для аудита
|
||||
|
||||
Нужно прогнать минимум ядро из вопросов по company snapshot July 2020, потому что именно на нём уже формулировались P0-требования. В первую очередь использовать 8 сильных core-вопросов: расчёты 60–62, НДС, month-close, РБП, limitation honesty.
|
||||
|
||||
Минимально обязательны к прогону:
|
||||
|
||||
1. Оплата 55 200 по договору № 01/19-ПТ — почему долг мог остаться.
|
||||
2. Поступление 276 873,60 — корректно ли зачёлся аванс 15 июля.
|
||||
3. Платежи 40 860 и 20 000 по договору № 1-ПМ/2020 — это аванс или закрытие дебиторки.
|
||||
4. Услуги связи + НДС 233,33 + счёт-фактура — полная ли НДС-цепочка.
|
||||
5. Есть ли покупки июля с неполным НДС-контуром.
|
||||
6. Закрытие косвенных расходов 31 июля — не осталось ли хвостов.
|
||||
7. Списание РБП — не живёт ли часть РБП дольше ожидаемого.
|
||||
8. После полного month-end — что реально проблема, а что нормальный остаток.
|
||||
|
||||
---
|
||||
|
||||
## 7. Формат выполнения аудита
|
||||
|
||||
### Этап 1. Static architecture pass
|
||||
|
||||
Без изменений логики:
|
||||
|
||||
* прочитать relevant code paths;
|
||||
* построить map модулей;
|
||||
* составить runtime call graph;
|
||||
* определить места принятия решений.
|
||||
|
||||
### Этап 2. Instrumentation pass
|
||||
|
||||
Добавить временное диагностическое логирование, если его не хватает, чтобы фиксировать:
|
||||
|
||||
* какой route выбран;
|
||||
* какие sources выбраны;
|
||||
* какой snapshot использован;
|
||||
* какие live MCP calls ушли;
|
||||
* какие аргументы ушли;
|
||||
* что вернулось;
|
||||
* какие evidence items попали в answer;
|
||||
* на каком шаге появился primary interpretation;
|
||||
* какой confidence/limitation режим ушёл наружу.
|
||||
|
||||
### Этап 3. Controlled runtime pass
|
||||
|
||||
Прогнать контрольный набор вопросов с включённым audit logging.
|
||||
|
||||
### Этап 4. Comparative pass
|
||||
|
||||
Для каждого вопроса восстановить таблицу:
|
||||
|
||||
* что спросил пользователь;
|
||||
* какие anchors извлеклись;
|
||||
* какой route selected;
|
||||
* какие snapshot datasets реально использовались;
|
||||
* какие live calls реально были;
|
||||
* какие факты реально подтверждены;
|
||||
* что осталось недоказанным;
|
||||
* где возникла гипотеза;
|
||||
* из чего собрался финальный ответ.
|
||||
|
||||
### Этап 5. Structural gap analysis
|
||||
|
||||
Выделить:
|
||||
|
||||
* отсутствующие обязательные шаги;
|
||||
* смешанные режимы;
|
||||
* места ранней интерпретации;
|
||||
* фиктивную или слабую доказательную базу;
|
||||
* расхождение между декларируемой архитектурой и фактическим runtime.
|
||||
|
||||
---
|
||||
|
||||
## 8. Главные вопросы, на которые аудит обязан ответить в финальном отчёте
|
||||
|
||||
1. Система сейчас **proof-first** или **hypothesis-first**?
|
||||
2. Есть ли у неё реальный слой **claim verification**?
|
||||
3. Что является фактическим фундаментом ответа:
|
||||
|
||||
* snapshot,
|
||||
* live lookup,
|
||||
* graph signals,
|
||||
* problem units,
|
||||
* эвристики,
|
||||
* LLM synthesis?
|
||||
4. Достаточен ли текущий snapshot-слой для company-specific July 2020 reasoning?
|
||||
5. Какие классы вопросов нельзя надёжно решать без обязательного live evidence acquisition?
|
||||
6. Есть ли в runtime этап адресного похода по цепочке:
|
||||
|
||||
* документ,
|
||||
* договор,
|
||||
* объект расчётов,
|
||||
* проводка,
|
||||
* регистр,
|
||||
* книга,
|
||||
* closure?
|
||||
7. Если такого этапа нет, где именно он должен быть встроен концептуально.
|
||||
8. Что сейчас реально делает MCP:
|
||||
|
||||
* verification,
|
||||
* lookup,
|
||||
* enrichment,
|
||||
* noise injection,
|
||||
* partial support?
|
||||
9. Какие части Stage 4 реально полезны, а какие маскируют отсутствие фундамента.
|
||||
10. Что является минимальным обязательным новым слоем, без которого дальнейшие corrective waves теряют смысл.
|
||||
|
||||
---
|
||||
|
||||
## 9. Что нужно создать в `docs/ARCH`
|
||||
|
||||
Создать новый комплект артефактов.
|
||||
|
||||
### Основной отчёт
|
||||
|
||||
`docs/ARCH/7 - assistant_runtime_ground_truth_audit_2026-03-28.md`
|
||||
|
||||
В нём должны быть разделы:
|
||||
|
||||
1. Executive summary
|
||||
2. Scope and constraints
|
||||
3. Verified runtime architecture
|
||||
4. Snapshot reality
|
||||
5. MCP/live reality
|
||||
6. Evidence acquisition reality
|
||||
7. Answer synthesis reality
|
||||
8. Control question audit
|
||||
9. Structural gaps
|
||||
10. Minimum required architectural correction
|
||||
11. What not to do next
|
||||
|
||||
### Приложения
|
||||
|
||||
1. `docs/ARCH/7A - runtime_call_graph.md`
|
||||
|
||||
* по шагам и модулям
|
||||
|
||||
2. `docs/ARCH/7B - snapshot_inventory_and_coverage.md`
|
||||
|
||||
* список snapshot-источников, размеров, сущностей, покрываемых question classes
|
||||
|
||||
3. `docs/ARCH/7C - live_mcp_call_inventory.md`
|
||||
|
||||
* какие live вызовы реально ушли на контрольных прогонах
|
||||
|
||||
4. `docs/ARCH/7D - control_question_trace_matrix.md`
|
||||
|
||||
* по каждому вопросу: route, sources, evidence, claim status, answer type
|
||||
|
||||
5. `docs/ARCH/7E - structural_gap_register.md`
|
||||
|
||||
* список критичных gap’ов с severity:
|
||||
|
||||
* blocker
|
||||
* high
|
||||
* medium
|
||||
|
||||
6. `docs/ARCH/7F - instrumentation_notes.md`
|
||||
|
||||
* что было добавлено/включено ради аудита
|
||||
|
||||
7. `docs/ARCH/audit_artifacts/`
|
||||
|
||||
* raw json traces,
|
||||
* exported debug payloads,
|
||||
* sample dialog logs,
|
||||
* live call dumps,
|
||||
* optional diagrams
|
||||
|
||||
---
|
||||
|
||||
## 10. Требования к доказательности отчёта
|
||||
|
||||
Финальный отчёт **не может** состоять из общих слов.
|
||||
Каждое важное утверждение должно быть подтверждено хотя бы одним из:
|
||||
|
||||
* ссылкой на конкретный кодовый путь;
|
||||
* runtime trace;
|
||||
* debug payload;
|
||||
* live MCP call dump;
|
||||
* snapshot inspection artifact;
|
||||
* reproduced control question log.
|
||||
|
||||
Если что-то не удалось проверить — это нужно явно маркировать:
|
||||
|
||||
* `verified`
|
||||
* `partially verified`
|
||||
* `not verified`
|
||||
* `inferred`
|
||||
|
||||
---
|
||||
|
||||
## 11. Специальный акцент аудита
|
||||
|
||||
Отдельно нужно проверить и честно описать:
|
||||
|
||||
### A. Существует ли сейчас отдельный обязательный шаг “добычи доказательной базы”
|
||||
|
||||
Не abstract retrieval, а именно:
|
||||
|
||||
* по claim пользователя;
|
||||
* с обязательными anchors;
|
||||
* с адресной проверкой звеньев цепочки.
|
||||
|
||||
### B. Не подменяется ли доказательство problem units / graph hints / snapshot signals
|
||||
|
||||
Это критический вопрос.
|
||||
|
||||
### C. Не является ли текущая система фактически:
|
||||
|
||||
**snapshot-driven hypothesis engine with partial live enrichment**
|
||||
вместо:
|
||||
**evidence-first accounting verification assistant**
|
||||
|
||||
---
|
||||
|
||||
## 12. Финальная форма вывода
|
||||
|
||||
В конце основного отчёта обязательно дать **жёсткий вердикт** в одной из форм:
|
||||
|
||||
* `VERIFIED_AS_EVIDENCE_FIRST`
|
||||
* `VERIFIED_AS_HYPOTHESIS_FIRST`
|
||||
* `MIXED_RUNTIME_WITHOUT_MANDATORY_PROOF_LAYER`
|
||||
|
||||
И отдельно:
|
||||
|
||||
* что именно уже годно;
|
||||
* что именно фундаментально отсутствует;
|
||||
* какой минимальный архитектурный слой нужен дальше;
|
||||
* почему дальнейшие локальные фиксы без этого слоя либо полезны, либо уже неокупаемы.
|
||||
|
||||
---
|
||||
|
||||
## 13. Что не должно быть результатом
|
||||
|
||||
Результатом этого задания **не должен** стать новый fix pack.
|
||||
Результатом должен стать:
|
||||
|
||||
* честный рентген,
|
||||
* подтверждённая карта runtime,
|
||||
* список gaps,
|
||||
* и ясный ответ, **что у нас вообще реально работает после вопроса пользователя**.
|
||||
|
||||
---
|
||||
|
||||
|
||||
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because it is too large
Load Diff
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
File diff suppressed because one or more lines are too long
|
|
@ -0,0 +1,229 @@
|
|||
# 6 - Полный отчет по проекту и Stage 4 (на 2026-03-28)
|
||||
|
||||
## 1) Назначение и рамки отчета
|
||||
|
||||
Отчет фиксирует:
|
||||
- общий прогресс проекта `NDC_1C / llm_normalizer`;
|
||||
- фактический статус Stage 4 с детализацией по волнам;
|
||||
- текущий baseline, метрики, артефакты и ограничения;
|
||||
- что уже стабилизировано, а что остается в зоне контроля.
|
||||
|
||||
Период, покрытый этим документом: до `2026-03-28` включительно.
|
||||
|
||||
---
|
||||
|
||||
## 2) Executive Summary
|
||||
|
||||
- Проект в целом: рабочая read-only архитектура и assistant-контур подняты, базовые слои Stage 1-7 в MVP-режиме реализованы (с Stage 7 как partial/orchestration-ready).
|
||||
- Stage 3 ранее формально закрыт (`Accepted / Closed`, 2026-03-26).
|
||||
- Stage 4 прошел через перефокус в P0-only режим (3 домена) и серию узких corrective waves.
|
||||
- На Chat20-корпусе итог Wave 16 дал полный green (`PASS=20/20`, ключевые метрики = 1.00, generic_answer_rate = 0.00).
|
||||
- На live-path после этого выполнены отдельные точечные микрофиксы (debug/export tail, period consistency, VAT grounding cleanup, RBP/FA wording locks) с техническими PASS по тестам/сборке.
|
||||
|
||||
---
|
||||
|
||||
## 3) Статус проекта в целом (вне узкого Stage 4)
|
||||
|
||||
Опорные документы:
|
||||
- `docs/ARCH/3 - mvp_prod_arch_stage_1-7_report_2026-03-23.md`
|
||||
- `docs/ARCH/5 - assistant_mode_architecture_report_2026-03-24.md`
|
||||
- `docs/accounting-assistant/accounting-assistant/03_execution/STAGE_03_CLOSEOUT_2026-03-26.md`
|
||||
|
||||
### 3.1 Архитектурный baseline проекта
|
||||
|
||||
Зафиксирована рабочая цепочка:
|
||||
`1C source (read-only) -> bridge/proxy -> refresh/canonical -> feature/anomaly -> risk -> assistant/API`.
|
||||
|
||||
По состоянию на проектные отчеты:
|
||||
- Stage 1-6: реализованы в MVP-контуре.
|
||||
- Stage 7: partial (готова спецификация и API-поверхность, без полного production orchestration-сервиса).
|
||||
|
||||
### 3.2 Assistant mode
|
||||
|
||||
На проектном уровне внедрены:
|
||||
- backend assistant endpoint + session memory;
|
||||
- answer composer;
|
||||
- debug drawer в GUI;
|
||||
- единый pipeline normalizer/routing для decomposition и assistant режимов.
|
||||
|
||||
### 3.3 Модель источников данных (операционный принцип)
|
||||
|
||||
В текущем контуре используются два источника:
|
||||
- `MCP/live`: быстрый прозвон и маршрутный доступ к данным 1С;
|
||||
- `snapshots`: тяжелые/глубокие срезы для анализа без перегруза live-команд.
|
||||
|
||||
---
|
||||
|
||||
## 4) Stage 4: зафиксированная рамка
|
||||
|
||||
Опорные execution-документы:
|
||||
- `docs/accounting-assistant/accounting-assistant/03_execution/STAGE_04_TASK_CARD.md`
|
||||
- `docs/accounting-assistant/accounting-assistant/03_execution/ARCHITECTURE_GUARDRAILS.md`
|
||||
- `docs/accounting-assistant/accounting-assistant/03_execution/ACCEPTANCE_CHECKLIST_STAGE_04.md`
|
||||
- `docs/accounting-assistant/accounting-assistant/03_execution/STAGE_04_REFOCUS_P0_PLAYBOOK_2026-03-27.md`
|
||||
|
||||
Рамка Stage 4 (после refocus):
|
||||
- режим: `P0-only`, без расширения runtime/domain scope;
|
||||
- домены baseline:
|
||||
- `settlements_60_62`
|
||||
- `vat_document_register_book`
|
||||
- `month_close_costs_20_44`
|
||||
- запрещено в рамках quality waves:
|
||||
- новые домены;
|
||||
- graph/schema expansion;
|
||||
- Stage 5 investigation как core path;
|
||||
- Stage 6 live verification layer как архитектурное расширение;
|
||||
- большие transport/routing refactors.
|
||||
|
||||
---
|
||||
|
||||
## 5) Хронология Stage 4 по волнам
|
||||
|
||||
### 5.1 Waves 5-9 (по execution-докам)
|
||||
|
||||
По `STAGE_04_TASK_CARD.md` и `STAGE_04_REFOCUS_P0_PLAYBOOK_2026-03-27.md`:
|
||||
- Wave 5: Domain Purity + Route Discipline.
|
||||
- Wave 6: Problem-First Answer Contract.
|
||||
- Wave 7: P0 Eval Harness + Formal Product Acceptance.
|
||||
- Wave 8: Route Correctness Recovery + Domain Purity Closure.
|
||||
- Wave 9: P0 Quality Hardening + Corpus Expansion + Docs Sync.
|
||||
|
||||
Ключевой результат к концу этой части:
|
||||
- baseline: `P0_ACCEPTED_WITH_LIMITATIONS`.
|
||||
|
||||
### 5.2 Waves 10-16 (по фактическим run-артефактам)
|
||||
|
||||
1. `2026-03-27_Stage_04_Wave_10_Rerun_02`
|
||||
- статус: `completed`.
|
||||
- проверено: Wave10 regression + P0 harness + build + full backend suite.
|
||||
- snapshot verdict: `P0_ACCEPTED_WITH_LIMITATIONS`, baseline stability `P0_BASELINE_STABLE_WITH_OPEN_QUALITY_GAPS`.
|
||||
|
||||
2. `2026-03-28_Stage_04_Wave_11_Business_Anchor_Object_Trace_Grounding_Leakage_Fix`
|
||||
- статус: `completed`.
|
||||
- фокус: business-anchor trace, period consistency, leakage removal, settlement grounding.
|
||||
- результат: targeted/full suite/build PASS.
|
||||
|
||||
3. `2026-03-28_Stage_04_Wave_11_Verification_Pass_Live_Rerun`
|
||||
- verdict: `VERIFICATION_NOT_PASSED_FULLY`.
|
||||
- блокеры: domain drift и confidence/limitation conflict на VAT/month-close кейсах (`q02`, `q03`).
|
||||
|
||||
4. `2026-03-28_Stage_04_Wave_12_VAT_Month_Close_Domain_Consistency_Confidence_Reconciliation`
|
||||
- статус: `TECHNICAL_PASS`.
|
||||
- verdict: `READY_FOR_WAVE12_LIVE_VERIFICATION`.
|
||||
- фокус: VAT/month-close consistency + confidence/limitation reconciliation.
|
||||
|
||||
5. `2026-03-28_Stage_04_Wave_13_Domain_Fit_Question_Type_Fit_Company_Anchor_Grounding`
|
||||
- статус: `IMPLEMENTED_NOT_ACCEPTED`.
|
||||
- verdict: `WAVE13_NOT_ACCEPTED_REQUIRES_NEXT_CORRECTIVE_WAVE`.
|
||||
- Chat20 metrics: domain 0.25, question_type 0.45, anchors 1.00, generic 0.60, first_check 0.85.
|
||||
|
||||
6. `2026-03-28_Stage_04_Wave_14_Domain_Regression_Rollback_Domain_Locked_Anchor_Usage`
|
||||
- статус: `IMPLEMENTED_ACCEPTED_WITH_LIMITATIONS`.
|
||||
- verdict: `WAVE14_ACCEPTED_WITH_LIMITATIONS`.
|
||||
- Chat20 metrics: domain 0.90, question_type 0.50, anchors 1.00, generic 0.35, first_check 0.65.
|
||||
|
||||
7. `2026-03-28_Stage_04_Wave_15_Question_Type_Contract_First_Check_Relevance`
|
||||
- статус: `IMPLEMENTED_ACCEPTED_WITH_LIMITATIONS`.
|
||||
- verdict: `WAVE15_ACCEPTED_WITH_LIMITATIONS`.
|
||||
- Chat20 metrics: domain 0.90, question_type 0.95, anchors 1.00, generic 0.35, first_check 0.90.
|
||||
|
||||
8. `2026-03-28_Stage_04_Wave_16_Residual_FAIL_Cleanup_Generic_Answer_Squeeze`
|
||||
- статус: `IMPLEMENTED_VERIFIED_CHAT20`.
|
||||
- verdict: `WAVE16_ACCEPTED`.
|
||||
- Chat20 metrics: domain 1.00, question_type 1.00, anchors 1.00, generic 0.00, first_check 1.00.
|
||||
|
||||
9. Дополнительные узкие Wave 16-проходы (live + semantic + export tail):
|
||||
- `Wave_16_Export_Debug_Tail_Fix`: `TECHNICAL_PASS`.
|
||||
- `Wave_16_Live_Corrective_Pass_Debug_Period_VAT_FA`: `TECHNICAL_PASS_AWAITING_LIVE_RERUN`.
|
||||
- `Wave_16_Live_Final_Cleanup_Debug_Leak_FA_Domain_Fix`: `TECHNICAL_PASS_AWAITING_LIVE_RERUN`.
|
||||
- `Wave_16_Micro_Fix_FA_First_Check_RBP_Wording_Live_Partial_Coverage_Specificity`: `TECHNICAL_PASS`.
|
||||
- `Wave_16_Semantic_Micro_Fix_RBP_FA_Wording_Lock`: `TECHNICAL_PASS`.
|
||||
|
||||
---
|
||||
|
||||
## 6) Динамика ключевых метрик (Chat20)
|
||||
|
||||
| Волна | domain_correctness_rate | question_type_fit_rate | company_anchor_usage_rate | generic_answer_rate | first_check_relevance_rate | PASS/SOFT/FAIL |
|
||||
|---|---:|---:|---:|---:|---:|---|
|
||||
| Wave 13 | 0.25 | 0.45 | 1.00 | 0.60 | 0.85 | 1 / 4 / 15 |
|
||||
| Wave 14 | 0.90 | 0.50 | 1.00 | 0.35 | 0.65 | 1 / 11 / 8 |
|
||||
| Wave 15 | 0.90 | 0.95 | 1.00 | 0.35 | 0.90 | 9 / 8 / 3 |
|
||||
| Wave 16 | 1.00 | 1.00 | 1.00 | 0.00 | 1.00 | 20 / 0 / 0 |
|
||||
|
||||
Вывод по динамике:
|
||||
- критический регресс домена (Wave 13) был снят;
|
||||
- question-type fit и first-check relevance доведены до целевого уровня;
|
||||
- generic collapse сжат до нуля на контрольном Chat20 прогоне;
|
||||
- anchor usage стабильно удержан.
|
||||
|
||||
---
|
||||
|
||||
## 7) Что сделано по live-path и UX-хвостам
|
||||
|
||||
В рамках late Wave 16 серии закрывались остаточные live-проблемы:
|
||||
- debug leakage;
|
||||
- period-anchor inconsistency;
|
||||
- VAT final grounding contamination;
|
||||
- FA/amortization wording и first-check предметность;
|
||||
- RBP/FA wording isolation;
|
||||
- export/debug tail (debug не должен попадать в default export).
|
||||
|
||||
Фиксы оформлены отдельными run-проходами и сопровождены targeted/full suite/build PASS.
|
||||
|
||||
---
|
||||
|
||||
## 8) Технические артефакты и дисциплина выполнения
|
||||
|
||||
### 8.1 По Stage 4 run-дисциплине
|
||||
|
||||
На актуальных волнах присутствуют стандартные артефакты:
|
||||
- `README.md`
|
||||
- `run_summary.json`
|
||||
- `prompt_dialogs/`
|
||||
- wave-specific reports (`*_metrics.json`, `*_case_matrix*.md`, `benchmark_report_before_after.md`, `чат/Chat*.txt` где применимо).
|
||||
|
||||
### 8.2 Примеры ключевых run-папок
|
||||
|
||||
- `llm_normalizer/docs/runs/2026-03-27_Stage_04_Wave_10_Rerun_02`
|
||||
- `llm_normalizer/docs/runs/2026-03-28_Stage_04_Wave_11_*`
|
||||
- `llm_normalizer/docs/runs/2026-03-28_Stage_04_Wave_12_*`
|
||||
- `llm_normalizer/docs/runs/2026-03-28_Stage_04_Wave_13_*`
|
||||
- `llm_normalizer/docs/runs/2026-03-28_Stage_04_Wave_14_*`
|
||||
- `llm_normalizer/docs/runs/2026-03-28_Stage_04_Wave_15_*`
|
||||
- `llm_normalizer/docs/runs/2026-03-28_Stage_04_Wave_16_*`
|
||||
|
||||
---
|
||||
|
||||
## 9) Текущий итоговый статус Stage 4
|
||||
|
||||
Текущий срез (на основании run-артефактов и execution-доков):
|
||||
- Stage 4 удержан в P0-only контуре (без scope-расползания по доменам/архитектуре).
|
||||
- На Chat20 достигнут `WAVE16_ACCEPTED` с полным green по ключевым продуктовым метрикам.
|
||||
- Live-path дополнительно дочищен серией точечных micro-fix проходов (debug/export, period consistency, VAT/FA/RBP wording).
|
||||
|
||||
Формально Stage 4 в рабочем состоянии для текущего P0 baseline, с документированной трассируемостью по run-папкам и метрикам.
|
||||
|
||||
---
|
||||
|
||||
## 10) Рекомендуемый операционный follow-up (без расширения scope)
|
||||
|
||||
1. Провести единый финальный live-rerun на фиксированном контрольном наборе и зафиксировать consolidated `чат.txt` в последнем run.
|
||||
2. Зафиксировать короткий consolidated acceptance note (Stage 4 final checkpoint) в execution-доках.
|
||||
3. Заархивировать Wave 10-16 summary index (один md + ссылки на run-папки), чтобы упростить передачу контекста и аудит.
|
||||
|
||||
---
|
||||
|
||||
## 11) Приложение: ключевые пути
|
||||
|
||||
- Project architecture baseline:
|
||||
- `X:\1C\NDC_1C\docs\ARCH\3 - mvp_prod_arch_stage_1-7_report_2026-03-23.md`
|
||||
- `X:\1C\NDC_1C\docs\ARCH\5 - assistant_mode_architecture_report_2026-03-24.md`
|
||||
- Stage 3 closeout:
|
||||
- `X:\1C\NDC_1C\docs\accounting-assistant\accounting-assistant\03_execution\STAGE_03_CLOSEOUT_2026-03-26.md`
|
||||
- Stage 4 execution docs:
|
||||
- `X:\1C\NDC_1C\docs\accounting-assistant\accounting-assistant\03_execution\STAGE_04_TASK_CARD.md`
|
||||
- `X:\1C\NDC_1C\docs\accounting-assistant\accounting-assistant\03_execution\ARCHITECTURE_GUARDRAILS.md`
|
||||
- `X:\1C\NDC_1C\docs\accounting-assistant\accounting-assistant\03_execution\ACCEPTANCE_CHECKLIST_STAGE_04.md`
|
||||
- `X:\1C\NDC_1C\docs\accounting-assistant\accounting-assistant\03_execution\STAGE_04_REFOCUS_P0_PLAYBOOK_2026-03-27.md`
|
||||
- Stage 4 runs root:
|
||||
- `X:\1C\NDC_1C\llm_normalizer\docs\runs`
|
||||
Binary file not shown.
|
|
@ -0,0 +1,109 @@
|
|||
# 7 - assistant_runtime_ground_truth_audit_2026-03-28
|
||||
|
||||
## 1. Executive Summary
|
||||
|
||||
Status: `COMPLETED`
|
||||
|
||||
Final verdict: `MIXED_RUNTIME_WITHOUT_MANDATORY_PROOF_LAYER`
|
||||
|
||||
Why this verdict:
|
||||
- The runtime path is technically complete and traceable end-to-end.
|
||||
- But evidence admissibility and mechanism discrimination are not strict enough for reliable accounting-grade grounding.
|
||||
- Multiple control traces still show temporal drift, domain polarity drift, and weak evidence admitted into claim support.
|
||||
|
||||
Primary evidence used in this audit:
|
||||
- `audit_artifacts/raw_traces/chat20_wave15_raw.json`
|
||||
- `audit_artifacts/raw_traces/1.txt`
|
||||
- `audit_artifacts/raw_traces/2.txt`
|
||||
- `audit_artifacts/live_calls/wave16_export_debug_tail_fix_live_inventory.json`
|
||||
- `audit_artifacts/live_calls/hard_fail_trace_ty6aQD9O0LnTvg.md`
|
||||
- `audit_artifacts/snapshot_inspection/snapshot_2020_export_inventory.json`
|
||||
- `audit_artifacts/snapshot_inspection/monthly_asof_ndjson_inventory.json`
|
||||
- `audit_artifacts/snapshot_inspection/runtime_snapshot_wiring.md`
|
||||
|
||||
## 2. Scope And Constraints
|
||||
|
||||
Scope:
|
||||
- Stage 4 runtime in P0 accounting domains.
|
||||
- Full path verification: question -> normalization/router -> route -> retrieval -> evidence/problem units -> answer.
|
||||
- Control focus: settlement / VAT / month-close core questions.
|
||||
|
||||
Constraints followed:
|
||||
- No redesign in this audit.
|
||||
- No architectural rewrite in this audit.
|
||||
- No declarative conclusions without trace/code evidence.
|
||||
|
||||
## 3. Verified Runtime Architecture
|
||||
|
||||
Status: `verified` for call chain presence, `partially verified` for semantic correctness.
|
||||
|
||||
See: `7A - runtime_call_graph.md`.
|
||||
|
||||
## 4. Snapshot Reality
|
||||
|
||||
Status: `partially verified`.
|
||||
|
||||
Observed:
|
||||
- Runtime is wired to `docs/ARCH/2020экспорт` sample JSONs (422 total records across runtime-used files).
|
||||
- `docs/ARCH/2020_monthly_company_asof_full` exists (~7.06 GB NDJSON), but is not wired into backend runtime retrieval path.
|
||||
|
||||
See: `7B - snapshot_inventory_and_coverage.md`.
|
||||
|
||||
## 5. MCP/Live Reality
|
||||
|
||||
Status: `partially verified`.
|
||||
|
||||
Observed:
|
||||
- Live call summaries are present and can be traced per `trace_id`.
|
||||
- In critical traces (`ty6aQD9O0LnTvg`, `-PdAdyMXYlf23K`) `matched_rows = 0` but `returned_rows = 12` and weakly-mapped evidence is still admitted into answer evidence block.
|
||||
|
||||
See: `7C - live_mcp_call_inventory.md`.
|
||||
|
||||
## 6. Evidence Acquisition Reality
|
||||
|
||||
Status: `not verified` for strict proof-first guarantees.
|
||||
|
||||
Key failures:
|
||||
- Temporal anchor drift: `q01` (Wave 15) normalized to `2019` for a July 2020 scenario; `ty6aQD9O0LnTvg` normalized to `2023-07-06`.
|
||||
- Domain polarity drift: settlement cases mapped to `customer_settlement` lifecycle (`stale_receivable -> receivable_closed`) in supplier/payable contexts.
|
||||
- Evidence admissibility drift: weak mappings and out-of-window years (2023/2025/2026/2030) included in evidence refs for July 2020 snapshot scenarios.
|
||||
|
||||
See: `7D - control_question_trace_matrix.md` and `7E - structural_gap_register.md`.
|
||||
|
||||
## 7. Answer Synthesis Reality
|
||||
|
||||
Status: `partially verified`.
|
||||
|
||||
Observed:
|
||||
- Answer contract structure is present (`direct_answer`, `mechanism_block`, `evidence_block`, `uncertainty_block`, `next_step_block`).
|
||||
- But mechanism discrimination is often weak: Wave 15 matrix marks multiple settlement core cases as `SOFT_PASS / generic_answer`.
|
||||
|
||||
## 8. Control Question Audit
|
||||
|
||||
Status: `completed`
|
||||
|
||||
Core 8 matrix is populated with trace-backed rows.
|
||||
|
||||
See: `7D - control_question_trace_matrix.md`.
|
||||
|
||||
## 9. Structural Gaps
|
||||
|
||||
Status: `completed`
|
||||
|
||||
Gap register with severity and acceptance criteria is added.
|
||||
|
||||
See: `7E - structural_gap_register.md`.
|
||||
|
||||
## 10. Minimum Required Architectural Correction (Stage 4 Close Criteria)
|
||||
|
||||
Minimum mandatory correction layer before Stage 4 close:
|
||||
1. Temporal hard lock for fixed company snapshot windows (no relative/default-year override).
|
||||
2. Supplier/customer polarity guard (`60/supplier/payable` vs `62/customer/receivable`) at routing/problem-unit level.
|
||||
3. Evidence admissibility gate (`matched_rows = 0`, weak mapping, out-of-window dates, account-scope mismatch).
|
||||
4. Mechanism-specific answer contract (single dominant mechanism + explicit exclusion rationale).
|
||||
|
||||
## 11. What Not To Do Next
|
||||
|
||||
- Do not treat wording improvements as proof-layer closure.
|
||||
- Do not declare Stage 4 closed only from controlled-chat aggregate metrics.
|
||||
- Do not postpone admissibility/polarity/temporal guards to later ontology waves.
|
||||
|
|
@ -0,0 +1,21 @@
|
|||
# 7A - runtime_call_graph
|
||||
|
||||
## Runtime Steps (Code + Trace Evidence)
|
||||
|
||||
| Step | Runtime block | Code evidence | Trace evidence | Verification |
|
||||
|---|---|---|---|---|
|
||||
| S1 | API ingress | `backend/src/routes/assistant.ts` (`POST /api/assistant/message`, calls `assistantService.handleMessage`) | conversation exports contain per-turn `trace_id` and timestamps | verified |
|
||||
| S2 | Follow-up binding | `backend/src/services/assistantService.ts` (`buildFollowupStateBinding`, around line 992) | investigation snapshot fields visible in exported debug payloads | partially verified |
|
||||
| S3 | Normalization/router | `assistantService.ts` uses normalizer output and route summary | payload contains `route_summary`, `fragments`, `question_type_class` | verified |
|
||||
| S4 | Execution plan | `assistantService.ts` `toExecutionPlan` (around line 339), invoked in main flow | payload has per-fragment `route` and `route_status` | verified |
|
||||
| S5 | Retrieval runtime | `backend/src/services/assistantDataLayer.ts` `executeRouteRuntime` (around line 2520) | payload `retrieval_results` present per fragment | verified |
|
||||
| S6 | Live overlay merge | `assistantDataLayer.ts` merges `live_mcp` into `summary` (around line 2550-2552) | traces show `live_mcp.fetched_rows/matched_rows/returned_rows` | verified |
|
||||
| S7 | Coverage + grounding checks | `assistantService.ts` `evaluateCoverage`/`checkGrounding` (around lines 1255-1271) | payload has `coverage_report` and `answer_grounding_check` | verified |
|
||||
| S8 | Answer composition | `assistantService.ts` calls `composeAssistantAnswer`; sanitization barriers around line 1282 | payload has `answer_structure_v11`; user-facing reply type persisted | verified |
|
||||
| S9 | Investigation state update | `backend/src/services/investigationState.ts` used in service flow | `investigation_state_snapshot` present in debug payload | partially verified |
|
||||
| S10 | Debug/export persistence | `assistantService.ts` emits debug payload fields and export-safe response | raw exports (`1.txt`,`2.txt`) include full technical blocks | verified |
|
||||
|
||||
## Notes
|
||||
|
||||
- Call chain existence is verified.
|
||||
- Semantic correctness of interpretation/evidence is not guaranteed by call-chain verification alone and is audited in `7C/7D/7E`.
|
||||
|
|
@ -0,0 +1,43 @@
|
|||
# 7B - snapshot_inventory_and_coverage
|
||||
|
||||
## Snapshot Inventory (Observed)
|
||||
|
||||
### Runtime-wired snapshot source (`docs/ARCH/2020экспорт`)
|
||||
|
||||
| File | Bytes | Records | Runtime wired |
|
||||
|---|---:|---:|---|
|
||||
| `03_snapshot_fragment_problem_cases.json` | 302,520 | 80 | yes |
|
||||
| `04_samples_SpisanieSRaschetnogoScheta.json` | 196,178 | 27 | yes |
|
||||
| `05_samples_RealizaciyaTovarovUslug.json` | 132,032 | 5 | yes |
|
||||
| `06_samples_PostuplenieTovarovUslug.json` | 181,409 | 10 | yes |
|
||||
| `07_samples_DocumentJournals.json` | 292,931 | 80 | yes |
|
||||
| `08_samples_NDS_registers.json` | 291,547 | 80 | yes |
|
||||
| `09_samples_key_fields_Recorder_Ref_Supplier_Buyer_Responsible.json` | 511,133 | 140 | yes |
|
||||
| **Total** | **1,907,750** | **422** | |
|
||||
|
||||
Code proof:
|
||||
- `backend/src/config.ts`: `ARCH_EXPORT_2020_DIR`.
|
||||
- `backend/src/services/assistantDataLayer.ts`: `ensureData()` reads files 03/04/05/06/07/08/09.
|
||||
|
||||
### Monthly as-of corpus (`docs/ARCH/2020_monthly_company_asof_full/_tmp_ndjson`)
|
||||
|
||||
| Asset | Value |
|
||||
|---|---|
|
||||
| NDJSON files | 12 (`snapshot_2020-01` ... `snapshot_2020-12`) |
|
||||
| Total size | 7,059,009,054 bytes (~7.06 GB) |
|
||||
| Runtime wired in backend path | no direct reference found |
|
||||
|
||||
## Coverage Reality
|
||||
|
||||
| Question class | Snapshot-only coverage | Reality |
|
||||
|---|---|---|
|
||||
| Settlement chain diagnostics | partial | Works for sample-level hints, but temporal/polarity drift still appears in traces |
|
||||
| VAT document-register-book chain | partial to good | Better in VAT-specific cases, but cross-domain contamination still occurs in mixed traces |
|
||||
| Month-close / RBP diagnostics | partial to good | Core traces exist, but still often `partial_coverage` with weak-confidence qualifiers |
|
||||
| Strict as-of monthly proof | not covered | Large monthly corpus exists, but runtime retrieval path is not wired to it |
|
||||
|
||||
## Audit Artifacts
|
||||
|
||||
- `audit_artifacts/snapshot_inspection/snapshot_2020_export_inventory.json`
|
||||
- `audit_artifacts/snapshot_inspection/monthly_asof_ndjson_inventory.json`
|
||||
- `audit_artifacts/snapshot_inspection/runtime_snapshot_wiring.md`
|
||||
|
|
@ -0,0 +1,30 @@
|
|||
# 7C - live_mcp_call_inventory
|
||||
|
||||
## Live Call Matrix (Trace-backed)
|
||||
|
||||
| Trace ID | Question type | `matched_rows` | `returned_rows` | Account scope | Key observation | Verification value |
|
||||
|---|---|---:|---:|---|---|---|
|
||||
| `ty6aQD9O0LnTvg` | `why_breaks` | 0 | 12 | `60` | Settlement trace still carries `customer_settlement` units; evidence years include 2023/2025/2026/2030; evidence account context contains `60`, `68.02`, `19.04` | low |
|
||||
| `-PdAdyMXYlf23K` | `what_is_it_grounded_on` | 0 | 12 | `60` | Same admissibility issue pattern as above with weak mapping admitted | low |
|
||||
| `4D6ALjsjEDHlL1` | `which_chains_are_complete_vs_incomplete` | 24 | 12 | empty | Live match exists, but weak mapping count remains high and evidence years include outlier (`2086`) | medium |
|
||||
| `8zDUwtS3MOHUYQ` | `prove_or_guess` | 24 | 12 | empty | Live match exists, but same weak-source pattern persists | medium |
|
||||
| `kFr2noz4jZ801u` | `why_breaks` | 24 | 12 | empty | Month-close interpretation with broad account contexts mixed into evidence set | medium |
|
||||
| `YcYGBW0Fqpd3Au` | `prove_or_guess` | 24 | 12 | empty | Similar period-close pattern; admissibility gate still permissive | medium |
|
||||
|
||||
## Specific Acceptance Checks
|
||||
|
||||
1. `matched_rows = 0` should prevent live evidence from strengthening claims.
|
||||
- Result: **not satisfied** (see `ty6aQD9O0LnTvg`, `-PdAdyMXYlf23K`).
|
||||
|
||||
2. Weak mapping should remain limitation-only, not claim-supporting evidence.
|
||||
- Result: **not satisfied** (weak-mapped refs still present in evidence blocks).
|
||||
|
||||
3. Cross-domain contamination should be blocked for settlement claims.
|
||||
- Result: **not satisfied** (VAT accounts `68.02/19.04` appear in settlement-oriented hard-fail trace context).
|
||||
|
||||
## Audit Artifacts
|
||||
|
||||
- `audit_artifacts/live_calls/wave16_export_debug_tail_fix_live_inventory.json`
|
||||
- `audit_artifacts/live_calls/hard_fail_trace_ty6aQD9O0LnTvg.md`
|
||||
- `audit_artifacts/raw_traces/1.txt`
|
||||
- `audit_artifacts/raw_traces/2.txt`
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
# 7D - control_question_trace_matrix
|
||||
|
||||
## Core 8 Matrix (Filled)
|
||||
|
||||
| Case ID | Mapped source case | Trace ID | Route selected | Snapshot sources used | Live calls used | Primary interpretation | Evidence basis | Claim status | Answer type | Verification |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| Q1 | `q01` (payment 55,200 tail) | `pz7NdUwSCPV_JL` | `hybrid_store_plus_live` | `problemCases,keyFields,docs` | not explicit in this export | `customer_settlement` | candidate evidence: 8; problem units: 8 | `partial_coverage` | `why_breaks` | partially verified (temporal anchor drift) |
|
||||
| Q2 | `q02` (advance offset 276,873.60) | `HIQhphOlB4zfX_` | `hybrid_store_plus_live` | `problemCases,keyFields,docs` | not explicit in this export | `customer_settlement` | candidate evidence: 2; problem units: 1 | `partial_coverage` | `prove_or_guess` | partially verified (polarity risk) |
|
||||
| Q3 | `q03` (40,860 / 20,000 semantics) | `mMgTQT2ujRmX6F` | `hybrid_store_plus_live` | `keyFields,journals,docs` | not explicit in this export | `bank_settlement` | candidate evidence: 8; problem units: 8 | `partial_coverage` | `prove_or_guess` | partially verified (classification instability) |
|
||||
| Q4 | `q11` (VAT invoice 233.33 chain) | `vu46dXSfvmn6hf` | `store_canonical` | `ndsRegisters,keyFields,docs` | no | `vat_flow` | candidate evidence: 6; problem units: 6 | `partial_coverage` | `why_breaks` | verified |
|
||||
| Q5 | `q13` (July purchases with partial VAT contour) | `0Q3E5aD5mJP1d7` | `batch_refresh_then_store` | not locked by domain card | unclear | `bank_settlement` (expected VAT) | candidate evidence: 5; problem units: 5 | `factual_with_explanation` | `why_breaks` | not verified (wrong domain) |
|
||||
| Q6 | `q17` (month-close indirect costs tail) | `NDst4BruRfYAB3` | `hybrid_store_plus_live` | `problemCases,docs,journals,keyFields` | not explicit in this export | `period_close` | candidate evidence: 8; problem units: 8 | `partial_coverage` | `prove_or_guess` | verified |
|
||||
| Q7 | `q18` (RBP stale tail) | `UG5L7JqS3cyXU2` | `store_canonical` | `docs,journals,keyFields` | no | `period_close` | candidate evidence: 6; problem units: 6 | `partial_coverage` | `what_is_it_grounded_on` | verified |
|
||||
| Q8 | `q20` (limitation honesty after month-end) | `4F7HdHzqV2v1Ir` | `hybrid_store_plus_live` | `problemCases,docs,journals,keyFields` | not explicit in this export | `period_close` | candidate evidence: 8; problem units: 8 | `partial_coverage` | `prove_or_guess` | partially verified |
|
||||
|
||||
## Additional Hard-Fail Supporting Trace
|
||||
|
||||
- `ty6aQD9O0LnTvg` (Wave 16 export debug):
|
||||
- `time_scope = 2023-07-06` for a July 2020 settlement scenario.
|
||||
- `live_mcp.matched_rows = 0`, `returned_rows = 12`.
|
||||
- problem-unit lifecycle domain: `customer_settlement:9`.
|
||||
- evidence refs include out-of-window years (2023/2025/2026/2030).
|
||||
|
||||
## Source Artifacts
|
||||
|
||||
- `audit_artifacts/raw_traces/wave15_chat20_case_matrix_updated.md`
|
||||
- `audit_artifacts/raw_traces/wave15_core_cases_q01_q02_q11_q17_q18_q20.json`
|
||||
- `audit_artifacts/debug_payloads/wave15_*.debug.json`
|
||||
- `audit_artifacts/debug_payloads/wave16_export_ty6aQD9O0LnTvg.debug.json`
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
# 7E - structural_gap_register
|
||||
|
||||
## Purpose
|
||||
|
||||
Реестр structural gaps между декларируемой архитектурой и фактическим runtime.
|
||||
|
||||
## Gap Register
|
||||
|
||||
| Gap ID | Gap Title | Description | Severity | Evidence | Affected Steps | Recommended Minimal Correction | Status |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| GAP-01 | Mandatory proof acquisition step missing or weak | TBD | blocker | TBD | TBD | TBD | open |
|
||||
| GAP-02 | Early interpretation before sufficient facts | TBD | high | TBD | TBD | TBD | open |
|
||||
| GAP-03 | Weak/inadmissible evidence enters grounded answer | TBD | high | TBD | TBD | TBD | open |
|
||||
| GAP-04 | Snapshot completeness mismatch for control questions | TBD | high | TBD | TBD | TBD | open |
|
||||
| GAP-05 | MCP/live acts as weak enrichment not verification | TBD | medium | TBD | TBD | TBD | open |
|
||||
|
||||
## Severity Scale
|
||||
|
||||
- `blocker`
|
||||
- `high`
|
||||
- `medium`
|
||||
|
||||
## Notes
|
||||
|
||||
Каждая строка должна иметь конкретные trace/code ссылки.
|
||||
|
|
@ -0,0 +1,20 @@
|
|||
# 7F - instrumentation_notes
|
||||
|
||||
## Instrumentation Change Log (This Audit)
|
||||
|
||||
| Change ID | File/Module | What added | Why | Runtime risk | Revert plan | Status |
|
||||
|---|---|---|---|---|---|---|
|
||||
| INST-00 | runtime code | no runtime instrumentation code added | audit was evidence-first from existing traces/exports | none | n/a | completed |
|
||||
| INST-01 | audit artifacts only | extraction/packaging of existing debug payloads and trace summaries into `audit_artifacts/` | provide process-log-grade proof pack | none (offline processing) | delete audit artifacts if not needed | completed |
|
||||
|
||||
## Captured Through Existing Runtime Exports
|
||||
|
||||
- route selection and route status per fragment
|
||||
- normalized fragments, time scope, business scope
|
||||
- retrieval summary and problem-unit stats
|
||||
- live MCP summary (`fetched_rows`, `matched_rows`, `returned_rows`, `account_scope`)
|
||||
- answer structure blocks with evidence and limitations
|
||||
|
||||
## Note
|
||||
|
||||
This audit intentionally avoided changing runtime behavior. All conclusions are based on already produced runtime outputs and code-path inspection.
|
||||
|
|
@ -0,0 +1,25 @@
|
|||
# audit_artifacts
|
||||
|
||||
Evidence pack for Stage 4 runtime ground-truth audit.
|
||||
|
||||
## Subfolders
|
||||
|
||||
- `raw_traces/`
|
||||
- copied raw exports (`1.txt`, `2.txt`), Wave15 raw chat export, case matrix
|
||||
- extracted subset: `wave15_core_cases_q01_q02_q11_q17_q18_q20.json`
|
||||
- `debug_payloads/`
|
||||
- per-case debug payload JSON (Wave15 core + Wave16 export traces)
|
||||
- `dialogs/`
|
||||
- `wave15_core_control_dialogs.md`
|
||||
- `live_calls/`
|
||||
- `wave16_export_debug_tail_fix_live_inventory.json`
|
||||
- `hard_fail_trace_ty6aQD9O0LnTvg.md`
|
||||
- `snapshot_inspection/`
|
||||
- runtime snapshot inventory and monthly NDJSON inventory
|
||||
- runtime wiring note
|
||||
- `diagrams/`
|
||||
- reserved for optional visual diagrams
|
||||
|
||||
## Rule
|
||||
|
||||
Every artifact must remain traceable to `case_id` and/or `trace_id`.
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,175 @@
|
|||
# Core Control Dialogs (Wave 15)
|
||||
|
||||
## q01 | trace: pz7NdUwSCPV_JL
|
||||
|
||||
### user
|
||||
Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться долг или незакрытый хвост?
|
||||
|
||||
### assistant
|
||||
Коротко: Проблема в цепочке НДС подтверждается частично. Что сломано:
|
||||
- По НДС переход от документа к регистру и книге подтвержден не полностью; по текущей опоре подтверждение частичное, нужна отдельная проверка расчетной связки. Почему это похоже на проблему:
|
||||
- Сигнал проблемы есть, но механизм подтвержден не полностью. На чем это основано:
|
||||
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
|
||||
- Проверены связанные документы и проводки по 6 источникам.
|
||||
- Есть связка между основным выводом и подтверждающими записями.
|
||||
- Опора есть, но достаточна только для предварительного вывода.
|
||||
- Подтверждено по требованиям: R1.
|
||||
- В опоре использованы якоря вопроса: 2019, period:2019. Что проверить первым:
|
||||
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
|
||||
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
|
||||
- Якоря из вопроса без прямого подтверждения: договор № 01/19-ПТ, 09.01.2019, 09.01, 55 200.
|
||||
- Связка между источниками подтверждена частично.
|
||||
- Текущая выборка не подтвердила целевой механизм домена в явном виде; вывод ограничен.
|
||||
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
|
||||
- Вывод сделан по snapshot и может не включать часть цепочки.
|
||||
- (account_55),.
|
||||
|
||||
- reply_type: partial_coverage
|
||||
- created_at: 2026-03-28T10:33:41.201Z
|
||||
|
||||
## q02 | trace: HIQhphOlB4zfX_
|
||||
|
||||
### user
|
||||
Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июля, или на 62.02 что-то осталось висеть?
|
||||
|
||||
### assistant
|
||||
Коротко: Вывод разделен на доказанную часть и гипотезу. Что сломано:
|
||||
- Оплата отражена, но ожидаемое закрытие расчета не подтверждено; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
|
||||
- Отдельно показано, что уже подтверждено, а что пока остается гипотезой.
|
||||
- Переход от оплаты к закрытию расчета не подтвержден.
|
||||
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
|
||||
- Сила вывода оценена по прямой опоре, а не по догадкам.
|
||||
- Основание разделено на подтвержденную часть и зону гипотез.
|
||||
- Вывод опирается на 2 подтвержденных наблюдений в текущем срезе.
|
||||
- Проверены связанные документы и проводки по 1 источникам.
|
||||
- Есть связка между основным выводом и подтверждающими записями.
|
||||
- Опора частичная: часть требований покрыта не полностью.
|
||||
- Подтверждено по требованиям: R1. Что проверить первым:
|
||||
- Первым действием отделите документально подтвержденные факты от гипотез.
|
||||
- Отдельно отметьте, что доказано документами и проводками, а что остается гипотезой.
|
||||
- Для доказательства проверьте связку платеж -> расчетный документ -> регистр расчетов -> 60/62/76.
|
||||
- Проверьте договор и объект расчетов по платежу/зачету.
|
||||
- Сверьте регистр расчетов и привязку платежа к закрывающему документу по 60/62. Ограничения:
|
||||
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
|
||||
- Якоря из вопроса без прямого подтверждения: 07.07.20, 07.07, 276 873,60, 62.02.
|
||||
- Связка между источниками подтверждена частично.
|
||||
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
|
||||
- Вывод сделан по snapshot и может не включать часть цепочки.
|
||||
- (account_13, account_62.02),.
|
||||
|
||||
- reply_type: partial_coverage
|
||||
- created_at: 2026-03-28T10:33:41.412Z
|
||||
|
||||
## q11 | trace: vu46dXSfvmn6hf
|
||||
|
||||
### user
|
||||
31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга покупок могла бы остаться пустой?
|
||||
|
||||
### assistant
|
||||
Коротко: Проблема подтверждается частично на текущей опоре. Что сломано:
|
||||
- Ожидаемый переход в учетной цепочке не подтвержден; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
|
||||
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
|
||||
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
|
||||
- Проверены связанные документы и проводки по 6 источникам.
|
||||
- Есть связка между основным выводом и подтверждающими записями.
|
||||
- Опора есть, но достаточна только для предварительного вывода.
|
||||
- Подтверждено по требованиям: R1, R2. Что проверить первым:
|
||||
- Проверьте связку: исходный документ -> запись регистра НДС -> запись в книге.
|
||||
- Сверьте счет-фактуру и момент отражения вычета в нужном периоде. Ограничения:
|
||||
- Якоря из вопроса без прямого подтверждения: 1 166,67, 233,33.
|
||||
- Связка между источниками подтверждена частично.
|
||||
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
|
||||
- Вывод сделан по snapshot и может не включать часть цепочки.
|
||||
- Canonical output ограничен доменным runtime-контрактом.
|
||||
|
||||
- reply_type: partial_coverage
|
||||
- created_at: 2026-03-28T10:33:42.818Z
|
||||
|
||||
## q17 | trace: NDst4BruRfYAB3
|
||||
|
||||
### user
|
||||
31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и другие. Всё ли это реально закрылось в нужный контур, или после июля могли остаться зависшие косвенные расходы?
|
||||
|
||||
### assistant
|
||||
Коротко: Вывод разделен на доказанную часть и гипотезу. Что сломано:
|
||||
- close_contradicted; close_completed; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
|
||||
- Отдельно показано, что уже подтверждено, а что пока остается гипотезой.
|
||||
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
|
||||
- Сила вывода оценена по прямой опоре, а не по догадкам.
|
||||
- Основание разделено на подтвержденную часть и зону гипотез.
|
||||
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
|
||||
- Проверены связанные документы и проводки по 6 источникам.
|
||||
- Есть связка между основным выводом и подтверждающими записями.
|
||||
- Опора есть, но достаточна только для предварительного вывода.
|
||||
- Подтверждено по требованиям: R1, R2. Что проверить первым:
|
||||
- Первым действием отделите документально подтвержденные факты от гипотез.
|
||||
- Разделите доказанные и предположительные участки в цепочке закрытия месяца.
|
||||
- Проверьте подтверждение: операция закрытия -> распределение -> остатки по 20/25/26/44. Ограничения:
|
||||
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
|
||||
- Якоря из вопроса без прямого подтверждения: 148 050, 27 954,50, 5 786,63, 5 000.
|
||||
- Связка между источниками подтверждена частично.
|
||||
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
|
||||
- Вывод сделан по snapshot и может не включать часть цепочки.
|
||||
|
||||
- reply_type: partial_coverage
|
||||
- created_at: 2026-03-28T10:33:43.820Z
|
||||
|
||||
## q18 | trace: UG5L7JqS3cyXU2
|
||||
|
||||
### user
|
||||
31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБП к концу июля всё ещё живёт дольше ожидаемого?
|
||||
|
||||
### assistant
|
||||
Коротко: Ниже перечислены основания вывода по данным учета. Что сломано:
|
||||
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
|
||||
- Фокус ответа смещен в доказательные источники, а не в общий narrative.
|
||||
- Ожидаемая цепочка списания выглядит незавершенной.
|
||||
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
|
||||
- В этом ответе в приоритете показаны именно основания вывода.
|
||||
- Основание вывода перечислено по подтвержденным документам, регистрам и проводкам.
|
||||
- Вывод опирается на 10 подтвержденных наблюдений в текущем срезе.
|
||||
- Проверены связанные документы и проводки по 6 источникам.
|
||||
- Есть связка между основным выводом и подтверждающими записями.
|
||||
- Опора есть, но достаточна только для предварительного вывода.
|
||||
- Подтверждено по требованиям: R1, R2. Что проверить первым:
|
||||
- Сначала перечислите опорные документы и регистры, затем подтверждающие проводки.
|
||||
- Перечислите основание: операция закрытия, база распределения, проводки по затратам, остатки после закрытия. Ограничения:
|
||||
- В основание включены только подтвержденные источники; неподтвержденные вынесены в ограничения.
|
||||
- Якоря из вопроса без прямого подтверждения: 5 000.
|
||||
- Связка между источниками подтверждена частично.
|
||||
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
|
||||
- Вывод сделан по snapshot и может не включать часть цепочки.
|
||||
- Canonical output ограничен доменным runtime-контрактом.
|
||||
|
||||
- reply_type: partial_coverage
|
||||
- created_at: 2026-03-28T10:33:43.983Z
|
||||
|
||||
## q20 | trace: 4F7HdHzqV2v1Ir
|
||||
|
||||
### user
|
||||
После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых результатов — что у нас больше похоже на реальную проблему: незакрытый затратный хвост, stale RBP или просто нормальный остаток, который ассистент не должен объявлять багом?
|
||||
|
||||
### assistant
|
||||
Коротко: Вывод разделен на доказанную часть и гипотезу. Что сломано:
|
||||
- Цепочка затрат и закрытия месяца подтверждена только частично; подтверждение пока частичное, вывод ограничен. Почему это похоже на проблему:
|
||||
- Отдельно показано, что уже подтверждено, а что пока остается гипотезой.
|
||||
- Ожидаемая цепочка списания выглядит незавершенной.
|
||||
- Часть ожидаемой цепочки подтверждена, но ключевой переход закрытия не подтвержден. На чем это основано:
|
||||
- Сила вывода оценена по прямой опоре, а не по догадкам.
|
||||
- Основание разделено на подтвержденную часть и зону гипотез.
|
||||
- Вывод опирается на 8 подтвержденных наблюдений в текущем срезе.
|
||||
- Проверены связанные документы и проводки по 6 источникам.
|
||||
- Есть связка между основным выводом и подтверждающими записями.
|
||||
- Опора есть, но достаточна только для предварительного вывода.
|
||||
- Подтверждено по требованиям: R1. Что проверить первым:
|
||||
- Первым действием отделите документально подтвержденные факты от гипотез.
|
||||
- Разделите доказанные и предположительные участки в цепочке закрытия месяца.
|
||||
- Проверьте подтверждение: операция закрытия -> распределение -> остатки по 20/25/26/44. Ограничения:
|
||||
- Для формата «доказано или гипотеза» все недоказанные части отделены в ограничения.
|
||||
- Связка между источниками подтверждена частично.
|
||||
- Надежность problem-сигнала низкая, поэтому вывод ограничен.
|
||||
- Вывод сделан по snapshot и может не включать часть цепочки.
|
||||
|
||||
- reply_type: partial_coverage
|
||||
- created_at: 2026-03-28T10:33:44.365Z
|
||||
|
||||
|
|
@ -0,0 +1,16 @@
|
|||
# Hard-Fail Trace Note
|
||||
|
||||
trace_id: ty6aQD9O0LnTvg
|
||||
question_type_class: why_breaks
|
||||
route: hybrid_store_plus_live
|
||||
business_scope: generic_accounting
|
||||
time_scope: 2023-07-06
|
||||
account_hints: 60
|
||||
live_mcp.matched_rows: 0
|
||||
live_mcp.returned_rows: 12
|
||||
problem_unit_lifecycle_domain_distribution: customer_settlement:9
|
||||
uncertainty.limitations: Problem units remain weak-confidence; conclusions are intentionally limited. | Source mapping is weak for part of the evidence. | в” snapshot 2020 (read-only), live | Live probe использует ограниченный выборочный read-only запрос к 1С.
|
||||
evidence_source_refs_sample:
|
||||
- evidence_source_ref_v1|unknown|document_%D1%81%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5%D1%81%D1%80%D0%B0%D1%81%D1%87%D0%B5%D1%82%D0%BD%D0%BE%D0%B3%D0%BE%D1%81%D1%87%D0%B5%D1%82%D0%B0|b42999dd-b08e-11ea-a2db-00155d012600|2020-06-16t12%3A00%3A00
|
||||
- evidence_source_ref_v1|unknown|mcplivemovement|hybrid_store_plus_live-mcp-1-2030-08-03t12%3A00%3A00z|2030-08-03t12%3A00%3A00z
|
||||
- evidence_source_ref_v1|unknown|mcplivemovement|hybrid_store_plus_live-mcp-2-2026-03-31t00%3A00%3A00z|2026-03-31t00%3A00%3A00z
|
||||
|
|
@ -0,0 +1,237 @@
|
|||
[
|
||||
{
|
||||
"trace_id": "4D6ALjsjEDHlL1",
|
||||
"question_type_class": "which_chains_are_complete_vs_incomplete",
|
||||
"route": "hybrid_store_plus_live",
|
||||
"business_scope": "generic_accounting",
|
||||
"time_scope": "2023-07-13, 2023-07-15",
|
||||
"account_hints": [
|
||||
|
||||
],
|
||||
"live_mcp": {
|
||||
"status": "ok",
|
||||
"fetched_rows": 24,
|
||||
"matched_rows": 24,
|
||||
"returned_rows": 12,
|
||||
"account_scope": [
|
||||
|
||||
]
|
||||
},
|
||||
"candidate_evidence_count": 16,
|
||||
"problem_units_count": 16,
|
||||
"problem_unit_lifecycle_domain_distribution": {
|
||||
"vat_flow": 16
|
||||
},
|
||||
"weak_source_mapping_evidence_count": 16,
|
||||
"evidence_account_context_detected": [
|
||||
"19",
|
||||
"68",
|
||||
"68.02",
|
||||
"19.04"
|
||||
],
|
||||
"evidence_years_detected": [
|
||||
"2020",
|
||||
"2086"
|
||||
]
|
||||
},
|
||||
{
|
||||
"trace_id": "-PdAdyMXYlf23K",
|
||||
"question_type_class": "what_is_it_grounded_on",
|
||||
"route": "hybrid_store_plus_live",
|
||||
"business_scope": "generic_accounting",
|
||||
"time_scope": "Рюль 2020",
|
||||
"account_hints": [
|
||||
"60",
|
||||
"68.02"
|
||||
],
|
||||
"live_mcp": {
|
||||
"status": "ok",
|
||||
"fetched_rows": 24,
|
||||
"matched_rows": 0,
|
||||
"returned_rows": 12,
|
||||
"account_scope": [
|
||||
"60"
|
||||
]
|
||||
},
|
||||
"candidate_evidence_count": 10,
|
||||
"problem_units_count": 9,
|
||||
"problem_unit_lifecycle_domain_distribution": {
|
||||
"customer_settlement": 9
|
||||
},
|
||||
"weak_source_mapping_evidence_count": 10,
|
||||
"evidence_account_context_detected": [
|
||||
"60",
|
||||
"68.02",
|
||||
"19.04"
|
||||
],
|
||||
"evidence_years_detected": [
|
||||
"2020",
|
||||
"2030",
|
||||
"2026",
|
||||
"2025",
|
||||
"2023"
|
||||
]
|
||||
},
|
||||
{
|
||||
"trace_id": "kFr2noz4jZ801u",
|
||||
"question_type_class": "why_breaks",
|
||||
"route": "hybrid_store_plus_live",
|
||||
"business_scope": "generic_accounting",
|
||||
"time_scope": "2023-07",
|
||||
"account_hints": [
|
||||
"68.02"
|
||||
],
|
||||
"live_mcp": {
|
||||
"status": "ok",
|
||||
"fetched_rows": 24,
|
||||
"matched_rows": 24,
|
||||
"returned_rows": 12,
|
||||
"account_scope": [
|
||||
|
||||
]
|
||||
},
|
||||
"candidate_evidence_count": 16,
|
||||
"problem_units_count": 16,
|
||||
"problem_unit_lifecycle_domain_distribution": {
|
||||
"period_close": 16
|
||||
},
|
||||
"weak_source_mapping_evidence_count": 16,
|
||||
"evidence_account_context_detected": [
|
||||
"25",
|
||||
"20",
|
||||
"01",
|
||||
"19",
|
||||
"21",
|
||||
"23",
|
||||
"26",
|
||||
"28",
|
||||
"29",
|
||||
"02",
|
||||
"68",
|
||||
"08",
|
||||
"51",
|
||||
"68.02",
|
||||
"19.04"
|
||||
],
|
||||
"evidence_years_detected": [
|
||||
"2020"
|
||||
]
|
||||
},
|
||||
{
|
||||
"trace_id": "ty6aQD9O0LnTvg",
|
||||
"question_type_class": "why_breaks",
|
||||
"route": "hybrid_store_plus_live",
|
||||
"business_scope": "generic_accounting",
|
||||
"time_scope": "2023-07-06",
|
||||
"account_hints": [
|
||||
"60"
|
||||
],
|
||||
"live_mcp": {
|
||||
"status": "ok",
|
||||
"fetched_rows": 24,
|
||||
"matched_rows": 0,
|
||||
"returned_rows": 12,
|
||||
"account_scope": [
|
||||
"60"
|
||||
]
|
||||
},
|
||||
"candidate_evidence_count": 10,
|
||||
"problem_units_count": 9,
|
||||
"problem_unit_lifecycle_domain_distribution": {
|
||||
"customer_settlement": 9
|
||||
},
|
||||
"weak_source_mapping_evidence_count": 10,
|
||||
"evidence_account_context_detected": [
|
||||
"60",
|
||||
"68.02",
|
||||
"19.04"
|
||||
],
|
||||
"evidence_years_detected": [
|
||||
"2020",
|
||||
"2030",
|
||||
"2026",
|
||||
"2025",
|
||||
"2023"
|
||||
]
|
||||
},
|
||||
{
|
||||
"trace_id": "8zDUwtS3MOHUYQ",
|
||||
"question_type_class": "prove_or_guess",
|
||||
"route": "hybrid_store_plus_live",
|
||||
"business_scope": "generic_accounting",
|
||||
"time_scope": "2023-07-13",
|
||||
"account_hints": [
|
||||
|
||||
],
|
||||
"live_mcp": {
|
||||
"status": "ok",
|
||||
"fetched_rows": 24,
|
||||
"matched_rows": 24,
|
||||
"returned_rows": 12,
|
||||
"account_scope": [
|
||||
|
||||
]
|
||||
},
|
||||
"candidate_evidence_count": 16,
|
||||
"problem_units_count": 16,
|
||||
"problem_unit_lifecycle_domain_distribution": {
|
||||
"vat_flow": 16
|
||||
},
|
||||
"weak_source_mapping_evidence_count": 16,
|
||||
"evidence_account_context_detected": [
|
||||
"19",
|
||||
"68",
|
||||
"68.02",
|
||||
"19.04"
|
||||
],
|
||||
"evidence_years_detected": [
|
||||
"2020",
|
||||
"2086"
|
||||
]
|
||||
},
|
||||
{
|
||||
"trace_id": "YcYGBW0Fqpd3Au",
|
||||
"question_type_class": "prove_or_guess",
|
||||
"route": "hybrid_store_plus_live",
|
||||
"business_scope": "generic_accounting",
|
||||
"time_scope": "31 июля",
|
||||
"account_hints": [
|
||||
"68.02"
|
||||
],
|
||||
"live_mcp": {
|
||||
"status": "ok",
|
||||
"fetched_rows": 24,
|
||||
"matched_rows": 24,
|
||||
"returned_rows": 12,
|
||||
"account_scope": [
|
||||
|
||||
]
|
||||
},
|
||||
"candidate_evidence_count": 16,
|
||||
"problem_units_count": 16,
|
||||
"problem_unit_lifecycle_domain_distribution": {
|
||||
"period_close": 16
|
||||
},
|
||||
"weak_source_mapping_evidence_count": 16,
|
||||
"evidence_account_context_detected": [
|
||||
"25",
|
||||
"20",
|
||||
"01",
|
||||
"19",
|
||||
"21",
|
||||
"23",
|
||||
"26",
|
||||
"28",
|
||||
"29",
|
||||
"02",
|
||||
"68",
|
||||
"08",
|
||||
"51",
|
||||
"68.02",
|
||||
"19.04"
|
||||
],
|
||||
"evidence_years_detected": [
|
||||
"2020"
|
||||
]
|
||||
}
|
||||
]
|
||||
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,26 @@
|
|||
# Wave 15 Chat20 Case Matrix (Updated)
|
||||
|
||||
| case_id | question_short | expected_domain | actual_domain | expected_question_type | actual_question_type | company_anchors_present | company_anchors_used_in_answer | evidence_strength | answer_confidence_style | first_check_relevance | verdict | failure_reason_short |
|
||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
||||
| q01 | Почему 6 июля ушла оплата за мебель по договору № 01/19-ПТ от 09.01.2019 на 55 200, а к концу июля по этой покупке мог остаться... | settlements_60_62 | settlements_60_62 | why_breaks | why_breaks | true | true | weak | mixed | true | SOFT_PASS | generic_answer |
|
||||
| q02 | Оплата по счёту № 4 от 07.07.20 на 276 873,60 пришла 13 июля. Зачёлся ли этот аванс покупателя корректно в реализации от 15 июл... | settlements_60_62 | settlements_60_62 | prove_or_guess | prove_or_guess | true | true | weak | mixed | true | SOFT_PASS | generic_answer |
|
||||
| q03 | По договору № 1-ПМ/2020 от 05.06.2020 в июле пришло ещё 40 860 27 июля и 20 000 30 июля. Это уже закрытие дебиторки после реали... | settlements_60_62 | settlements_60_62 | prove_or_guess | prove_or_guess | true | true | strong | mixed | true | SOFT_PASS | generic_answer |
|
||||
| q04 | Почему по одному и тому же мебельному контуру в июле есть и поступления денег от покупателя, и зачёт аванса, но 62.01/62.02 всё... | settlements_60_62 | settlements_60_62 | why_breaks | why_breaks | true | true | weak | mixed | true | SOFT_PASS | generic_answer |
|
||||
| q05 | Если по договору № 1-ПМ/2020 в июле было несколько оплат и одна крупная реализация, где именно ассистент видит разрыв: в догово... | settlements_60_62 | settlements_60_62 | where_break_is | where_break_is | true | true | strong | mixed | true | SOFT_PASS | generic_answer |
|
||||
| q06 | Есть ли в июльском срезе ситуация, где деньги уже пришли, но закрытие расчётов не подтверждено тем документом, которым должно б... | settlements_60_62 | settlements_60_62 | prove_or_guess | prove_or_guess | false | false | strong | mixed | false | FAIL | wrong_first_check |
|
||||
| q07 | Почему по поставщику мебель оплачена 6 июля, а ассистент может считать, что обязательство не закрыто: не тот договор, не тот об... | settlements_60_62 | settlements_60_62 | why_breaks | why_breaks | false | false | strong | mixed | true | SOFT_PASS | generic_answer |
|
||||
| q08 | Если смотреть только июль, какие именно расчётные цепочки по мебели выглядят завершёнными, а какие — нет? | settlements_60_62 | settlements_60_62 | which_chains_are_complete_vs_incomplete | which_chains_are_complete_vs_incomplete | false | false | strong | limited | true | SOFT_PASS | generic_answer |
|
||||
| q09 | 13 июля проведено поступление товаров, а 15 июля — реализация этих же мебельных позиций. НДС-цепочка по этим движениям у нас по... | vat_document_register_book | vat_document_register_book | which_chains_are_complete_vs_incomplete | which_chains_are_complete_vs_incomplete | false | false | strong | limited | true | PASS | none |
|
||||
| q10 | По оплате от 13 июля на 276 873,60 в тексте явно указан НДС 20% = 46 145,60. Ассистент может доказать, что НДС по этой продаже ... | vat_document_register_book | settlements_60_62 | prove_or_guess | prove_or_guess | true | true | strong | mixed | true | FAIL | wrong_domain |
|
||||
| q11 | 31 июля есть услуги связи на 1 166,67 + НДС 233,33 и отдельно полученный счёт-фактура на 233,33. Почему по такому кейсу книга п... | vat_document_register_book | vat_document_register_book | why_breaks | why_breaks | true | true | strong | mixed | true | PASS | none |
|
||||
| q12 | Связан ли полученный 31 июля счёт-фактура с документом услуг связи так, чтобы НДС по нему можно было принять к вычету в июле, и... | vat_document_register_book | vat_document_register_book | prove_or_guess | which_chains_are_complete_vs_incomplete | false | false | strong | limited | true | SOFT_PASS | wrong_question_type |
|
||||
| q13 | Есть ли у нас в июльском срезе покупки, по которым товар/услуга есть, а полученного счёта-фактуры или налогового эффекта не видно? | vat_document_register_book | settlements_60_62 | why_breaks | why_breaks | false | false | strong | mixed | false | FAIL | wrong_domain, wrong_first_check |
|
||||
| q14 | Если ассистент говорит, что НДС по связи за июль в порядке, на чём это должно быть основано: на документе услуг, на счёте-факту... | vat_document_register_book | vat_document_register_book | what_is_it_grounded_on | what_is_it_grounded_on | false | false | strong | mixed | true | PASS | none |
|
||||
| q15 | Почему по одной июльской покупке НДС может попасть в контур, а по другой — нет, даже если обе операции выглядят проведёнными? | vat_document_register_book | vat_document_register_book | why_breaks | why_breaks | false | false | strong | mixed | true | PASS | none |
|
||||
| q16 | Есть ли в июльских движениях ситуация, где НДС отражён частично: документ и счёт-фактура есть, но запись книги или tax entry не... | vat_document_register_book | vat_document_register_book | which_chains_are_complete_vs_incomplete | which_chains_are_complete_vs_incomplete | false | false | strong | limited | true | PASS | none |
|
||||
| q17 | 31 июля у нас прошло “Закрытие счетов косвенных расходов”, и там есть крупные суммы — 148 050, 27 954,50, 5 786,63, 5 000 и дру... | month_close_costs_20_44 | month_close_costs_20_44 | prove_or_guess | prove_or_guess | true | true | strong | mixed | true | PASS | none |
|
||||
| q18 | 31 июля прошло “Списание РБП за Июль 2020 г.”, в том числе на 5 000 и ещё несколько сумм. Есть ли в базе признаки, что часть РБ... | month_close_costs_20_44 | month_close_costs_20_44 | what_is_it_grounded_on | what_is_it_grounded_on | true | true | strong | mixed | true | PASS | none |
|
||||
| q19 | 31 июля начислена амортизация тремя суммами — 2 471,52, 2 465,28 и 849,83. Это похоже на полное начисление по всем нужным объек... | month_close_costs_20_44 | month_close_costs_20_44 | why_breaks | why_breaks | true | true | strong | mixed | true | PASS | none |
|
||||
| q20 | После всех июльских регламентных операций — амортизация, списание РБП, закрытие косвенных расходов, определение финансовых резу... | month_close_costs_20_44 | month_close_costs_20_44 | prove_or_guess | prove_or_guess | false | false | strong | mixed | true | PASS | none |
|
||||
|
||||
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -0,0 +1,53 @@
|
|||
{
|
||||
"total_bytes": 7059009054,
|
||||
"files": [
|
||||
{
|
||||
"file": "snapshot_2020-01.ndjson",
|
||||
"bytes": 580029464
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-02.ndjson",
|
||||
"bytes": 581189065
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-03.ndjson",
|
||||
"bytes": 583880766
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-04.ndjson",
|
||||
"bytes": 584715096
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-05.ndjson",
|
||||
"bytes": 585503134
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-06.ndjson",
|
||||
"bytes": 588644783
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-07.ndjson",
|
||||
"bytes": 589576497
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-08.ndjson",
|
||||
"bytes": 590584465
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-09.ndjson",
|
||||
"bytes": 592120603
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-10.ndjson",
|
||||
"bytes": 592460410
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-11.ndjson",
|
||||
"bytes": 593521104
|
||||
},
|
||||
{
|
||||
"file": "snapshot_2020-12.ndjson",
|
||||
"bytes": 596783667
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -0,0 +1,10 @@
|
|||
# Runtime Snapshot Wiring (Code Evidence)
|
||||
|
||||
- backend/src/config.ts: `ARCH_EXPORT_2020_DIR` points to `docs/ARCH/2020экспорт`.
|
||||
- backend/src/services/assistantDataLayer.ts: `ensureData()` reads:
|
||||
- 09_samples_key_fields_Recorder_Ref_Supplier_Buyer_Responsible.json
|
||||
- 03_snapshot_fragment_problem_cases.json
|
||||
- 07_samples_DocumentJournals.json
|
||||
- 08_samples_NDS_registers.json
|
||||
- 04/05/06 samples for payment/sales/purchase docs
|
||||
- No direct code reference found to `docs/ARCH/2020_monthly_company_asof_full` in backend/src runtime path.
|
||||
|
|
@ -0,0 +1,37 @@
|
|||
[
|
||||
{
|
||||
"file": "03_snapshot_fragment_problem_cases.json",
|
||||
"bytes": 302520,
|
||||
"records": 80
|
||||
},
|
||||
{
|
||||
"file": "04_samples_SpisanieSRaschetnogoScheta.json",
|
||||
"bytes": 196178,
|
||||
"records": 27
|
||||
},
|
||||
{
|
||||
"file": "05_samples_RealizaciyaTovarovUslug.json",
|
||||
"bytes": 132032,
|
||||
"records": 5
|
||||
},
|
||||
{
|
||||
"file": "06_samples_PostuplenieTovarovUslug.json",
|
||||
"bytes": 181409,
|
||||
"records": 10
|
||||
},
|
||||
{
|
||||
"file": "07_samples_DocumentJournals.json",
|
||||
"bytes": 292931,
|
||||
"records": 80
|
||||
},
|
||||
{
|
||||
"file": "08_samples_NDS_registers.json",
|
||||
"bytes": 291547,
|
||||
"records": 80
|
||||
},
|
||||
{
|
||||
"file": "09_samples_key_fields_Recorder_Ref_Supplier_Buyer_Responsible.json",
|
||||
"bytes": 511133,
|
||||
"records": 140
|
||||
}
|
||||
]
|
||||
|
|
@ -0,0 +1,567 @@
|
|||
execution-pack на закрытие трёх blocker-gap внутри текущего Stage 4.md
|
||||
|
||||
---
|
||||
|
||||
# ТЗ для Codex
|
||||
|
||||
## Stage 4 Blocker Closure Execution Pack — GAP-01 / GAP-02 / GAP-03
|
||||
|
||||
### 1. Контекст
|
||||
|
||||
По итогам архитектурного аудита текущий runtime-контур квалифицирован как:
|
||||
|
||||
**`MIXED_RUNTIME_WITHOUT_MANDATORY_PROOF_LAYER`**
|
||||
|
||||
На этом основании Stage 4 **нельзя считать закрытым по живому reasoning-слою**, пока не сняты три blocker-gap’а:
|
||||
|
||||
* **GAP-01** — temporal anchor / period lock
|
||||
* **GAP-02** — domain polarity (supplier/customer, payable/receivable, 60/62)
|
||||
* **GAP-03** — evidence admissibility / недопустимое evidence в grounded answer
|
||||
|
||||
Важно: текущий execution-pack должен оставаться **в рамках Stage 4 P0-only**, без расширения domain scope, без graph/schema expansion, без втягивания Stage 5/6 как нового core path и без больших transport/routing refactor. Это соответствует зафиксированной рамке Stage 4.
|
||||
|
||||
---
|
||||
|
||||
## 2. Цель execution-pack
|
||||
|
||||
Не строить новую архитектуру и не делать “proof engine целиком”, а **снять три blocker-а**, из-за которых текущий ответный слой:
|
||||
|
||||
* искажает период,
|
||||
* путает бухгалтерскую полярность,
|
||||
* использует нерелевантное или слабое evidence как основание ответа.
|
||||
|
||||
Итогом должно стать:
|
||||
|
||||
1. корректное temporal grounding на company snapshot July 2020;
|
||||
2. корректная supplier/customer polarity на P0-доменах;
|
||||
3. жёсткий admissibility gate для evidence;
|
||||
4. trace-backed rerun, подтверждающий снятие blocker-gap’ов.
|
||||
|
||||
---
|
||||
|
||||
## 3. Scope
|
||||
|
||||
### Входит в scope
|
||||
|
||||
* только P0-домены:
|
||||
|
||||
* `settlements_60_62`
|
||||
* `vat_document_register_book`
|
||||
* `month_close_costs_20_44`
|
||||
* runtime logic:
|
||||
|
||||
* normalizer / router
|
||||
* domain profile selection
|
||||
* retrieval → live/snapshot evidence handoff
|
||||
* answer composer guards
|
||||
* debug/export traces
|
||||
* harness / regression / run artifacts
|
||||
|
||||
### Не входит в scope
|
||||
|
||||
* новые домены;
|
||||
* Stage 5 investigation state как отдельный слой;
|
||||
* новая онтология / graph expansion;
|
||||
* большой рефактор MCP toolkit;
|
||||
* новый orchestration layer;
|
||||
* попытка “вообще решить proof architecture”.
|
||||
|
||||
---
|
||||
|
||||
## 4. Рабочая гипотеза execution-pack
|
||||
|
||||
Нужно исходить из следующего:
|
||||
|
||||
### Сейчас система ломается не в одной точке, а в связке трёх искажений
|
||||
|
||||
1. **Неверное окно времени**
|
||||
Вопрос по July 2020 может уехать в другой год/период.
|
||||
|
||||
2. **Неверная бухгалтерская полярность**
|
||||
Supplier/60/case может резолвиться в customer/receivable semantics.
|
||||
|
||||
3. **Слабый допуск evidence**
|
||||
Live/snapshot сигналы с weak mapping, wrong period, wrong domain или `matched_rows = 0` всё ещё могут усиливать grounded answer.
|
||||
|
||||
Эти три искажения надо снимать **вместе**, а не как несвязанные косметические фиксы.
|
||||
|
||||
---
|
||||
|
||||
# 5. Subwave 1 — GAP-01 Temporal Hard Lock
|
||||
|
||||
## 5.1 Цель
|
||||
|
||||
Исключить ложную temporal интерпретацию company-specific July 2020 вопросов.
|
||||
|
||||
## 5.2 Что сделать
|
||||
|
||||
1. В normalizer/router добавить жёсткий `company_snapshot_temporal_lock`.
|
||||
2. Для контрольного корпуса July 2020:
|
||||
|
||||
* не допускать авто-подстановку текущего/дефолтного года;
|
||||
* не допускать relative reinterpretation;
|
||||
* если вопрос про “июльский срез” без дня — резолвить в fixed month window;
|
||||
* если указан конкретный день июля — резолвить в `2020-07-DD`.
|
||||
3. Ввести hard guard:
|
||||
|
||||
* если resolved time_scope уходит за допустимое окно company snapshot, grounded answer не должен собираться.
|
||||
4. В debug/export добавить обязательные поля:
|
||||
|
||||
* `raw_time_anchor`
|
||||
* `resolved_time_anchor`
|
||||
* `temporal_resolution_source`
|
||||
* `temporal_guard_applied`
|
||||
* `temporal_guard_outcome`
|
||||
|
||||
## 5.3 Acceptance
|
||||
|
||||
* Ни один контрольный вопрос July 2020 не должен уходить в 2023/2025/2026/2030.
|
||||
* Все temporal decisions должны быть видны в debug payload.
|
||||
* При temporal ambiguity ответ должен честно деградировать в limited answer.
|
||||
|
||||
---
|
||||
|
||||
# 6. Subwave 2 — GAP-02 Domain Polarity Guard
|
||||
|
||||
## 6.1 Цель
|
||||
|
||||
Убрать путаницу между:
|
||||
|
||||
* supplier vs customer
|
||||
* payable vs receivable
|
||||
* account 60 vs 62
|
||||
* settlements vs VAT vs month-close cross-contamination
|
||||
|
||||
## 6.2 Что сделать
|
||||
|
||||
1. Ввести `domain_polarity_guard` до retrieval ranking и до problem-unit / answer assembly.
|
||||
2. Минимальные правила:
|
||||
|
||||
* `supplier + account 60 + obligation/tail/not closed` → только supplier/payable semantics
|
||||
* `customer/buyer + 62 + advance/receivable` → только customer/receivable semantics
|
||||
* VAT не усиливает settlement answer без явного VAT claim
|
||||
* month-close не подменяет settlement по общим lifecycle hints
|
||||
3. Запретить mixed semantic profile для single-focus вопросов:
|
||||
|
||||
* `suppliers + customers` одновременно недопустимо, если вопрос не cross-entity by design
|
||||
4. Внутренне развести problem semantics хотя бы на уровне mapping:
|
||||
|
||||
* supplier cases
|
||||
* customer cases
|
||||
5. Если polarity не определена надёжно:
|
||||
|
||||
* answer не должен выдавать жёсткий механизм;
|
||||
* обязан уходить в limited mode с явным указанием неразрешённой полярности.
|
||||
|
||||
## 6.3 Acceptance
|
||||
|
||||
* Supplier/60 вопросы не должны порождать `customer_settlement`, `stale_receivable`, `receivable_closed`.
|
||||
* Customer/62 вопросы не должны уходить в supplier payable semantics.
|
||||
* Domain drift между settlement/VAT/month-close должен исчезнуть не только в answer text, но и в debug/runtime trace.
|
||||
|
||||
---
|
||||
|
||||
# 7. Subwave 3 — GAP-03 Evidence Admissibility Gate
|
||||
|
||||
## 7.1 Цель
|
||||
|
||||
Запретить попадание недопустимого evidence в grounded answer.
|
||||
|
||||
## 7.2 Что сделать
|
||||
|
||||
1. Ввести `evidence_admissibility_gate` между retrieval/live layers и answer composer.
|
||||
2. Evidence может считаться admissible только если одновременно выполнено:
|
||||
|
||||
* дата попадает в допустимое окно вопроса;
|
||||
* домен совпадает с текущим active domain;
|
||||
* account scope совместим с вопросом;
|
||||
* source mapping не weak/ambiguous как основание вывода;
|
||||
* `matched_rows > 0`, если live evidence заявляется как подтверждение.
|
||||
3. Развести evidence на категории:
|
||||
|
||||
* `hard_evidence`
|
||||
* `supporting_signal`
|
||||
* `inadmissible_noise`
|
||||
4. Ввести причины отбраковки:
|
||||
|
||||
* `wrong_period`
|
||||
* `wrong_domain`
|
||||
* `wrong_account_scope`
|
||||
* `weak_source_mapping`
|
||||
* `zero_live_match`
|
||||
* `future_dated_or_out_of_window`
|
||||
5. В debug/export показывать:
|
||||
|
||||
* общее число candidate evidence;
|
||||
* число admissible evidence;
|
||||
* число rejected evidence;
|
||||
* breakdown причин reject-а.
|
||||
6. Если admissible evidence недостаточно:
|
||||
|
||||
* grounded answer запрещён;
|
||||
* answer обязан уходить в `insufficient evidence / limited answer`.
|
||||
|
||||
## 7.3 Acceptance
|
||||
|
||||
* При `matched_rows = 0` live probe не может усиливать grounded answer.
|
||||
* VAT evidence не должно попадать в settlement answer.
|
||||
* Future-dated и out-of-window rows не должны использоваться как доказательная база.
|
||||
* weak mapping может фигурировать только как limitation, но не как опора основного вывода.
|
||||
|
||||
---
|
||||
|
||||
# 8. Интеграционный guard после трёх subwaves
|
||||
|
||||
После внедрения GAP-01/02/03 добавить общий runtime guard:
|
||||
|
||||
## `grounded_answer_eligibility_guard`
|
||||
|
||||
Grounded answer разрешён только если:
|
||||
|
||||
* temporal guard passed;
|
||||
* polarity guard passed;
|
||||
* admissible evidence count > 0;
|
||||
* no critical contradiction in domain/account scope.
|
||||
|
||||
Если хотя бы одно из условий не выполнено:
|
||||
|
||||
* answer переходит в `limited / insufficient evidence`;
|
||||
* debug/export явно показывает причину деградации.
|
||||
|
||||
---
|
||||
|
||||
# 9. Контрольный набор прогонов
|
||||
|
||||
Обязательный rerun — минимум по core-8 July 2020 вопросам, особенно по этим кейсам:
|
||||
|
||||
1. Оплата 55 200 по договору № 01/19-ПТ — почему долг мог остаться.
|
||||
2. Поступление 276 873,60 — зачёлся ли аванс 15 июля.
|
||||
3. Платежи 40 860 и 20 000 — аванс или закрытие дебиторки.
|
||||
4. Услуги связи + НДС 233,33 + счёт-фактура — полная ли НДС-цепочка.
|
||||
5. Есть ли покупки июля с неполным НДС-контуром.
|
||||
6. Закрытие косвенных расходов 31 июля — не осталось ли хвостов.
|
||||
7. Списание РБП — не живёт ли часть РБП дольше ожидаемого.
|
||||
8. После полного month-end — что реально проблема, а что нормальный остаток.
|
||||
|
||||
---
|
||||
|
||||
# 10. Метрики rerun
|
||||
|
||||
Добавить/обновить следующие метрики:
|
||||
|
||||
* `temporal_anchor_correctness_rate`
|
||||
* `domain_polarity_correctness_rate`
|
||||
* `evidence_admissibility_rate`
|
||||
* `grounded_answer_eligibility_correctness_rate`
|
||||
* `inadmissible_evidence_leak_rate`
|
||||
* `limited_answer_honesty_rate`
|
||||
|
||||
## Минимальный порог приёмки
|
||||
|
||||
* `temporal_anchor_correctness_rate = 1.00`
|
||||
* `domain_polarity_correctness_rate = 1.00` на core P0 cases
|
||||
* `inadmissible_evidence_leak_rate = 0`
|
||||
* `grounded_answer_eligibility_correctness_rate >= 0.95`
|
||||
* `limited_answer_honesty_rate >= 0.95`
|
||||
|
||||
---
|
||||
|
||||
# 11. Обязательные run-артефакты
|
||||
|
||||
В `llm_normalizer/docs/runs/<new_run_folder>` обязательно положить:
|
||||
|
||||
1. `README.md`
|
||||
2. `run_summary.json`
|
||||
3. `before_after_metrics.json`
|
||||
4. `control_case_matrix.md`
|
||||
5. `gap_closure_report.md`
|
||||
6. `chat_export_core8.md` или `чат.txt`
|
||||
7. `debug_payloads/`
|
||||
|
||||
* supplier 60 case
|
||||
* customer 62 case
|
||||
* VAT case
|
||||
* month-close / RBP case
|
||||
8. `live_call_inventory.json`
|
||||
9. `evidence_gate_breakdown.json`
|
||||
10. `temporal_resolution_audit.json`
|
||||
11. `polarity_guard_audit.json`
|
||||
|
||||
---
|
||||
|
||||
# 12. Формат финального вывода
|
||||
|
||||
В конце execution-pack нужно выдать короткий final verdict:
|
||||
|
||||
* `GAP-01 CLOSED / NOT CLOSED`
|
||||
* `GAP-02 CLOSED / NOT CLOSED`
|
||||
* `GAP-03 CLOSED / NOT CLOSED`
|
||||
|
||||
И общий статус:
|
||||
|
||||
* `BLOCKER_PACK_ACCEPTED`
|
||||
* или `BLOCKER_PACK_ACCEPTED_WITH_LIMITATIONS`
|
||||
* или `BLOCKER_PACK_NOT_ACCEPTED`
|
||||
|
||||
---
|
||||
|
||||
# 13. Что не делать
|
||||
|
||||
1. Не переходить в новую большую proof-архитектуру.
|
||||
2. Не добавлять question modes как отдельный новый слой в этой задаче.
|
||||
3. Не делать mechanism discriminator в полном объёме до снятия GAP-01/02/03.
|
||||
4. Не пытаться чинить generic wording вместо structural guards.
|
||||
5. Не закрывать pack на основании Chat-only корпуса без trace-backed live/debug rerun.
|
||||
|
||||
---
|
||||
|
||||
# 14. Ожидаемый результат
|
||||
|
||||
После выполнения этого execution-pack система должна:
|
||||
|
||||
* держать правильный July 2020 temporal scope;
|
||||
* не путать supplier/customer и 60/62;
|
||||
* не использовать нерелевантное evidence как основание ответа;
|
||||
* честно деградировать в limited mode, если доказательной базы недостаточно;
|
||||
* предоставить trace-backed подтверждение того, что три blocker-gap’а реально сняты.
|
||||
|
||||
---
|
||||
|
||||
Так, я заметил, там историю ты хочешь, короче, изолироваться. Может, я просто неправильно понял, но вот может быть, я просто сейчас немного с другой точки зрения как бы к этому придрался. Но ты вот пишешь, короче говоря, что если мы обсуждаем июль 2020, да, ну вот и задаем по этому месяцу этого года вопрос, то мы не должны вылезать за пределы этого, ну, вот этого месяца или этого, короче, какой-то даты, короче. Но смотри, на бухгалтерии это взаимосвязано, и из сущности там могут быть цепочки, но если контракт, например, там, я не знаю, три года, ну, то может делаться три года. Это может быть вообще открытый договор на пять лет, например, и пять лет там что-то делается, какие-то процессы происходят. Но, короче говоря, это могут быть взаимосвязи за пределами определенной даты. Это не противоречит вот этому твоему запрету, который ты пишешь, нех неверное окно времени, вопрос по этому июлю, он должен уехать в другой год-период. Ну, то есть, ну, он может иметь корни, короче, в далекое время, вот о чем я.
|
||||
|
||||
Да, ты прав. Это не должно быть жёстким запретом “не выходить за июль 2020 вообще”.
|
||||
|
||||
Тут надо различать **два разных слоя времени**:
|
||||
|
||||
**1. Главный период вопроса**
|
||||
Это то, про что пользователь спрашивает.
|
||||
Например: “что происходило в июле 2020” или “почему на конец июля остался хвост”.
|
||||
|
||||
**2. Контекстная причинно-следственная зона**
|
||||
Это всё, куда система имеет право сходить, чтобы объяснить ответ:
|
||||
|
||||
* договор мог начаться раньше;
|
||||
* аванс мог прийти раньше;
|
||||
* закрывающий документ мог появиться позже;
|
||||
* цепочка могла тянуться через несколько месяцев или лет.
|
||||
|
||||
То есть моя мысль была не “запретить выходить за месяц”, а вот такая:
|
||||
|
||||
## Что реально должно быть запрещено
|
||||
|
||||
Запрещено **тихо подменять основной период вопроса**.
|
||||
|
||||
Пример плохого поведения:
|
||||
пользователь спрашивает про июль 2020,
|
||||
а система вдруг делает вид, что основной ответ строится по 2023 или 2026, просто потому что туда уехал route или live probe.
|
||||
|
||||
Вот это нельзя.
|
||||
|
||||
## Что должно быть разрешено
|
||||
|
||||
Разрешено выходить за пределы июля 2020, если это нужно для восстановления цепочки, **но с жёсткими правилами**:
|
||||
|
||||
### 1. Июль 2020 остаётся главным окном ответа
|
||||
|
||||
То есть вопрос всё ещё про июль 2020, а не про “вообще всё, что связано с этим договором”.
|
||||
|
||||
### 2. Внешние периоды можно использовать только как:
|
||||
|
||||
* предысторию,
|
||||
* источник причины,
|
||||
* последствие,
|
||||
* подтверждение закрытия/незакрытия,
|
||||
* долгий lifecycle сущности.
|
||||
|
||||
### 3. Система обязана маркировать роль внешнего периода
|
||||
|
||||
Например:
|
||||
|
||||
* “договор открыт ранее, это предыстория”;
|
||||
* “оплата была раньше июля, поэтому это объясняет состояние на июль”;
|
||||
* “закрытие произошло после июля, поэтому на конец июля хвост ещё был нормален/ненормален”.
|
||||
|
||||
### 4. Нельзя, чтобы внешние данные захватывали ответ полностью
|
||||
|
||||
То есть ответ не должен превращаться в:
|
||||
“нашли что-то в 2025, значит объясняем июль 2020 через это”.
|
||||
|
||||
Сначала должно быть:
|
||||
|
||||
* что видно в самом окне июля 2020,
|
||||
* потом — что объясняется данными вне окна.
|
||||
|
||||
Это очень важная разница.
|
||||
|
||||
---
|
||||
|
||||
## Как это правильно назвать в ТЗ
|
||||
|
||||
Не `temporal hard lock` в смысле “сидим внутри месяца и ни шагу в сторону”, а так:
|
||||
|
||||
### `primary_period_anchor + controlled temporal expansion`
|
||||
|
||||
То есть:
|
||||
|
||||
**Primary period anchor**
|
||||
|
||||
* вопрос жёстко привязан к основному периоду пользователя.
|
||||
|
||||
**Controlled temporal expansion**
|
||||
|
||||
* система может выходить за пределы периода,
|
||||
* но только по связанным сущностям,
|
||||
* только с объяснимой причиной,
|
||||
* только в ограниченной роли,
|
||||
* и не подменяя основной период ответа.
|
||||
|
||||
---
|
||||
|
||||
## Как бы я переписал это в ТЗ
|
||||
|
||||
Вот формулировка, которую лучше дать Codex вместо слишком жёсткого запрета:
|
||||
|
||||
### Temporal rules
|
||||
|
||||
1. Для каждого вопроса определить:
|
||||
|
||||
* `primary_period`
|
||||
* `allowed_context_window`
|
||||
* `context_expansion_reason`
|
||||
|
||||
2. `Primary_period` — это главный период ответа, который нельзя silently replace.
|
||||
|
||||
3. Выход за пределы `primary_period` разрешён, если:
|
||||
|
||||
* найден связанный договор / расчётный объект / документ / регистровая цепочка;
|
||||
* внешняя дата нужна для объяснения причины или последствия;
|
||||
* данные явно маркируются как `prehistory`, `carryover`, `post-period closure`, `long-running contract context`.
|
||||
|
||||
4. В answer/debug нужно различать:
|
||||
|
||||
* **что подтверждено внутри основного периода**;
|
||||
* **что подтянуто из соседних/дальних периодов как объясняющий контекст**.
|
||||
|
||||
5. Запрещено:
|
||||
|
||||
* заменять `primary_period` другим периодом без явного основания;
|
||||
* использовать out-of-period evidence как основной grounding, если оно не связано с сущностью вопроса;
|
||||
* строить ответ на future-dated / unrelated data.
|
||||
|
||||
---
|
||||
|
||||
## Самая правильная модель для бухгалтерии
|
||||
|
||||
Я бы описал её так:
|
||||
|
||||
**Есть период вопроса.
|
||||
Есть горизонт расследования.
|
||||
Период вопроса — это центр.
|
||||
Горизонт расследования — это допустимая зона обхода цепочки.**
|
||||
|
||||
И вот ваша система сейчас как раз, похоже, не различает эти две вещи:
|
||||
|
||||
* иногда слишком свободно уезжает из центра,
|
||||
* а иногда, наоборот, живёт на маленьком срезе и не дотягивается до причинной цепочки.
|
||||
|
||||
Поэтому тебе кажется, что “запрет на выход из месяца” опасен — и ты прав, если понимать его буквально. Буквально так делать нельзя.
|
||||
|
||||
---
|
||||
|
||||
## Коротко
|
||||
|
||||
Да, замечание правильное.
|
||||
Нужен не запрет выходить за пределы июля 2020, а:
|
||||
|
||||
**жёсткая фиксация главного периода вопроса + контролируемое расширение по цепочке связанных сущностей.**
|
||||
|
||||
____
|
||||
Да — **отдавать лучше одним пакетом**, а не тремя разрозненными ТЗ.
|
||||
|
||||
Но с важной оговоркой:
|
||||
|
||||
**одна ТЗ ≠ один слепой мах без промежуточной фиксации.**
|
||||
|
||||
Правильный режим такой:
|
||||
|
||||
## Как это лучше ставить Codex
|
||||
|
||||
Ты даёшь **одну общую ТЗ на blocker-pack**, где внутри уже прописано:
|
||||
|
||||
1. `GAP-01` — primary period anchor + controlled temporal expansion
|
||||
2. `GAP-02` — domain polarity guard
|
||||
3. `GAP-03` — evidence admissibility gate
|
||||
4. общий rerun и run-артефакты после всех трёх
|
||||
|
||||
То есть для тебя это **одна задача**, а для него — **один execution pack с внутренними этапами**.
|
||||
|
||||
---
|
||||
|
||||
## Почему не надо дробить на отдельные независимые ТЗ
|
||||
|
||||
Потому что эти штуки связаны:
|
||||
|
||||
* без временной фиксации периодов polarity может строиться на мусоре;
|
||||
* без polarity admissibility будет фильтровать не тот домен;
|
||||
* без admissibility temporal fix не спасёт от левых evidence.
|
||||
|
||||
Если их резать на три независимых задания, есть риск, что:
|
||||
|
||||
* один кусок “починился” локально,
|
||||
* а вся цепочка всё равно продолжает врать.
|
||||
|
||||
---
|
||||
|
||||
## Но почему нельзя “одним махом” совсем без структуры
|
||||
|
||||
Потому что тогда Codex легко:
|
||||
|
||||
* начнёт лезть шире, чем надо;
|
||||
* смешает fix и redesign;
|
||||
* сделает пачку изменений без понятного before/after;
|
||||
* и ты потом не поймёшь, что именно помогло, а что просто пошумело.
|
||||
|
||||
Поэтому правильная формула:
|
||||
|
||||
### Даёшь одним пакетом, но требуешь:
|
||||
|
||||
* делать **по subwave внутри одного run-пакета**;
|
||||
* после каждой subwave фиксировать изменения и локальные проверки;
|
||||
* в конце делать **единый rerun core-8**;
|
||||
* положить все артефакты в один новый run folder.
|
||||
|
||||
---
|
||||
|
||||
## Как это сформулировать ему одной фразой
|
||||
|
||||
Можно так:
|
||||
|
||||
**Выполни это как один Stage 4 blocker-closure execution pack, но реализуй внутри последовательно: сначала GAP-01, потом GAP-02, потом GAP-03, без выхода за scope, с обязательной фиксацией локальных результатов по каждой подволне и общим финальным rerun после всех трёх.**
|
||||
|
||||
---
|
||||
|
||||
## Это тюн или не тюн
|
||||
|
||||
Это уже **не просто тюн текста/маршрута**.
|
||||
Это **структурный corrective pack внутри Stage 4**.
|
||||
|
||||
Но это всё ещё:
|
||||
|
||||
* не новая архитектурная стадия,
|
||||
* не Stage 5,
|
||||
* не proof engine целиком,
|
||||
* не большой redesign.
|
||||
|
||||
То есть это **сильный runtime hardening**, а не “перестройка всего”.
|
||||
|
||||
---
|
||||
|
||||
## Мой совет
|
||||
|
||||
Отдавай **одним ТЗ**, да.
|
||||
Но прямо в начале добавь две жёсткие фразы:
|
||||
|
||||
**1. Не делать это как один большой неразмеченный рефактор.**
|
||||
**2. Выполнять как один pack с тремя последовательными subwave и общим финальным rerun.**
|
||||
|
||||
|
||||
Binary file not shown.
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
File diff suppressed because it is too large
Load Diff
|
|
@ -1,93 +0,0 @@
|
|||
# Router / Orchestration Fix Report (2026-03-23)
|
||||
|
||||
## Scope completed
|
||||
|
||||
По `IN/TZ_Router_Orchestration_Fix.md` реализованы:
|
||||
|
||||
1. Query classifier v2 с decision flags.
|
||||
2. Store sufficiency checker.
|
||||
3. Explicit route guards.
|
||||
4. Runtime batch handoff (`refresh_and_answer` job path).
|
||||
5. Route decision logging для всех benchmark-вопросов.
|
||||
6. Unit + integration-style tests по router-модулям.
|
||||
7. Повторный validation-run на июньском semantic-v2 срезе.
|
||||
|
||||
## Implemented modules
|
||||
|
||||
Новые пакеты и файлы:
|
||||
|
||||
- `router/query_classifier.py`
|
||||
- `router/store_sufficiency.py`
|
||||
- `router/route_selector.py`
|
||||
- `router/decision_log.py`
|
||||
- `orchestration/batch_runtime.py`
|
||||
|
||||
Подключение в benchmark-runtime:
|
||||
|
||||
- `scripts/run_validation_accounting_analytics.py`
|
||||
- orchestration policy расширена ссылками на runtime-router модули;
|
||||
- добавлен `build_store_metadata(...)`;
|
||||
- добавлен `build_benchmark_results_v2(...)`;
|
||||
- добавлен batch handoff path для `batch_refresh_then_store`;
|
||||
- добавлен export `route_decision_logs.json`.
|
||||
|
||||
## Tests
|
||||
|
||||
Добавлены тесты:
|
||||
|
||||
- `tests/test_router_decision_flags.py`
|
||||
- `tests/test_store_sufficiency.py`
|
||||
- `tests/test_route_guards.py`
|
||||
- `tests/test_batch_runtime_handoff.py`
|
||||
- `tests/test_router_benchmark_subset.py`
|
||||
|
||||
Статус:
|
||||
|
||||
- `python -m pytest -q` -> `31 passed`
|
||||
|
||||
## Validation run (router-fix)
|
||||
|
||||
Команда:
|
||||
|
||||
`python scripts/run_validation_accounting_analytics.py --snapshot-path logs/pre_report_snapshot_2020_2020-06_semantic_v2.json --output-dir docs/ARCH/validation_run_2026-03-23_router_fix --strict`
|
||||
|
||||
Выход:
|
||||
|
||||
- `docs/ARCH/validation_run_2026-03-23_router_fix/`
|
||||
|
||||
Ключевые результаты benchmark:
|
||||
|
||||
- `questions_total = 35`
|
||||
- `route_mismatch_count = 1` (было 7)
|
||||
- `degraded_answers_count = 0`
|
||||
- `batch_route_count = 5` (было 0)
|
||||
- `heavy_analytical mismatches = 0`
|
||||
- `cross_entity mismatches = 0`
|
||||
- `drilldown_explain mismatches = 0`
|
||||
|
||||
Единственный остаточный mismatch:
|
||||
|
||||
- `Q19` (`period_trend`): expected `store_feature_risk`, actual `batch_refresh_then_store`
|
||||
|
||||
Decision logs:
|
||||
|
||||
- `docs/ARCH/validation_run_2026-03-23_router_fix/route_decision_logs.json`
|
||||
- покрытие логами: `35/35` вопросов.
|
||||
|
||||
## Acceptance criteria status
|
||||
|
||||
По целям ТЗ:
|
||||
|
||||
- `route_mismatch_count <= 2`: **done** (`1`)
|
||||
- `heavy_analytical mismatches = 0`: **done**
|
||||
- `cross_entity mismatches = 0`: **done**
|
||||
- `drilldown_explain mismatches <= 1`: **done** (`0`)
|
||||
- `batch_route_count > 0`: **done** (`5`)
|
||||
- `degraded_answers_count = 0`: **done**
|
||||
- decision logs for all 35: **done**
|
||||
|
||||
## Notes
|
||||
|
||||
1. Batch runtime path исполняется в-process через `orchestration.batch_runtime`, с job payload и run-id trace.
|
||||
2. Refresh step в batch режиме сейчас gated (`allow_refresh_in_batch=False` для validation profile), чтобы не делать неконтролируемый live refresh в этом прогоне; при этом feature/risk handoff исполняется реально.
|
||||
3. Следующий точечный шаг: опционально дотюнить classifier threshold для `Q19`, чтобы привести `route_mismatch_count` к `0`.
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
# Router / Orchestration Fix Report v2 (2026-03-23)
|
||||
|
||||
## Final tuning step
|
||||
|
||||
После первого router-fix прогона оставался 1 mismatch (`Q19`), где `period_trend` вопрос с формулировкой про аномалию уходил в batch.
|
||||
|
||||
Сделана точечная правка:
|
||||
|
||||
- `router/route_selector.py`
|
||||
- heavy-guard теперь срабатывает по `needs_anomaly_summary` только если запрос не относится к trend/risk профилю (`not parsed_as_trend_or_risk`).
|
||||
|
||||
Добавлен тест:
|
||||
|
||||
- `tests/test_router_benchmark_subset.py::test_router_period_trend_anomaly_stays_feature_store`
|
||||
|
||||
## Verification
|
||||
|
||||
- `python -m pytest -q` -> `32 passed`
|
||||
- Validation run:
|
||||
- `python scripts/run_validation_accounting_analytics.py --snapshot-path logs/pre_report_snapshot_2020_2020-06_semantic_v2.json --output-dir docs/ARCH/validation_run_2026-03-23_router_fix_v2 --strict`
|
||||
|
||||
## Result metrics (router_fix_v2)
|
||||
|
||||
- `questions_total = 35`
|
||||
- `route_mismatch_count = 0`
|
||||
- `degraded_answers_count = 0`
|
||||
- `heavy_analytical mismatches = 0`
|
||||
- `cross_entity mismatches = 0`
|
||||
- `drilldown_explain mismatches = 0`
|
||||
- `batch_route_count = 4` (> 0, runtime path active)
|
||||
|
||||
## Artifacts
|
||||
|
||||
- `docs/ARCH/validation_run_2026-03-23_router_fix_v2/`
|
||||
- `docs/ARCH/validation_run_2026-03-23_router_fix_v2/route_decision_logs.json`
|
||||
|
|
@ -1,117 +0,0 @@
|
|||
# Stage 4 Wave 4 — Root Cause Diagnostic Report (4.4)
|
||||
|
||||
Дата: 2026-03-27
|
||||
Режим: диагностический проход (без нового patch)
|
||||
|
||||
## 1. Что проверено
|
||||
|
||||
Проверены артефакты:
|
||||
- `TZ_Stage_4_Accounting_Ontology_Graph_Core_Assistant_Mode.md`
|
||||
- `STAGE_04_TASK_CARD.md`
|
||||
- `defect_report_case_97_lifecycle_stage4_wave4_2026-03-27.md`
|
||||
- `fix_report_case_97_lifecycle_stage4_wave4_2026-03-27.md`
|
||||
- `Текстовый документ.txt`
|
||||
- `Текстовый документ2.txt`
|
||||
- дополнительно для фактического ответа по 97: `Текстовый документ1.txt` (в `Текстовый документ2.txt` по 97 есть два подряд user-сообщения без assistant-ответа)
|
||||
|
||||
Сверка сделана по 3 кейсам:
|
||||
1. 97 / зависшее списание РБП
|
||||
2. ОС / карточка-документы-начисления не бьются
|
||||
3. НДС / документы и регистры расходятся
|
||||
|
||||
## 2. Какой ответ приемлем для 4.4
|
||||
|
||||
Для Stage 4 Wave 4 приемлемый минимум (без завышения до Stage 5/6):
|
||||
- problem-first верх ответа;
|
||||
- короткое causal-объяснение;
|
||||
- человеческое указание missing/conflicting link/transition;
|
||||
- доменно-чистый вывод по запросу (без подмешивания чужих контуров);
|
||||
- честные ограничения по coverage/confidence и периоду;
|
||||
- без internal/debug мусора в user-facing тексте.
|
||||
|
||||
Это соответствует Stage 4 Task Card: graph traversal в graph-eligible запросах + graph-backed problem/lifecycle + user-facing causal path, без выхода в Stage 5/6.
|
||||
|
||||
## 3. Какие дефекты повторяются между кейсами
|
||||
|
||||
Общие повторяемые дефекты:
|
||||
1. User-facing слой остаётся technical-heavy:
|
||||
- `Answer summary`, `Mechanism block`, `Evidence block`, `Uncertainty block`, служебные коды/англоязычные токены.
|
||||
2. Доменная деградация:
|
||||
- VAT и OS кейсы тянут lifecycle-смысл в `deferred_expense` / `overdue_writeoff` вместо чистого доменного вывода.
|
||||
3. Слабая развязка «реальная проблема vs шум»:
|
||||
- почти везде "ограниченная надежность", но без ясного ранжирования по практической проверке.
|
||||
4. Шум рендера:
|
||||
- повторы кластеров (97),
|
||||
- следы mojibake (`в” snapshot 2020...`, искажённые русские строки в technical sections).
|
||||
5. Нестабильность runtime-пути между сессиями:
|
||||
- в одном экспорте `graph_runtime_enabled=false` + legacy `stage1_policy_v11`,
|
||||
- в других — `graph_runtime_enabled=true` + `stage3_lifecycle_aware_v1`.
|
||||
|
||||
## 4. Root cause по слоям
|
||||
|
||||
### Normalizer
|
||||
- В целом корректно распознаёт in-scope.
|
||||
- 97: есть `account_hints=[97]`, `asks_for_chain_explanation=true`, `time_scope=missing`.
|
||||
- Проблема не в базовом in-scope распознавании.
|
||||
|
||||
### Routing
|
||||
- 97 (реальный ответ из `Текстовый документ1.txt`): ушёл в `store_canonical` при lifecycle-интенте (`has_multi_entity_scope=false`), что ухудшило дальнейший path.
|
||||
- OS/NDS: routed в `hybrid_store_plus_live`.
|
||||
- Итог: routing частично причина (особенно 97), но не единственная.
|
||||
|
||||
### Retrieval
|
||||
- OS: `query_subject=fixed_asset_card_mismatch`, но evidence/graph_scope подмешивает VAT/RBP/settlement.
|
||||
- NDS: `query_subject=vat_chain_conflict`, traversal есть, но downstream признаки уходят в deferred-expense semantics.
|
||||
- 97: canonical-list retrieval даёт слабую доменную точность для lifecycle-сценария.
|
||||
|
||||
### Graph traversal
|
||||
- OS экспорт: `graph_eligible=true`, но `graph_runtime_enabled=false`, `graph_traversal_applied=false`.
|
||||
- NDS экспорт: `graph_runtime_enabled=true`, `graph_traversal_applied=true`.
|
||||
- Значит, traversal как механизм существует, но execution-path между сессиями нестабилен.
|
||||
|
||||
### Problem assembly
|
||||
- Кластеры в low-confidence, duplicate-collapse фактически слабый в user-facing результате (особенно 97).
|
||||
- Ассемблер допускает cross-domain contamination в итоговых unit-ах.
|
||||
|
||||
### Lifecycle binding
|
||||
- Для VAT кейса lifecycle-дистрибуция в ответе уходит в `deferred_expense` вместо VAT-специфики.
|
||||
- Для OS отсутствует доменно-точный causal path "карточка -> документ -> начисление" в верхнем ответе.
|
||||
|
||||
### Answer synthesis
|
||||
- Главный пользовательский bottleneck:
|
||||
- technical tokens и внутренние маркеры попадают в direct answer;
|
||||
- повторы и перегрузка текстом;
|
||||
- слабая бухгалтерская actionable форма;
|
||||
- не всегда корректно/чисто отдается limitation по периоду.
|
||||
|
||||
## 5. Что сейчас первично чинить
|
||||
|
||||
Первично чинить не онтологию, а execution/binding/synthesis контур 4.4:
|
||||
1. Стабилизировать единый runtime-path для Stage 4 (исключить смешение `graph_runtime_enabled` ON/OFF между сессиями одного wave).
|
||||
2. Добить domain separation в problem/lifecycle binding (OS != VAT != 97).
|
||||
3. Ужесточить user-facing sanitizer/composer (убрать technical block leakage и повторы, оставить problem-first + causal + first checks).
|
||||
|
||||
## 6. Идти дальше в ontology или стоп и добивать 4.4
|
||||
|
||||
Решение: **стоп и добивать 4.4**.
|
||||
|
||||
Обоснование:
|
||||
- По документам Stage 4 acceptance требует user-facing causal usefulness уже на этом этапе.
|
||||
- Текущие реальные ответы показывают, что узкое место в decision/binding/answer packaging + runtime consistency.
|
||||
- Расширение ontology сейчас увеличит сложность, но не снимет главный пользовательский дефект.
|
||||
|
||||
## 7. Минимальный план следующего прохода (без Stage 5/6)
|
||||
|
||||
1. Сделать контрольный rerun 3 кейсов в одной фиксированной backend-сессии (один runtime state), с export диалогов.
|
||||
2. Для каждого кейса зафиксировать:
|
||||
- `route`
|
||||
- `graph_runtime_enabled`
|
||||
- `graph_traversal_applied`
|
||||
- `problem_answer_mode`
|
||||
- top-level direct answer
|
||||
3. Проверить acceptance 4.4 на этих же трёх кейсах (problem-first, causal link, domain purity, period limitation, no internal leakage).
|
||||
4. Только если на контрольном rerun повторится просадка — запускать минимальный patch именно в binding/synthesis (без Stage 5/6, без transport redesign).
|
||||
|
||||
---
|
||||
|
||||
Краткий вывод: главный bottleneck 4.4 сейчас — **не недостроенная ontology**, а **нестабильный runtime path + binding/synthesis quality**. До стабилизации этого контура дальше в ontology идти рано.
|
||||
|
|
@ -1,172 +0,0 @@
|
|||
# Stage 4 Wave 4 — Диагностический репорт качества user-facing ответов
|
||||
|
||||
Дата: 2026-03-26
|
||||
Контур: Assistant Mode, Stage 4 Wave 4
|
||||
Статус: диагностический отчёт без code patch
|
||||
|
||||
---
|
||||
|
||||
## 1. Что проверено
|
||||
|
||||
Проверены три последних пары user/assistant из файла:
|
||||
- `X:\1C\NDC_1C\llm_normalizer\docs\runs\2026-03-26_Stage_04_Wave_04_Graph_Critical_Coverage\Текстовый документ.txt`
|
||||
|
||||
Сверка выполнена с целевыми требованиями:
|
||||
- `X:\1C\NDC_1C\docs\accounting-assistant\accounting-assistant\02_stages\TZ_Stage_4_Accounting_Ontology_Graph_Core_Assistant_Mode.md`
|
||||
- `X:\1C\NDC_1C\docs\accounting-assistant\accounting-assistant\03_execution\STAGE_04_TASK_CARD.md`
|
||||
|
||||
Дополнительно проверено, не выключен ли graph runtime по конфигу:
|
||||
- `X:\1C\NDC_1C\llm_normalizer\backend\src\config.ts` (feature flag по умолчанию `false`)
|
||||
- runtime env vars процесса (`FEATURE_ASSISTANT_GRAPH_RUNTIME_V1` и связанные) — пустые
|
||||
- `.env` в `backend` отсутствует
|
||||
|
||||
---
|
||||
|
||||
## 2. Какая планка ответа приемлема именно для 4.4
|
||||
|
||||
Для Stage 4 Wave 4 приемлем промежуточный уровень, без завышения до Stage 5/6:
|
||||
|
||||
1. `problem-first` верх ответа
|
||||
2. короткое причинное объяснение (causal path)
|
||||
3. явный смысл отсутствующей/конфликтной связи или перехода
|
||||
4. доменная чистота ответа (без смешивания чужих контуров)
|
||||
5. честные ограничения (coverage/confidence)
|
||||
6. без internal/debug мусора в user-facing
|
||||
7. для period-close без периода допустим честный clarification
|
||||
|
||||
Что **не требуется** на 4.4:
|
||||
- full Investigation Engine (Stage 5)
|
||||
- full live verification orchestration (Stage 6)
|
||||
|
||||
---
|
||||
|
||||
## 3. Фактическое состояние по последним 3 вопросам
|
||||
|
||||
### Пара 1 — ОС
|
||||
Вопрос: «Покажи по основным средствам, где карточка, документы и начисления между собой не бьются.»
|
||||
|
||||
Технически:
|
||||
- `reply_type=partial_coverage`
|
||||
- `route=hybrid_store_plus_live`
|
||||
- `query_subject=fixed_asset_card_mismatch`
|
||||
- `graph_eligible=true`
|
||||
- `graph_runtime_enabled=false`
|
||||
- `graph_traversal_applied=false`
|
||||
- `problem_centric_answer_applied=false`
|
||||
- `problem_answer_mode=stage1_policy_v11`
|
||||
|
||||
Наблюдение:
|
||||
- верх ответа формально problem-first, но содержательно смешивает контуры (в рекомендациях появляются РБП/НДС/расчёты), что снижает доменную полезность ОС-ответа.
|
||||
|
||||
### Пара 2 — закрытие периода
|
||||
Вопрос: «Что сейчас сильнее всего мешает закрытию периода не по отдельному документу, а по связанной цепочке операций?»
|
||||
|
||||
Технически:
|
||||
- `reply_type=no_grounded_answer`
|
||||
- `fallback_type=clarification`
|
||||
- `route=no_route`
|
||||
- `execution_readiness=needs_clarification`
|
||||
- `no_route_reason=insufficient_specificity`
|
||||
|
||||
Наблюдение:
|
||||
- по логике это корректно для 4.4 (нужен период/объект),
|
||||
- но user-facing фраза в mojibake (дефект слоя рендеринга/кодировки).
|
||||
|
||||
### Пара 3 — cross-object gap
|
||||
Вопрос: «Где лучше всего видно, что проблема сидит не в одном документе, а в разрыве между связанными объектами?»
|
||||
|
||||
Технически:
|
||||
- `reply_type=partial_coverage`
|
||||
- `route=hybrid_store_plus_live`
|
||||
- `query_subject=cross_entity_breakage`
|
||||
- `graph_eligible=true`
|
||||
- `graph_runtime_enabled=false`
|
||||
- `graph_traversal_applied=false`
|
||||
- `problem_centric_answer_applied=false`
|
||||
- `problem_answer_mode=stage1_policy_v11`
|
||||
|
||||
Наблюдение:
|
||||
- ответ выглядит лучше формально, но фактически не подтверждает включённый graph-runtime в верхнем слое.
|
||||
|
||||
---
|
||||
|
||||
## 4. Какие дефекты найдены
|
||||
|
||||
1. **Graph value не доходит до user-facing слоя**
|
||||
По graph-eligible кейсам фактически `graph_runtime_enabled=false` и `graph_traversal_applied=false`.
|
||||
|
||||
2. **Ответы собираются старым answer path**
|
||||
`problem_answer_mode=stage1_policy_v11`, `problem_centric_answer_applied=false` в 2 из 3 кейсов с retrieval.
|
||||
|
||||
3. **Доменная нечистота ОС-ответа**
|
||||
В ответе по ОС смешиваются рекомендации по РБП/НДС/расчётным веткам.
|
||||
|
||||
4. **Mojibake в clarification ответе**
|
||||
В period-close кейсе логика верная, но user-facing текст испорчен.
|
||||
|
||||
5. **Неполная проверка рамки 60-счёта в этом конкретном хвосте**
|
||||
В последних 3 вопросах нет отдельного кейса по 60-му счёту, поэтому по этой части текущий хвост не даёт завершённого доказательства качества.
|
||||
|
||||
---
|
||||
|
||||
## 5. Root cause по слоям
|
||||
|
||||
### Normalizer
|
||||
- В целом рабочий.
|
||||
- ОС-кейс распознан корректно (`fixed_asset_card_mismatch`), period-close корректно отправлен в clarification из-за недостаточной конкретики.
|
||||
|
||||
### Routing
|
||||
- В целом рабочий.
|
||||
- Для неуточнённого period-close корректно `no_route`.
|
||||
|
||||
### Retrieval
|
||||
- Работает, но в текущих ответах нет runtime-эффекта graph traversal в верхнем ответе.
|
||||
|
||||
### Graph traversal
|
||||
- Ключевая проблема: graph-фаза фактически не применяется в этих ответах (`runtime_enabled=false`, `traversal_applied=false`).
|
||||
|
||||
### Problem assembly / lifecycle binding
|
||||
- Недоиспользование: проблема/causal сигналы не поднимаются в целевом режиме 4.4.
|
||||
|
||||
### Answer synthesis
|
||||
- Критический вклад в деградацию: fallback в `stage1_policy_v11`, доменное смешивание и mojibake в clarification.
|
||||
|
||||
---
|
||||
|
||||
## 6. Это проблема онтологии или decision/binding/answer layer?
|
||||
|
||||
Вывод: **в первую очередь проблема decision/binding/answer layer + activation/runtime path**, а не "недостроенная онтология".
|
||||
|
||||
Почему:
|
||||
- в Stage 4 артефактах graph-идеи уже есть,
|
||||
- но в реальных ответах runtime graph не участвует,
|
||||
- и верх ответа собирается legacy-режимом.
|
||||
|
||||
---
|
||||
|
||||
## 7. Можно ли идти дальше в ontology?
|
||||
|
||||
Решение: **не идти дальше в ontology сейчас**.
|
||||
Сначала добить 4.4 качество ответа и включённость graph-runtime в реальном user-facing контуре.
|
||||
|
||||
Иначе будет масштабирование архитектуры без фактической прибавки к полезности ответа, что противоречит Stage 4 acceptance логике.
|
||||
|
||||
---
|
||||
|
||||
## 8. Что чинить первым (минимальный план следующего прохода)
|
||||
|
||||
1. Проверить и стабилизировать activation graph-runtime в фактическом процессе backend.
|
||||
2. Убрать fallback в `stage1_policy_v11` для graph-eligible Stage 4 кейсов.
|
||||
3. Починить clarification user-facing кодировку (mojibake).
|
||||
4. Зафиксировать короткий before/after по тем же 3 вопросам с явными полями:
|
||||
- `graph_runtime_enabled`
|
||||
- `graph_traversal_applied`
|
||||
- `problem_centric_answer_applied`
|
||||
- `problem_answer_mode`
|
||||
|
||||
---
|
||||
|
||||
## 9. Краткий вердикт
|
||||
|
||||
Stage 4 Wave 4 на текущем состоянии **частично выполнен, но не принят по качеству user-facing**.
|
||||
Нужна точечная добивка 4.4 (activation + binding + synthesis), после чего уже можно безопасно продолжать онтологическое расширение.
|
||||
|
|
@ -1,35 +0,0 @@
|
|||
# Stage 4 Wave 4 — User-Facing Fix Report
|
||||
|
||||
Date: 2026-03-26
|
||||
Scope: точечный patch для качества user-facing ответа (без Stage 5/6 redesign)
|
||||
|
||||
## Что исправлено
|
||||
|
||||
1. Включены Stage 4 runtime/answer feature flags по умолчанию, чтобы backend не оставался в legacy-path при пустом env.
|
||||
2. В user-facing answer layer убраны internal/debug-like фрагменты из support-блоков (`Graph traversal mode`, `semantic_only`, `domain/document/relation`, и пр.).
|
||||
3. Усилена problem-first causal подача в верхнем ответе:
|
||||
- missing/conflicting transition формулируются в человеческом виде;
|
||||
- добавлен блок разделения «реальная проблема» vs «возможный шум».
|
||||
4. Уточнены domain-aware first checks, чтобы не смешивать ОС-ответы с payment/settlement цепочками без доменного сигнала.
|
||||
5. Устранены mojibake fallback-фразы в user-facing ответах (включая clarification path).
|
||||
|
||||
## Touched Files
|
||||
|
||||
- `X:\1C\NDC_1C\llm_normalizer\backend\src\config.ts`
|
||||
- `X:\1C\NDC_1C\llm_normalizer\backend\src\services\answerComposer.ts`
|
||||
- `X:\1C\NDC_1C\llm_normalizer\backend\tests\assistantEndpoint.test.ts`
|
||||
|
||||
## Проверки
|
||||
|
||||
- Build: `npm.cmd run build` — PASS
|
||||
- Full tests: `npm.cmd test` — PASS
|
||||
- Валидационные тесты по Stage 4 user-facing:
|
||||
- `assistantStage4Wave4UserFacing.test.ts` — PASS
|
||||
- `assistantAnswerEncodingSanitizer.test.ts` — PASS
|
||||
|
||||
## Что сознательно НЕ делалось
|
||||
|
||||
- Не менялся prompt-set.
|
||||
- Не менялись eval/framework.
|
||||
- Не делался transport/endpoint/base routing redesign.
|
||||
- Не выполнялся полный Stage 5/6 answer rewrite.
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
# Benchmark Final Verdict
|
||||
|
||||
## Verdict
|
||||
|
||||
`adopt_with_improvements`
|
||||
|
||||
## Key numbers
|
||||
|
||||
- Questions total: `35`
|
||||
- Route mismatches: `7`
|
||||
- Degraded answers: `0`
|
||||
- Avg latency ms: `506.43`
|
||||
- p95 latency ms: `1024.5`
|
||||
|
||||
## Recommendation
|
||||
|
||||
1. Fix ontology unknown mapping hotspots.
|
||||
2. Tune heavy-route threshold (`store_feature_risk` vs `batch_refresh_then_store`).
|
||||
3. Implement full production orchestration runtime.
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
# Benchmark Questions (35)
|
||||
|
||||
| ID | Class | Expected route | Question |
|
||||
| --- | --- | --- | --- |
|
||||
| Q01 | simple_factual | store_canonical | Сальдо счета 68.02 за июнь 2020? |
|
||||
| Q02 | simple_factual | live_mcp_drilldown | Документ по номеру и его ссылка. |
|
||||
| Q03 | simple_factual | store_canonical | Типовая проводка по реализации. |
|
||||
| Q04 | simple_factual | store_canonical | Контрагент с максимумом оборота. |
|
||||
| Q05 | simple_factual | store_canonical | Договоры топ-контрагента. |
|
||||
| Q06 | drilldown_explain | hybrid_store_plus_live | Объясни сальдо через движения. |
|
||||
| Q07 | drilldown_explain | live_mcp_drilldown | Почему проводка на этот счет? |
|
||||
| Q08 | drilldown_explain | live_mcp_drilldown | Цепочка документ -> проводки -> субконто. |
|
||||
| Q09 | drilldown_explain | live_mcp_drilldown | Источник регистра для строки движения. |
|
||||
| Q10 | drilldown_explain | live_mcp_drilldown | Почему выбрано это субконто3? |
|
||||
| Q11 | cross_entity | hybrid_store_plus_live | Свяжи документы покупателей и проводки. |
|
||||
| Q12 | cross_entity | hybrid_store_plus_live | Свяжи контрагентов, договоры и проводки. |
|
||||
| Q13 | cross_entity | store_canonical | Номенклатура, склад, обороты за июнь. |
|
||||
| Q14 | cross_entity | hybrid_store_plus_live | Регистр и первичный документ. |
|
||||
| Q15 | cross_entity | store_canonical | По счету: контрагенты и договоры. |
|
||||
| Q16 | period_trend | store_feature_risk | Обороты июня против мая. |
|
||||
| Q17 | period_trend | store_feature_risk | Недельные всплески в июне. |
|
||||
| Q18 | period_trend | store_feature_risk | Кто дал резкий рост активности. |
|
||||
| Q19 | period_trend | store_feature_risk | Аномальный рост расходных операций? |
|
||||
| Q20 | period_trend | store_feature_risk | Динамика НДС к соседним периодам. |
|
||||
| Q21 | anomaly_control | store_feature_risk | Нетипичные корреспонденции счетов. |
|
||||
| Q22 | anomaly_control | store_feature_risk | Незакрытые хвосты по расчетам. |
|
||||
| Q23 | anomaly_control | store_feature_risk | Дублирующиеся проводки. |
|
||||
| Q24 | anomaly_control | store_feature_risk | Пустые или странные субконто. |
|
||||
| Q25 | anomaly_control | store_feature_risk | Узлы с подозрительно большим degree. |
|
||||
| Q26 | heavy_analytical | batch_refresh_then_store | Полный риск-срез за июнь. |
|
||||
| Q27 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-счетов. |
|
||||
| Q28 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-контрагентов. |
|
||||
| Q29 | heavy_analytical | store_feature_risk | Baseline closed/open periods. |
|
||||
| Q30 | heavy_analytical | batch_refresh_then_store | Company anomaly summary. |
|
||||
| Q31 | ambiguous_fuzzy | store_feature_risk | Что по налогам и рискам? |
|
||||
| Q32 | ambiguous_fuzzy | store_feature_risk | Что странное в расходах? |
|
||||
| Q33 | ambiguous_fuzzy | store_feature_risk | Самые рисковые контрагенты? |
|
||||
| Q34 | ambiguous_fuzzy | hybrid_store_plus_live | Что с 68.02? |
|
||||
| Q35 | ambiguous_fuzzy | store_feature_risk | Проверить документы июня. |
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
# Benchmark Route Analysis
|
||||
|
||||
- Total mismatches: `7`
|
||||
|
||||
## Route confusion matrix
|
||||
|
||||
- `batch_refresh_then_store` -> store_feature_risk:4
|
||||
- `hybrid_store_plus_live` -> hybrid_store_plus_live:3, store_canonical:2
|
||||
- `live_mcp_drilldown` -> hybrid_store_plus_live:1, live_mcp_drilldown:4
|
||||
- `store_canonical` -> store_canonical:6
|
||||
- `store_feature_risk` -> store_feature_risk:15
|
||||
|
||||
## Mismatch by class
|
||||
|
||||
| Class | Mismatch count |
|
||||
| --- | --- |
|
||||
| cross_entity | 2 |
|
||||
| drilldown_explain | 1 |
|
||||
| heavy_analytical | 4 |
|
||||
|
|
@ -1,38 +0,0 @@
|
|||
# Benchmark Run Report
|
||||
|
||||
## Aggregate statistics
|
||||
|
||||
| Metric | Value |
|
||||
| --- | --- |
|
||||
| questions_total | 35 |
|
||||
| avg_latency_ms | 506.43 |
|
||||
| median_latency_ms | 402 |
|
||||
| p90_latency_ms | 941.4 |
|
||||
| p95_latency_ms | 1024.5 |
|
||||
| avg_context_size | 2162.51 |
|
||||
| live_route_count | 8 |
|
||||
| store_route_count | 27 |
|
||||
| batch_route_count | 0 |
|
||||
| route_mismatch_count | 7 |
|
||||
| degraded_answers_count | 0 |
|
||||
|
||||
## Route distribution
|
||||
|
||||
| Route | Count |
|
||||
| --- | --- |
|
||||
| hybrid_store_plus_live | 4 |
|
||||
| live_mcp_drilldown | 4 |
|
||||
| store_canonical | 8 |
|
||||
| store_feature_risk | 19 |
|
||||
|
||||
## Question class distribution
|
||||
|
||||
| Class | Count |
|
||||
| --- | --- |
|
||||
| ambiguous_fuzzy | 5 |
|
||||
| anomaly_control | 5 |
|
||||
| cross_entity | 5 |
|
||||
| drilldown_explain | 5 |
|
||||
| heavy_analytical | 5 |
|
||||
| period_trend | 5 |
|
||||
| simple_factual | 5 |
|
||||
|
|
@ -1,827 +0,0 @@
|
|||
{
|
||||
"status": "success",
|
||||
"slice_window_key": "2020-06",
|
||||
"generated_at": "2026-03-23T09:28:12.312411+00:00",
|
||||
"questions_total": 35,
|
||||
"aggregate": {
|
||||
"questions_total": 35,
|
||||
"avg_latency_ms": 506.43,
|
||||
"median_latency_ms": 402,
|
||||
"p90_latency_ms": 941.4,
|
||||
"p95_latency_ms": 1024.5,
|
||||
"avg_context_size": 2162.51,
|
||||
"live_route_count": 8,
|
||||
"store_route_count": 27,
|
||||
"batch_route_count": 0,
|
||||
"route_mismatch_count": 7,
|
||||
"degraded_answers_count": 0,
|
||||
"route_distribution": {
|
||||
"store_canonical": 8,
|
||||
"live_mcp_drilldown": 4,
|
||||
"hybrid_store_plus_live": 4,
|
||||
"store_feature_risk": 19
|
||||
},
|
||||
"question_class_distribution": {
|
||||
"simple_factual": 5,
|
||||
"drilldown_explain": 5,
|
||||
"cross_entity": 5,
|
||||
"period_trend": 5,
|
||||
"anomaly_control": 5,
|
||||
"heavy_analytical": 5,
|
||||
"ambiguous_fuzzy": 5
|
||||
}
|
||||
},
|
||||
"results": [
|
||||
{
|
||||
"question_id": "Q01",
|
||||
"question_text": "Сальдо счета 68.02 за июнь 2020?",
|
||||
"question_class": "simple_factual",
|
||||
"expected_route": "store_canonical",
|
||||
"actual_route": "store_canonical",
|
||||
"sources_used": [
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 332,
|
||||
"planning_time_ms": 67,
|
||||
"retrieval_time_ms": 129,
|
||||
"response_generation_time_ms": 136,
|
||||
"context_size": 1595,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q02",
|
||||
"question_text": "Документ по номеру и его ссылка.",
|
||||
"question_class": "simple_factual",
|
||||
"expected_route": "live_mcp_drilldown",
|
||||
"actual_route": "live_mcp_drilldown",
|
||||
"sources_used": [
|
||||
"mcp_runtime_bridge"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 1020,
|
||||
"planning_time_ms": 93,
|
||||
"retrieval_time_ms": 740,
|
||||
"response_generation_time_ms": 187,
|
||||
"context_size": 2796,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=live_mcp_drilldown; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q03",
|
||||
"question_text": "Типовая проводка по реализации.",
|
||||
"question_class": "simple_factual",
|
||||
"expected_route": "store_canonical",
|
||||
"actual_route": "store_canonical",
|
||||
"sources_used": [
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 338,
|
||||
"planning_time_ms": 69,
|
||||
"retrieval_time_ms": 131,
|
||||
"response_generation_time_ms": 138,
|
||||
"context_size": 1597,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q04",
|
||||
"question_text": "Контрагент с максимумом оборота.",
|
||||
"question_class": "simple_factual",
|
||||
"expected_route": "store_canonical",
|
||||
"actual_route": "store_canonical",
|
||||
"sources_used": [
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 341,
|
||||
"planning_time_ms": 70,
|
||||
"retrieval_time_ms": 132,
|
||||
"response_generation_time_ms": 139,
|
||||
"context_size": 1598,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q05",
|
||||
"question_text": "Договоры топ-контрагента.",
|
||||
"question_class": "simple_factual",
|
||||
"expected_route": "store_canonical",
|
||||
"actual_route": "store_canonical",
|
||||
"sources_used": [
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 344,
|
||||
"planning_time_ms": 71,
|
||||
"retrieval_time_ms": 133,
|
||||
"response_generation_time_ms": 140,
|
||||
"context_size": 1599,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q06",
|
||||
"question_text": "Объясни сальдо через движения.",
|
||||
"question_class": "drilldown_explain",
|
||||
"expected_route": "hybrid_store_plus_live",
|
||||
"actual_route": "hybrid_store_plus_live",
|
||||
"sources_used": [
|
||||
"canonical_store",
|
||||
"mcp_runtime_bridge"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 819,
|
||||
"planning_time_ms": 114,
|
||||
"retrieval_time_ms": 524,
|
||||
"response_generation_time_ms": 181,
|
||||
"context_size": 2950,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=hybrid_store_plus_live; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q07",
|
||||
"question_text": "Почему проводка на этот счет?",
|
||||
"question_class": "drilldown_explain",
|
||||
"expected_route": "live_mcp_drilldown",
|
||||
"actual_route": "live_mcp_drilldown",
|
||||
"sources_used": [
|
||||
"mcp_runtime_bridge"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 1035,
|
||||
"planning_time_ms": 98,
|
||||
"retrieval_time_ms": 745,
|
||||
"response_generation_time_ms": 192,
|
||||
"context_size": 2801,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=live_mcp_drilldown; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q08",
|
||||
"question_text": "Цепочка документ -> проводки -> субконто.",
|
||||
"question_class": "drilldown_explain",
|
||||
"expected_route": "live_mcp_drilldown",
|
||||
"actual_route": "live_mcp_drilldown",
|
||||
"sources_used": [
|
||||
"mcp_runtime_bridge"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 1038,
|
||||
"planning_time_ms": 99,
|
||||
"retrieval_time_ms": 746,
|
||||
"response_generation_time_ms": 193,
|
||||
"context_size": 2802,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=live_mcp_drilldown; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q09",
|
||||
"question_text": "Источник регистра для строки движения.",
|
||||
"question_class": "drilldown_explain",
|
||||
"expected_route": "live_mcp_drilldown",
|
||||
"actual_route": "hybrid_store_plus_live",
|
||||
"sources_used": [
|
||||
"canonical_store",
|
||||
"mcp_runtime_bridge"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 828,
|
||||
"planning_time_ms": 117,
|
||||
"retrieval_time_ms": 527,
|
||||
"response_generation_time_ms": 184,
|
||||
"context_size": 2953,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=hybrid_store_plus_live; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "acceptable_with_warning",
|
||||
"issues_detected": [
|
||||
"Route mismatch: expected live_mcp_drilldown, got hybrid_store_plus_live"
|
||||
],
|
||||
"recommended_fix": "Tune router threshold for heavy/live boundary."
|
||||
},
|
||||
{
|
||||
"question_id": "Q10",
|
||||
"question_text": "Почему выбрано это субконто3?",
|
||||
"question_class": "drilldown_explain",
|
||||
"expected_route": "live_mcp_drilldown",
|
||||
"actual_route": "live_mcp_drilldown",
|
||||
"sources_used": [
|
||||
"mcp_runtime_bridge"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 1017,
|
||||
"planning_time_ms": 92,
|
||||
"retrieval_time_ms": 739,
|
||||
"response_generation_time_ms": 186,
|
||||
"context_size": 2795,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=live_mcp_drilldown; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q11",
|
||||
"question_text": "Свяжи документы покупателей и проводки.",
|
||||
"question_class": "cross_entity",
|
||||
"expected_route": "hybrid_store_plus_live",
|
||||
"actual_route": "store_canonical",
|
||||
"sources_used": [
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 335,
|
||||
"planning_time_ms": 68,
|
||||
"retrieval_time_ms": 130,
|
||||
"response_generation_time_ms": 137,
|
||||
"context_size": 1596,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "acceptable_with_warning",
|
||||
"issues_detected": [
|
||||
"Route mismatch: expected hybrid_store_plus_live, got store_canonical"
|
||||
],
|
||||
"recommended_fix": "Tune router threshold for heavy/live boundary."
|
||||
},
|
||||
{
|
||||
"question_id": "Q12",
|
||||
"question_text": "Свяжи контрагентов, договоры и проводки.",
|
||||
"question_class": "cross_entity",
|
||||
"expected_route": "hybrid_store_plus_live",
|
||||
"actual_route": "store_canonical",
|
||||
"sources_used": [
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 338,
|
||||
"planning_time_ms": 69,
|
||||
"retrieval_time_ms": 131,
|
||||
"response_generation_time_ms": 138,
|
||||
"context_size": 1597,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "acceptable_with_warning",
|
||||
"issues_detected": [
|
||||
"Route mismatch: expected hybrid_store_plus_live, got store_canonical"
|
||||
],
|
||||
"recommended_fix": "Tune router threshold for heavy/live boundary."
|
||||
},
|
||||
{
|
||||
"question_id": "Q13",
|
||||
"question_text": "Номенклатура, склад, обороты за июнь.",
|
||||
"question_class": "cross_entity",
|
||||
"expected_route": "store_canonical",
|
||||
"actual_route": "store_canonical",
|
||||
"sources_used": [
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 341,
|
||||
"planning_time_ms": 70,
|
||||
"retrieval_time_ms": 132,
|
||||
"response_generation_time_ms": 139,
|
||||
"context_size": 1598,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q14",
|
||||
"question_text": "Регистр и первичный документ.",
|
||||
"question_class": "cross_entity",
|
||||
"expected_route": "hybrid_store_plus_live",
|
||||
"actual_route": "hybrid_store_plus_live",
|
||||
"sources_used": [
|
||||
"canonical_store",
|
||||
"mcp_runtime_bridge"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 816,
|
||||
"planning_time_ms": 113,
|
||||
"retrieval_time_ms": 523,
|
||||
"response_generation_time_ms": 180,
|
||||
"context_size": 2949,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=hybrid_store_plus_live; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q15",
|
||||
"question_text": "По счету: контрагенты и договоры.",
|
||||
"question_class": "cross_entity",
|
||||
"expected_route": "store_canonical",
|
||||
"actual_route": "store_canonical",
|
||||
"sources_used": [
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 347,
|
||||
"planning_time_ms": 72,
|
||||
"retrieval_time_ms": 134,
|
||||
"response_generation_time_ms": 141,
|
||||
"context_size": 1600,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_canonical; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q16",
|
||||
"question_text": "Обороты июня против мая.",
|
||||
"question_class": "period_trend",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 402,
|
||||
"planning_time_ms": 85,
|
||||
"retrieval_time_ms": 155,
|
||||
"response_generation_time_ms": 162,
|
||||
"context_size": 2101,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q17",
|
||||
"question_text": "Недельные всплески в июне.",
|
||||
"question_class": "period_trend",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 405,
|
||||
"planning_time_ms": 86,
|
||||
"retrieval_time_ms": 156,
|
||||
"response_generation_time_ms": 163,
|
||||
"context_size": 2102,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q18",
|
||||
"question_text": "Кто дал резкий рост активности.",
|
||||
"question_class": "period_trend",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 408,
|
||||
"planning_time_ms": 87,
|
||||
"retrieval_time_ms": 157,
|
||||
"response_generation_time_ms": 164,
|
||||
"context_size": 2103,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q19",
|
||||
"question_text": "Аномальный рост расходных операций?",
|
||||
"question_class": "period_trend",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 411,
|
||||
"planning_time_ms": 88,
|
||||
"retrieval_time_ms": 158,
|
||||
"response_generation_time_ms": 165,
|
||||
"context_size": 2104,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q20",
|
||||
"question_text": "Динамика НДС к соседним периодам.",
|
||||
"question_class": "period_trend",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 387,
|
||||
"planning_time_ms": 80,
|
||||
"retrieval_time_ms": 150,
|
||||
"response_generation_time_ms": 157,
|
||||
"context_size": 2096,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q21",
|
||||
"question_text": "Нетипичные корреспонденции счетов.",
|
||||
"question_class": "anomaly_control",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 390,
|
||||
"planning_time_ms": 81,
|
||||
"retrieval_time_ms": 151,
|
||||
"response_generation_time_ms": 158,
|
||||
"context_size": 2097,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q22",
|
||||
"question_text": "Незакрытые хвосты по расчетам.",
|
||||
"question_class": "anomaly_control",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 393,
|
||||
"planning_time_ms": 82,
|
||||
"retrieval_time_ms": 152,
|
||||
"response_generation_time_ms": 159,
|
||||
"context_size": 2098,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q23",
|
||||
"question_text": "Дублирующиеся проводки.",
|
||||
"question_class": "anomaly_control",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 396,
|
||||
"planning_time_ms": 83,
|
||||
"retrieval_time_ms": 153,
|
||||
"response_generation_time_ms": 160,
|
||||
"context_size": 2099,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q24",
|
||||
"question_text": "Пустые или странные субконто.",
|
||||
"question_class": "anomaly_control",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 399,
|
||||
"planning_time_ms": 84,
|
||||
"retrieval_time_ms": 154,
|
||||
"response_generation_time_ms": 161,
|
||||
"context_size": 2100,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q25",
|
||||
"question_text": "Узлы с подозрительно большим degree.",
|
||||
"question_class": "anomaly_control",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 402,
|
||||
"planning_time_ms": 85,
|
||||
"retrieval_time_ms": 155,
|
||||
"response_generation_time_ms": 162,
|
||||
"context_size": 2101,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "good",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q26",
|
||||
"question_text": "Полный риск-срез за июнь.",
|
||||
"question_class": "heavy_analytical",
|
||||
"expected_route": "batch_refresh_then_store",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 405,
|
||||
"planning_time_ms": 86,
|
||||
"retrieval_time_ms": 156,
|
||||
"response_generation_time_ms": 163,
|
||||
"context_size": 2102,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "acceptable",
|
||||
"route_quality_assessment": "acceptable_with_warning",
|
||||
"issues_detected": [
|
||||
"Route mismatch: expected batch_refresh_then_store, got store_feature_risk"
|
||||
],
|
||||
"recommended_fix": "Tune router threshold for heavy/live boundary."
|
||||
},
|
||||
{
|
||||
"question_id": "Q27",
|
||||
"question_text": "Рейтинг риск-счетов.",
|
||||
"question_class": "heavy_analytical",
|
||||
"expected_route": "batch_refresh_then_store",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 408,
|
||||
"planning_time_ms": 87,
|
||||
"retrieval_time_ms": 157,
|
||||
"response_generation_time_ms": 164,
|
||||
"context_size": 2103,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "acceptable",
|
||||
"route_quality_assessment": "acceptable_with_warning",
|
||||
"issues_detected": [
|
||||
"Route mismatch: expected batch_refresh_then_store, got store_feature_risk"
|
||||
],
|
||||
"recommended_fix": "Tune router threshold for heavy/live boundary."
|
||||
},
|
||||
{
|
||||
"question_id": "Q28",
|
||||
"question_text": "Рейтинг риск-контрагентов.",
|
||||
"question_class": "heavy_analytical",
|
||||
"expected_route": "batch_refresh_then_store",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 411,
|
||||
"planning_time_ms": 88,
|
||||
"retrieval_time_ms": 158,
|
||||
"response_generation_time_ms": 165,
|
||||
"context_size": 2104,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "acceptable",
|
||||
"route_quality_assessment": "acceptable_with_warning",
|
||||
"issues_detected": [
|
||||
"Route mismatch: expected batch_refresh_then_store, got store_feature_risk"
|
||||
],
|
||||
"recommended_fix": "Tune router threshold for heavy/live boundary."
|
||||
},
|
||||
{
|
||||
"question_id": "Q29",
|
||||
"question_text": "Baseline closed/open periods.",
|
||||
"question_class": "heavy_analytical",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 414,
|
||||
"planning_time_ms": 89,
|
||||
"retrieval_time_ms": 159,
|
||||
"response_generation_time_ms": 166,
|
||||
"context_size": 2105,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "acceptable",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q30",
|
||||
"question_text": "Company anomaly summary.",
|
||||
"question_class": "heavy_analytical",
|
||||
"expected_route": "batch_refresh_then_store",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 390,
|
||||
"planning_time_ms": 81,
|
||||
"retrieval_time_ms": 151,
|
||||
"response_generation_time_ms": 158,
|
||||
"context_size": 2097,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "acceptable",
|
||||
"route_quality_assessment": "acceptable_with_warning",
|
||||
"issues_detected": [
|
||||
"Route mismatch: expected batch_refresh_then_store, got store_feature_risk"
|
||||
],
|
||||
"recommended_fix": "Tune router threshold for heavy/live boundary."
|
||||
},
|
||||
{
|
||||
"question_id": "Q31",
|
||||
"question_text": "Что по налогам и рискам?",
|
||||
"question_class": "ambiguous_fuzzy",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 393,
|
||||
"planning_time_ms": 82,
|
||||
"retrieval_time_ms": 152,
|
||||
"response_generation_time_ms": 159,
|
||||
"context_size": 2098,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "acceptable",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q32",
|
||||
"question_text": "Что странное в расходах?",
|
||||
"question_class": "ambiguous_fuzzy",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 396,
|
||||
"planning_time_ms": 83,
|
||||
"retrieval_time_ms": 153,
|
||||
"response_generation_time_ms": 160,
|
||||
"context_size": 2099,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "acceptable",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q33",
|
||||
"question_text": "Самые рисковые контрагенты?",
|
||||
"question_class": "ambiguous_fuzzy",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 399,
|
||||
"planning_time_ms": 84,
|
||||
"retrieval_time_ms": 154,
|
||||
"response_generation_time_ms": 161,
|
||||
"context_size": 2100,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "acceptable",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q34",
|
||||
"question_text": "Что с 68.02?",
|
||||
"question_class": "ambiguous_fuzzy",
|
||||
"expected_route": "hybrid_store_plus_live",
|
||||
"actual_route": "hybrid_store_plus_live",
|
||||
"sources_used": [
|
||||
"canonical_store",
|
||||
"mcp_runtime_bridge"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 822,
|
||||
"planning_time_ms": 115,
|
||||
"retrieval_time_ms": 525,
|
||||
"response_generation_time_ms": 182,
|
||||
"context_size": 2951,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=hybrid_store_plus_live; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "acceptable",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
},
|
||||
{
|
||||
"question_id": "Q35",
|
||||
"question_text": "Проверить документы июня.",
|
||||
"question_class": "ambiguous_fuzzy",
|
||||
"expected_route": "store_feature_risk",
|
||||
"actual_route": "store_feature_risk",
|
||||
"sources_used": [
|
||||
"feature_store",
|
||||
"risk_store",
|
||||
"canonical_store"
|
||||
],
|
||||
"refresh_needed": false,
|
||||
"latency_ms": 405,
|
||||
"planning_time_ms": 86,
|
||||
"retrieval_time_ms": 156,
|
||||
"response_generation_time_ms": 163,
|
||||
"context_size": 2102,
|
||||
"answer_text": "[simulated-4o-mini-profile] route=store_feature_risk; answer synthesized from June-2020 slice + current stores.",
|
||||
"answer_quality_assessment": "acceptable",
|
||||
"route_quality_assessment": "good",
|
||||
"issues_detected": [],
|
||||
"recommended_fix": "No action required."
|
||||
}
|
||||
]
|
||||
}
|
||||
|
|
@ -1,27 +0,0 @@
|
|||
# LLM-like Simulation Profile
|
||||
|
||||
Simulation mode: `4o-mini-like` (controlled emulation)
|
||||
|
||||
## Constraints
|
||||
|
||||
- Store-first retrieval policy.
|
||||
- Compact planning and bounded context.
|
||||
- Limited live calls for drill-down only.
|
||||
- Avoid expensive heavy live scans.
|
||||
|
||||
## Route timing baseline (ms)
|
||||
|
||||
| Route | Planning | Retrieval | Generation | Context |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| live_mcp_drilldown | 95 | 780 | 180 | 2900 |
|
||||
| store_canonical | 70 | 170 | 130 | 1700 |
|
||||
| store_feature_risk | 82 | 190 | 150 | 2200 |
|
||||
| hybrid_store_plus_live | 112 | 560 | 170 | 3050 |
|
||||
| batch_refresh_then_store | 135 | 1240 | 210 | 3600 |
|
||||
|
||||
## Active run context
|
||||
|
||||
- Slice window: `2020-06`
|
||||
- Refresh latest run: `30b2a2da4d824e0b81c2fb263cb9b64b`
|
||||
- Feature latest run: `2d2dc33e509e4f5681b64217673dad09`
|
||||
- Risk latest run: `d4833f6aa39f4bb5b4897c3d48caa843`
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
# Ontology & Mapping Audit
|
||||
|
||||
## Core metrics
|
||||
|
||||
| Metric | Value |
|
||||
| --- | --- |
|
||||
| entity_classes_total | 42 |
|
||||
| covered_entity_classes | 33 |
|
||||
| uncovered_entity_classes | 9 |
|
||||
| relation_types_total | 1 |
|
||||
| correctly_typed_relations | 1602 |
|
||||
| unknown_relations | 1016 |
|
||||
| conflicting_mappings_count | 0 |
|
||||
| link_coverage_pct | 100.0 |
|
||||
| semantic_coverage_pct | 61.1917 |
|
||||
|
||||
## Top problematic source entity types
|
||||
|
||||
| Source entity | Unknown relations |
|
||||
| --- | --- |
|
||||
| AccumulationRegister_НДСПредъявленный_RecordType | 130 |
|
||||
| Document_СписаниеСРасчетногоСчета | 116 |
|
||||
| DocumentJournal_ЖурналОпераций | 114 |
|
||||
| AccumulationRegister_НДСЗаписиКнигиПродаж_RecordType | 92 |
|
||||
| DocumentJournal_БанковскиеВыписки | 90 |
|
||||
| DocumentJournal_ДокументыПоставщиков | 90 |
|
||||
| Document_РеализацияТоваровУслуг | 60 |
|
||||
| Document_ПоступлениеТоваровУслуг | 50 |
|
||||
| DocumentJournal_ДокументыПокупателей | 32 |
|
||||
| AccumulationRegister_НДФЛРасчетыСБюджетом_RecordType | 28 |
|
||||
| Document_СчетФактураВыданный | 25 |
|
||||
| AccumulationRegister_НДСЗаписиКнигиПокупок_RecordType | 24 |
|
||||
|
||||
## Top problematic relation fields
|
||||
|
||||
| Source field | Unknown relations |
|
||||
| --- | --- |
|
||||
| Ответственный_Key | 187 |
|
||||
| Ref | 168 |
|
||||
| Recorder | 147 |
|
||||
| Поставщик_Key | 78 |
|
||||
| ФизЛицо_Key | 49 |
|
||||
| Информация | 49 |
|
||||
| Покупатель_Key | 46 |
|
||||
| Валюта_Key | 34 |
|
||||
| СтатьяДвиженияДенежныхСредств_Key | 34 |
|
||||
| ПодразделениеДт_Key | 29 |
|
||||
| ОбособленноеПодразделение_Key | 18 |
|
||||
| Склад_Key | 16 |
|
||||
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
# Orchestration Policy Spec
|
||||
|
||||
## Decision tree
|
||||
|
||||
- exact object trace or posting chain -> `live_mcp_drilldown`
|
||||
- simple factual in loaded slice -> `store_canonical`
|
||||
- trend/anomaly/risk -> `store_feature_risk`
|
||||
- heavy whole-slice with freshness gap -> `batch_refresh_then_store`
|
||||
- low confidence fallback -> `hybrid_store_plus_live`
|
||||
|
||||
## Routing rules
|
||||
|
||||
- Prefer store answers when freshness allows.
|
||||
- Use live bridge only for drill-down evidence.
|
||||
- Do not run uncapped heavy live scans.
|
||||
- Trigger refresh/features/risk for stale context.
|
||||
- Apply retrieval/context budget before fallback.
|
||||
|
||||
## Source priorities
|
||||
|
||||
| Scenario | Priority order |
|
||||
| --- | --- |
|
||||
| simple_factual | canonical_store -> mcp_runtime_bridge |
|
||||
| drilldown_explain | mcp_runtime_bridge -> canonical_store |
|
||||
| period_trend | feature_store -> risk_store -> canonical_store |
|
||||
| anomaly_control | risk_store -> feature_store -> canonical_store |
|
||||
| heavy_analytical | batch_refresh_then_store -> feature_store -> risk_store |
|
||||
| ambiguous_fuzzy | feature_store -> canonical_store -> mcp_runtime_bridge |
|
||||
|
||||
## Timeout budget (ms)
|
||||
|
||||
| Budget | Value |
|
||||
| --- | --- |
|
||||
| planning | 200 |
|
||||
| retrieval_soft_limit | 1200 |
|
||||
| retrieval_hard_limit | 2500 |
|
||||
| response_generation | 600 |
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
# Slice Ingestion Report
|
||||
|
||||
Validation date: 2026-03-23T09:28:12.311411+00:00
|
||||
Slice window: `2020-06` (`2020-06-01T00:00:00+00:00` -> `2020-07-01T00:00:00+00:00`)
|
||||
|
||||
- Snapshot file: `X:\1C\NDC_1C\logs\pre_report_snapshot_2020_2020-06.json`
|
||||
- Profile file: `X:\1C\NDC_1C\logs\pre_report_activity_2020.json`
|
||||
- Snapshot entities: `467`
|
||||
- Snapshot links: `2618`
|
||||
- Refresh run id: `30b2a2da4d824e0b81c2fb263cb9b64b`
|
||||
- Entities written: `451`
|
||||
- Links written: `2586`
|
||||
- Checkpoints updated: `42`
|
||||
- Canonical entities total: `453`
|
||||
- Canonical links total: `2596`
|
||||
- Feature run status: `success`
|
||||
- Feature metrics written: `202`
|
||||
- Risk run status: `success`
|
||||
- Risk patterns written: `2`
|
||||
- Risk global score: `0.608542`
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
# Benchmark Final Verdict
|
||||
|
||||
## Verdict
|
||||
|
||||
`adopt_ready_for_pilot`
|
||||
|
||||
## Key numbers
|
||||
|
||||
- Questions total: `35`
|
||||
- Route mismatches: `1`
|
||||
- Degraded answers: `0`
|
||||
- Avg latency ms: `705.63`
|
||||
- p95 latency ms: `1571.9`
|
||||
|
||||
## Recommendation
|
||||
|
||||
1. Fix ontology unknown mapping hotspots.
|
||||
2. Tune heavy-route threshold (`store_feature_risk` vs `batch_refresh_then_store`).
|
||||
3. Implement full production orchestration runtime.
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
# Benchmark Questions (35)
|
||||
|
||||
| ID | Class | Expected route | Question |
|
||||
| --- | --- | --- | --- |
|
||||
| Q01 | simple_factual | store_canonical | Сальдо счета 68.02 за июнь 2020? |
|
||||
| Q02 | simple_factual | live_mcp_drilldown | Документ по номеру и его ссылка. |
|
||||
| Q03 | simple_factual | store_canonical | Типовая проводка по реализации. |
|
||||
| Q04 | simple_factual | store_canonical | Контрагент с максимумом оборота. |
|
||||
| Q05 | simple_factual | store_canonical | Договоры топ-контрагента. |
|
||||
| Q06 | drilldown_explain | hybrid_store_plus_live | Объясни сальдо через движения. |
|
||||
| Q07 | drilldown_explain | live_mcp_drilldown | Почему проводка на этот счет? |
|
||||
| Q08 | drilldown_explain | live_mcp_drilldown | Цепочка документ -> проводки -> субконто. |
|
||||
| Q09 | drilldown_explain | live_mcp_drilldown | Источник регистра для строки движения. |
|
||||
| Q10 | drilldown_explain | live_mcp_drilldown | Почему выбрано это субконто3? |
|
||||
| Q11 | cross_entity | hybrid_store_plus_live | Свяжи документы покупателей и проводки. |
|
||||
| Q12 | cross_entity | hybrid_store_plus_live | Свяжи контрагентов, договоры и проводки. |
|
||||
| Q13 | cross_entity | store_canonical | Номенклатура, склад, обороты за июнь. |
|
||||
| Q14 | cross_entity | hybrid_store_plus_live | Регистр и первичный документ. |
|
||||
| Q15 | cross_entity | store_canonical | По счету: контрагенты и договоры. |
|
||||
| Q16 | period_trend | store_feature_risk | Обороты июня против мая. |
|
||||
| Q17 | period_trend | store_feature_risk | Недельные всплески в июне. |
|
||||
| Q18 | period_trend | store_feature_risk | Кто дал резкий рост активности. |
|
||||
| Q19 | period_trend | store_feature_risk | Аномальный рост расходных операций? |
|
||||
| Q20 | period_trend | store_feature_risk | Динамика НДС к соседним периодам. |
|
||||
| Q21 | anomaly_control | store_feature_risk | Нетипичные корреспонденции счетов. |
|
||||
| Q22 | anomaly_control | store_feature_risk | Незакрытые хвосты по расчетам. |
|
||||
| Q23 | anomaly_control | store_feature_risk | Дублирующиеся проводки. |
|
||||
| Q24 | anomaly_control | store_feature_risk | Пустые или странные субконто. |
|
||||
| Q25 | anomaly_control | store_feature_risk | Узлы с подозрительно большим degree. |
|
||||
| Q26 | heavy_analytical | batch_refresh_then_store | Полный риск-срез за июнь. |
|
||||
| Q27 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-счетов. |
|
||||
| Q28 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-контрагентов. |
|
||||
| Q29 | heavy_analytical | store_feature_risk | Baseline closed/open periods. |
|
||||
| Q30 | heavy_analytical | batch_refresh_then_store | Company anomaly summary. |
|
||||
| Q31 | ambiguous_fuzzy | store_feature_risk | Что по налогам и рискам? |
|
||||
| Q32 | ambiguous_fuzzy | store_feature_risk | Что странное в расходах? |
|
||||
| Q33 | ambiguous_fuzzy | store_feature_risk | Самые рисковые контрагенты? |
|
||||
| Q34 | ambiguous_fuzzy | hybrid_store_plus_live | Что с 68.02? |
|
||||
| Q35 | ambiguous_fuzzy | store_feature_risk | Проверить документы июня. |
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
# Benchmark Route Analysis
|
||||
|
||||
- Total mismatches: `1`
|
||||
|
||||
## Route confusion matrix
|
||||
|
||||
- `batch_refresh_then_store` -> batch_refresh_then_store:4
|
||||
- `hybrid_store_plus_live` -> hybrid_store_plus_live:5
|
||||
- `live_mcp_drilldown` -> live_mcp_drilldown:5
|
||||
- `store_canonical` -> store_canonical:6
|
||||
- `store_feature_risk` -> batch_refresh_then_store:1, store_feature_risk:14
|
||||
|
||||
## Mismatch by class
|
||||
|
||||
| Class | Mismatch count |
|
||||
| --- | --- |
|
||||
| period_trend | 1 |
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
# Benchmark Run Report
|
||||
|
||||
## Aggregate statistics
|
||||
|
||||
| Metric | Value |
|
||||
| --- | --- |
|
||||
| questions_total | 35 |
|
||||
| avg_latency_ms | 705.63 |
|
||||
| median_latency_ms | 405 |
|
||||
| p90_latency_ms | 1562.0 |
|
||||
| p95_latency_ms | 1571.9 |
|
||||
| avg_context_size | 2435.37 |
|
||||
| live_route_count | 10 |
|
||||
| store_route_count | 20 |
|
||||
| batch_route_count | 5 |
|
||||
| route_mismatch_count | 1 |
|
||||
| degraded_answers_count | 0 |
|
||||
|
||||
## Route distribution
|
||||
|
||||
| Route | Count |
|
||||
| --- | --- |
|
||||
| batch_refresh_then_store | 5 |
|
||||
| hybrid_store_plus_live | 5 |
|
||||
| live_mcp_drilldown | 5 |
|
||||
| store_canonical | 6 |
|
||||
| store_feature_risk | 14 |
|
||||
|
||||
## Question class distribution
|
||||
|
||||
| Class | Count |
|
||||
| --- | --- |
|
||||
| ambiguous_fuzzy | 5 |
|
||||
| anomaly_control | 5 |
|
||||
| cross_entity | 5 |
|
||||
| drilldown_explain | 5 |
|
||||
| heavy_analytical | 5 |
|
||||
| period_trend | 5 |
|
||||
| simple_factual | 5 |
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,27 +0,0 @@
|
|||
# LLM-like Simulation Profile
|
||||
|
||||
Simulation mode: `4o-mini-like` (controlled emulation)
|
||||
|
||||
## Constraints
|
||||
|
||||
- Store-first retrieval policy.
|
||||
- Compact planning and bounded context.
|
||||
- Limited live calls for drill-down only.
|
||||
- Avoid expensive heavy live scans.
|
||||
|
||||
## Route timing baseline (ms)
|
||||
|
||||
| Route | Planning | Retrieval | Generation | Context |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| live_mcp_drilldown | 95 | 780 | 180 | 2900 |
|
||||
| store_canonical | 70 | 170 | 130 | 1700 |
|
||||
| store_feature_risk | 82 | 190 | 150 | 2200 |
|
||||
| hybrid_store_plus_live | 112 | 560 | 170 | 3050 |
|
||||
| batch_refresh_then_store | 135 | 1240 | 210 | 3600 |
|
||||
|
||||
## Active run context
|
||||
|
||||
- Slice window: `2020-06`
|
||||
- Refresh latest run: `6f6c622c254e4e79a86ccdbd140b1631`
|
||||
- Feature latest run: `c1daa35506474be19331f21cf663282a`
|
||||
- Risk latest run: `b167c610c8b84dd79ca0357e72422c7f`
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
# Ontology & Mapping Audit
|
||||
|
||||
## Core metrics
|
||||
|
||||
| Metric | Value |
|
||||
| --- | --- |
|
||||
| entity_classes_total | 42 |
|
||||
| covered_entity_classes | 42 |
|
||||
| uncovered_entity_classes | 0 |
|
||||
| relation_types_total | 25 |
|
||||
| correctly_typed_relations | 1909 |
|
||||
| unknown_relations | 102 |
|
||||
| conflicting_mappings_count | 1 |
|
||||
| link_coverage_pct | 100.0 |
|
||||
| semantic_coverage_pct | 94.9279 |
|
||||
|
||||
## Top problematic source entity types
|
||||
|
||||
| Source entity | Unknown relations |
|
||||
| --- | --- |
|
||||
| DocumentJournal_БанковскиеВыписки | 30 |
|
||||
| DocumentJournal_ЖурналОпераций | 16 |
|
||||
| Document_СписаниеСРасчетногоСчета | 14 |
|
||||
| Document_РеализацияТоваровУслуг | 12 |
|
||||
| Document_СчетФактураВыданный | 8 |
|
||||
| Document_ОперацияБух | 5 |
|
||||
| AccumulationRegister_СтраховыеВзносыСведенияОДоходах_RecordType | 4 |
|
||||
| DocumentJournal_КассовыеДокументы | 4 |
|
||||
| Document_РасходныйКассовыйОрдер | 4 |
|
||||
| AccumulationRegister_НДФЛСведенияОДоходах_RecordType | 3 |
|
||||
| AccumulationRegister_НДФЛПредоставленныеСтандартныеВычетыФизЛиц_RecordType | 1 |
|
||||
| Document_СчетНаОплатуПокупателю | 1 |
|
||||
|
||||
## Top problematic relation fields
|
||||
|
||||
| Source field | Unknown relations |
|
||||
| --- | --- |
|
||||
| ВидОперации | 34 |
|
||||
| Информация | 16 |
|
||||
| СубконтоДт1 | 15 |
|
||||
| Руководитель_Key | 8 |
|
||||
| ГлавныйБухгалтер_Key | 8 |
|
||||
| СпособЗаполнения | 5 |
|
||||
| ВидДохода_Key | 4 |
|
||||
| СтатьяДоходовИРасходовПоТаре_Key | 4 |
|
||||
| КодДохода_Key | 3 |
|
||||
| СубконтоДт2 | 3 |
|
||||
| КодВычета_Key | 1 |
|
||||
| СтруктурнаяЕдиница_Key | 1 |
|
||||
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
# Orchestration Policy Spec
|
||||
|
||||
## Decision tree
|
||||
|
||||
- exact object trace or posting chain -> `live_mcp_drilldown`
|
||||
- simple factual in loaded slice -> `store_canonical`
|
||||
- trend/anomaly/risk -> `store_feature_risk`
|
||||
- heavy whole-slice with freshness gap -> `batch_refresh_then_store`
|
||||
- low confidence fallback -> `hybrid_store_plus_live`
|
||||
|
||||
## Routing rules
|
||||
|
||||
- Prefer store answers when freshness allows.
|
||||
- Use live bridge only for drill-down evidence.
|
||||
- Do not run uncapped heavy live scans.
|
||||
- Trigger refresh/features/risk for stale context.
|
||||
- Apply retrieval/context budget before fallback.
|
||||
|
||||
## Source priorities
|
||||
|
||||
| Scenario | Priority order |
|
||||
| --- | --- |
|
||||
| simple_factual | canonical_store -> mcp_runtime_bridge |
|
||||
| drilldown_explain | mcp_runtime_bridge -> canonical_store |
|
||||
| period_trend | feature_store -> risk_store -> canonical_store |
|
||||
| anomaly_control | risk_store -> feature_store -> canonical_store |
|
||||
| heavy_analytical | batch_refresh_then_store -> feature_store -> risk_store |
|
||||
| ambiguous_fuzzy | feature_store -> canonical_store -> mcp_runtime_bridge |
|
||||
|
||||
## Timeout budget (ms)
|
||||
|
||||
| Budget | Value |
|
||||
| --- | --- |
|
||||
| planning | 200 |
|
||||
| retrieval_soft_limit | 1200 |
|
||||
| retrieval_hard_limit | 2500 |
|
||||
| response_generation | 600 |
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,20 +0,0 @@
|
|||
# Slice Ingestion Report
|
||||
|
||||
Validation date: 2026-03-23T11:04:31.558207+00:00
|
||||
Slice window: `2020-06` (`2020-06-01T00:00:00+00:00` -> `2020-07-01T00:00:00+00:00`)
|
||||
|
||||
- Snapshot file: `logs\pre_report_snapshot_2020_2020-06_semantic_v2.json`
|
||||
- Profile file: `X:\1C\NDC_1C\logs\pre_report_activity_2020.json`
|
||||
- Snapshot entities: `409`
|
||||
- Snapshot links: `2011`
|
||||
- Refresh run id: `6f6c622c254e4e79a86ccdbd140b1631`
|
||||
- Entities written: `409`
|
||||
- Links written: `2011`
|
||||
- Checkpoints updated: `42`
|
||||
- Canonical entities total: `769`
|
||||
- Canonical links total: `3700`
|
||||
- Feature run status: `success`
|
||||
- Feature metrics written: `202`
|
||||
- Risk run status: `success`
|
||||
- Risk patterns written: `2`
|
||||
- Risk global score: `0.977351`
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
# Benchmark Final Verdict
|
||||
|
||||
## Verdict
|
||||
|
||||
`adopt_ready_for_pilot`
|
||||
|
||||
## Key numbers
|
||||
|
||||
- Questions total: `35`
|
||||
- Route mismatches: `0`
|
||||
- Degraded answers: `0`
|
||||
- Avg latency ms: `672.4`
|
||||
- p95 latency ms: `1568.9`
|
||||
|
||||
## Recommendation
|
||||
|
||||
1. Fix ontology unknown mapping hotspots.
|
||||
2. Tune heavy-route threshold (`store_feature_risk` vs `batch_refresh_then_store`).
|
||||
3. Implement full production orchestration runtime.
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
# Benchmark Questions (35)
|
||||
|
||||
| ID | Class | Expected route | Question |
|
||||
| --- | --- | --- | --- |
|
||||
| Q01 | simple_factual | store_canonical | Сальдо счета 68.02 за июнь 2020? |
|
||||
| Q02 | simple_factual | live_mcp_drilldown | Документ по номеру и его ссылка. |
|
||||
| Q03 | simple_factual | store_canonical | Типовая проводка по реализации. |
|
||||
| Q04 | simple_factual | store_canonical | Контрагент с максимумом оборота. |
|
||||
| Q05 | simple_factual | store_canonical | Договоры топ-контрагента. |
|
||||
| Q06 | drilldown_explain | hybrid_store_plus_live | Объясни сальдо через движения. |
|
||||
| Q07 | drilldown_explain | live_mcp_drilldown | Почему проводка на этот счет? |
|
||||
| Q08 | drilldown_explain | live_mcp_drilldown | Цепочка документ -> проводки -> субконто. |
|
||||
| Q09 | drilldown_explain | live_mcp_drilldown | Источник регистра для строки движения. |
|
||||
| Q10 | drilldown_explain | live_mcp_drilldown | Почему выбрано это субконто3? |
|
||||
| Q11 | cross_entity | hybrid_store_plus_live | Свяжи документы покупателей и проводки. |
|
||||
| Q12 | cross_entity | hybrid_store_plus_live | Свяжи контрагентов, договоры и проводки. |
|
||||
| Q13 | cross_entity | store_canonical | Номенклатура, склад, обороты за июнь. |
|
||||
| Q14 | cross_entity | hybrid_store_plus_live | Регистр и первичный документ. |
|
||||
| Q15 | cross_entity | store_canonical | По счету: контрагенты и договоры. |
|
||||
| Q16 | period_trend | store_feature_risk | Обороты июня против мая. |
|
||||
| Q17 | period_trend | store_feature_risk | Недельные всплески в июне. |
|
||||
| Q18 | period_trend | store_feature_risk | Кто дал резкий рост активности. |
|
||||
| Q19 | period_trend | store_feature_risk | Аномальный рост расходных операций? |
|
||||
| Q20 | period_trend | store_feature_risk | Динамика НДС к соседним периодам. |
|
||||
| Q21 | anomaly_control | store_feature_risk | Нетипичные корреспонденции счетов. |
|
||||
| Q22 | anomaly_control | store_feature_risk | Незакрытые хвосты по расчетам. |
|
||||
| Q23 | anomaly_control | store_feature_risk | Дублирующиеся проводки. |
|
||||
| Q24 | anomaly_control | store_feature_risk | Пустые или странные субконто. |
|
||||
| Q25 | anomaly_control | store_feature_risk | Узлы с подозрительно большим degree. |
|
||||
| Q26 | heavy_analytical | batch_refresh_then_store | Полный риск-срез за июнь. |
|
||||
| Q27 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-счетов. |
|
||||
| Q28 | heavy_analytical | batch_refresh_then_store | Рейтинг риск-контрагентов. |
|
||||
| Q29 | heavy_analytical | store_feature_risk | Baseline closed/open periods. |
|
||||
| Q30 | heavy_analytical | batch_refresh_then_store | Company anomaly summary. |
|
||||
| Q31 | ambiguous_fuzzy | store_feature_risk | Что по налогам и рискам? |
|
||||
| Q32 | ambiguous_fuzzy | store_feature_risk | Что странное в расходах? |
|
||||
| Q33 | ambiguous_fuzzy | store_feature_risk | Самые рисковые контрагенты? |
|
||||
| Q34 | ambiguous_fuzzy | hybrid_store_plus_live | Что с 68.02? |
|
||||
| Q35 | ambiguous_fuzzy | store_feature_risk | Проверить документы июня. |
|
||||
|
|
@ -1,17 +0,0 @@
|
|||
# Benchmark Route Analysis
|
||||
|
||||
- Total mismatches: `0`
|
||||
|
||||
## Route confusion matrix
|
||||
|
||||
- `batch_refresh_then_store` -> batch_refresh_then_store:4
|
||||
- `hybrid_store_plus_live` -> hybrid_store_plus_live:5
|
||||
- `live_mcp_drilldown` -> live_mcp_drilldown:5
|
||||
- `store_canonical` -> store_canonical:6
|
||||
- `store_feature_risk` -> store_feature_risk:15
|
||||
|
||||
## Mismatch by class
|
||||
|
||||
| Class | Mismatch count |
|
||||
| --- | --- |
|
||||
| n/a | 0 |
|
||||
|
|
@ -1,39 +0,0 @@
|
|||
# Benchmark Run Report
|
||||
|
||||
## Aggregate statistics
|
||||
|
||||
| Metric | Value |
|
||||
| --- | --- |
|
||||
| questions_total | 35 |
|
||||
| avg_latency_ms | 672.4 |
|
||||
| median_latency_ms | 405 |
|
||||
| p90_latency_ms | 1348.2 |
|
||||
| p95_latency_ms | 1568.9 |
|
||||
| avg_context_size | 2395.37 |
|
||||
| live_route_count | 10 |
|
||||
| store_route_count | 21 |
|
||||
| batch_route_count | 4 |
|
||||
| route_mismatch_count | 0 |
|
||||
| degraded_answers_count | 0 |
|
||||
|
||||
## Route distribution
|
||||
|
||||
| Route | Count |
|
||||
| --- | --- |
|
||||
| batch_refresh_then_store | 4 |
|
||||
| hybrid_store_plus_live | 5 |
|
||||
| live_mcp_drilldown | 5 |
|
||||
| store_canonical | 6 |
|
||||
| store_feature_risk | 15 |
|
||||
|
||||
## Question class distribution
|
||||
|
||||
| Class | Count |
|
||||
| --- | --- |
|
||||
| ambiguous_fuzzy | 5 |
|
||||
| anomaly_control | 5 |
|
||||
| cross_entity | 5 |
|
||||
| drilldown_explain | 5 |
|
||||
| heavy_analytical | 5 |
|
||||
| period_trend | 5 |
|
||||
| simple_factual | 5 |
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,27 +0,0 @@
|
|||
# LLM-like Simulation Profile
|
||||
|
||||
Simulation mode: `4o-mini-like` (controlled emulation)
|
||||
|
||||
## Constraints
|
||||
|
||||
- Store-first retrieval policy.
|
||||
- Compact planning and bounded context.
|
||||
- Limited live calls for drill-down only.
|
||||
- Avoid expensive heavy live scans.
|
||||
|
||||
## Route timing baseline (ms)
|
||||
|
||||
| Route | Planning | Retrieval | Generation | Context |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| live_mcp_drilldown | 95 | 780 | 180 | 2900 |
|
||||
| store_canonical | 70 | 170 | 130 | 1700 |
|
||||
| store_feature_risk | 82 | 190 | 150 | 2200 |
|
||||
| hybrid_store_plus_live | 112 | 560 | 170 | 3050 |
|
||||
| batch_refresh_then_store | 135 | 1240 | 210 | 3600 |
|
||||
|
||||
## Active run context
|
||||
|
||||
- Slice window: `2020-06`
|
||||
- Refresh latest run: `44b9881f29f343d7816b89ddf3e4a6ec`
|
||||
- Feature latest run: `ce3a6385d6fd43f480ddf9b499c76e7a`
|
||||
- Risk latest run: `0895566641a74a44adf19faa5dc4f385`
|
||||
|
|
@ -1,50 +0,0 @@
|
|||
# Ontology & Mapping Audit
|
||||
|
||||
## Core metrics
|
||||
|
||||
| Metric | Value |
|
||||
| --- | --- |
|
||||
| entity_classes_total | 42 |
|
||||
| covered_entity_classes | 42 |
|
||||
| uncovered_entity_classes | 0 |
|
||||
| relation_types_total | 25 |
|
||||
| correctly_typed_relations | 1909 |
|
||||
| unknown_relations | 102 |
|
||||
| conflicting_mappings_count | 1 |
|
||||
| link_coverage_pct | 100.0 |
|
||||
| semantic_coverage_pct | 94.9279 |
|
||||
|
||||
## Top problematic source entity types
|
||||
|
||||
| Source entity | Unknown relations |
|
||||
| --- | --- |
|
||||
| DocumentJournal_БанковскиеВыписки | 30 |
|
||||
| DocumentJournal_ЖурналОпераций | 16 |
|
||||
| Document_СписаниеСРасчетногоСчета | 14 |
|
||||
| Document_РеализацияТоваровУслуг | 12 |
|
||||
| Document_СчетФактураВыданный | 8 |
|
||||
| Document_ОперацияБух | 5 |
|
||||
| AccumulationRegister_СтраховыеВзносыСведенияОДоходах_RecordType | 4 |
|
||||
| DocumentJournal_КассовыеДокументы | 4 |
|
||||
| Document_РасходныйКассовыйОрдер | 4 |
|
||||
| AccumulationRegister_НДФЛСведенияОДоходах_RecordType | 3 |
|
||||
| AccumulationRegister_НДФЛПредоставленныеСтандартныеВычетыФизЛиц_RecordType | 1 |
|
||||
| Document_СчетНаОплатуПокупателю | 1 |
|
||||
|
||||
## Top problematic relation fields
|
||||
|
||||
| Source field | Unknown relations |
|
||||
| --- | --- |
|
||||
| ВидОперации | 34 |
|
||||
| Информация | 16 |
|
||||
| СубконтоДт1 | 15 |
|
||||
| Руководитель_Key | 8 |
|
||||
| ГлавныйБухгалтер_Key | 8 |
|
||||
| СпособЗаполнения | 5 |
|
||||
| ВидДохода_Key | 4 |
|
||||
| СтатьяДоходовИРасходовПоТаре_Key | 4 |
|
||||
| КодДохода_Key | 3 |
|
||||
| СубконтоДт2 | 3 |
|
||||
| КодВычета_Key | 1 |
|
||||
| СтруктурнаяЕдиница_Key | 1 |
|
||||
|
||||
|
|
@ -1,37 +0,0 @@
|
|||
# Orchestration Policy Spec
|
||||
|
||||
## Decision tree
|
||||
|
||||
- exact object trace or posting chain -> `live_mcp_drilldown`
|
||||
- simple factual in loaded slice -> `store_canonical`
|
||||
- trend/anomaly/risk -> `store_feature_risk`
|
||||
- heavy whole-slice with freshness gap -> `batch_refresh_then_store`
|
||||
- low confidence fallback -> `hybrid_store_plus_live`
|
||||
|
||||
## Routing rules
|
||||
|
||||
- Prefer store answers when freshness allows.
|
||||
- Use live bridge only for drill-down evidence.
|
||||
- Do not run uncapped heavy live scans.
|
||||
- Trigger refresh/features/risk for stale context.
|
||||
- Apply retrieval/context budget before fallback.
|
||||
|
||||
## Source priorities
|
||||
|
||||
| Scenario | Priority order |
|
||||
| --- | --- |
|
||||
| simple_factual | canonical_store -> mcp_runtime_bridge |
|
||||
| drilldown_explain | mcp_runtime_bridge -> canonical_store |
|
||||
| period_trend | feature_store -> risk_store -> canonical_store |
|
||||
| anomaly_control | risk_store -> feature_store -> canonical_store |
|
||||
| heavy_analytical | batch_refresh_then_store -> feature_store -> risk_store |
|
||||
| ambiguous_fuzzy | feature_store -> canonical_store -> mcp_runtime_bridge |
|
||||
|
||||
## Timeout budget (ms)
|
||||
|
||||
| Budget | Value |
|
||||
| --- | --- |
|
||||
| planning | 200 |
|
||||
| retrieval_soft_limit | 1200 |
|
||||
| retrieval_hard_limit | 2500 |
|
||||
| response_generation | 600 |
|
||||
File diff suppressed because it is too large
Load Diff
|
|
@ -1,20 +0,0 @@
|
|||
# Slice Ingestion Report
|
||||
|
||||
Validation date: 2026-03-23T11:09:29.880582+00:00
|
||||
Slice window: `2020-06` (`2020-06-01T00:00:00+00:00` -> `2020-07-01T00:00:00+00:00`)
|
||||
|
||||
- Snapshot file: `logs\pre_report_snapshot_2020_2020-06_semantic_v2.json`
|
||||
- Profile file: `X:\1C\NDC_1C\logs\pre_report_activity_2020.json`
|
||||
- Snapshot entities: `409`
|
||||
- Snapshot links: `2011`
|
||||
- Refresh run id: `44b9881f29f343d7816b89ddf3e4a6ec`
|
||||
- Entities written: `409`
|
||||
- Links written: `2011`
|
||||
- Checkpoints updated: `42`
|
||||
- Canonical entities total: `769`
|
||||
- Canonical links total: `3700`
|
||||
- Feature run status: `success`
|
||||
- Feature metrics written: `202`
|
||||
- Risk run status: `success`
|
||||
- Risk patterns written: `2`
|
||||
- Risk global score: `0.977351`
|
||||
|
|
@ -1,19 +0,0 @@
|
|||
# Benchmark Final Verdict
|
||||
|
||||
## Verdict
|
||||
|
||||
`adopt_with_improvements`
|
||||
|
||||
## Key numbers
|
||||
|
||||
- Questions total: `35`
|
||||
- Route mismatches: `7`
|
||||
- Degraded answers: `0`
|
||||
- Avg latency ms: `506.43`
|
||||
- p95 latency ms: `1024.5`
|
||||
|
||||
## Recommendation
|
||||
|
||||
1. Fix ontology unknown mapping hotspots.
|
||||
2. Tune heavy-route threshold (`store_feature_risk` vs `batch_refresh_then_store`).
|
||||
3. Implement full production orchestration runtime.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue