SILVER
/
NODEDC_1C
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
NODEDC_1C/IN/ssistant_runtime_ground_tru...

20 KiB
Raw Permalink Blame History

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,
  • и ясный ответ, что у нас вообще реально работает после вопроса пользователя.