Этап 4 / Волна 18 закрытие блокеров по времени, доменной полярности и допуску доказательной базы
This commit is contained in:
@@ -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,
|
||||
* и ясный ответ, **что у нас вообще реально работает после вопроса пользователя**.
|
||||
|
||||
---
|
||||
|
||||
|
||||
Reference in New Issue
Block a user