315 lines
11 KiB
Markdown
315 lines
11 KiB
Markdown
# Этап 4 — corrective pack по family isolation, claim routing и чистой приемке
|
||
|
||
## 1. Контекст
|
||
|
||
Stage 4 уже работает в `family-based execution`:
|
||
|
||
- единица анализа: `family`;
|
||
- единица реализации: `family pack`;
|
||
- единица приемки: `family acceptance`.
|
||
|
||
По трем новым прогонам подтверждено: основная проблема в runtime не текстовая, а маршрутизационная:
|
||
|
||
- leakage между family/lane;
|
||
- неправильный `claim_type` на корректных вопросах;
|
||
- рассинхрон между route/domain/claim в разных слоях runtime;
|
||
- смешанные acceptance-файлы, где трудно объективно мерить качество lane/family.
|
||
|
||
## 2. Архитектурная рамка corrective pack
|
||
|
||
Чтобы пакет был совместим с текущим проектом, фиксируем:
|
||
|
||
1. `core families` Stage 4:
|
||
`VAT chain`, `RBP tail`, `FA amortization`.
|
||
2. `control lanes` (regression/sanity, не first-class family):
|
||
`settlements_60_62`, `month_close_indirect_costs`.
|
||
3. Пакет не добавляет новые домены и не меняет Stage 4 модель.
|
||
4. Пакет не строит новый proof engine и не уводит в Stage 5.
|
||
|
||
## 3. Цель corrective pack
|
||
|
||
Привести execution к состоянию, где:
|
||
|
||
1. вопрос из одного family/lane не уходит в чужой `claim/domain path`;
|
||
2. routing в live и follow-up не расходится между runtime-слоями;
|
||
3. acceptance выполняется по чистым family/lane файлам;
|
||
4. `false_grounded_answer_rate = 0`;
|
||
5. `wrong_family_route_rate = 0` на контрольном наборе этого pack.
|
||
|
||
## 4. Подволны
|
||
|
||
### Подволна 1 — Family isolation matrix
|
||
|
||
#### Задача
|
||
|
||
Снять матрицу соответствия вопроса и целевого family/lane, и явно показать точки leakage.
|
||
|
||
#### Что сделать
|
||
|
||
Построить матрицу по контрольным вопросам из трех файлов:
|
||
|
||
- `расчеты банк 60 62.txt`
|
||
- `ндс книга покупок и продаж.txt`
|
||
- `рбп затраты аморт.txt`
|
||
|
||
Для каждого вопроса зафиксировать:
|
||
|
||
- `raw_question`
|
||
- `expected_lane_type` (`core_family` | `control_lane`)
|
||
- `expected_family_or_lane`
|
||
- `expected_domain`
|
||
- `expected_claim_type`
|
||
- `actual_domain`
|
||
- `actual_claim_type`
|
||
- `actual_query_subject`
|
||
- `actual_source_profile`
|
||
- `actual_business_scope`
|
||
- `mismatch_type`
|
||
|
||
Минимальные lane:
|
||
|
||
1. `settlements_60_62` (control lane)
|
||
2. `VAT chain` (core family)
|
||
3. `RBP tail` (core family)
|
||
4. `FA amortization` (core family)
|
||
5. `month_close_indirect_costs` (control/sanity lane)
|
||
|
||
#### Acceptance
|
||
|
||
Есть явная матрица:
|
||
|
||
- что относится к core family, а что к control lane;
|
||
- где и почему происходит leakage.
|
||
|
||
### Подволна 2 — Claim routing + domain purity alignment
|
||
|
||
#### Задача
|
||
|
||
Устранить переходы:
|
||
|
||
- settlement -> VAT claim;
|
||
- settlement -> FA claim;
|
||
- VAT -> settlement guard path;
|
||
- month-close -> случайный FA/RBP claim без основания.
|
||
|
||
#### Что сделать
|
||
|
||
##### A. Синхронизировать domain inference между слоями
|
||
|
||
Унифицировать доменную классификацию для:
|
||
|
||
- `assistantService` domain hint;
|
||
- `investigationState` explicit domain hint;
|
||
- follow-up cross-scope checks.
|
||
|
||
Цель: один и тот же вопрос не должен получать разные домены в разных слоях runtime.
|
||
|
||
##### B. Ужесточить claim inference для settlement/VAT/FA
|
||
|
||
1. Settlement/advance/closure не должны резолвиться в:
|
||
|
||
- `prove_vat_chain_completeness`;
|
||
- `prove_fixed_asset_amortization_coverage`.
|
||
|
||
2. Убрать ложный FA-триггер на числовых артефактах:
|
||
|
||
- числа из дат/сумм не должны поднимать FA claim;
|
||
- `62.02` не должен теряться как `amount_token` в settlement flow.
|
||
|
||
3. FA claim допускается только при явном FA-сигнале:
|
||
|
||
- лексический FA-сигнал;
|
||
- или валидные account/object anchors после account extraction cleanup.
|
||
|
||
##### C. Привязать `query_subject` к resolved family/lane
|
||
|
||
`query_subject` должен строиться от resolved route/domain/claim, а не от сырого mixed-domain списка.
|
||
|
||
Практический эффект:
|
||
|
||
- VAT не должен уходить в `supplier_tail_analysis`;
|
||
- settlement не должен маскироваться под VAT/FA path.
|
||
|
||
##### D. Сохранить рабочий RBP path
|
||
|
||
Не ломать поднятый RBP контракт:
|
||
|
||
- `claim_type = prove_rbp_tail_state`;
|
||
- обязательный live recipe;
|
||
- non-zero admissible evidence path.
|
||
|
||
##### E. Для FA использовать route-lock/parity контроль
|
||
|
||
FA в этом паке контролируется через:
|
||
|
||
- `claim-route lock`;
|
||
- `mock/live parity` по целевым FA вопросам;
|
||
|
||
а не через прямую метрику domain-card purity 1:1.
|
||
|
||
#### Acceptance
|
||
|
||
На контрольном наборе pack:
|
||
|
||
- `wrong_family_route_rate = 0`;
|
||
- `wrong_claim_type_rate = 0`;
|
||
- `domain_purity_guard_lane_match_rate = 1.0` для lanes с domain-card (`settlements`, `VAT`, `month_close`);
|
||
- `fa_route_lock_correctness_rate >= 0.95`;
|
||
- `supplier_customer_polarity` не остается unresolved на core settlement cases.
|
||
|
||
### Подволна 3 — Чистая структура acceptance-прогонов
|
||
|
||
#### Задача
|
||
|
||
Убрать смешанные acceptance-файлы.
|
||
|
||
#### Что сделать
|
||
|
||
Собрать отдельные прогоны:
|
||
|
||
1. `chat_export_settlements.txt` (control lane)
|
||
2. `chat_export_vat.txt` (core family)
|
||
3. `chat_export_rbp.txt` (core family)
|
||
4. `chat_export_fa.txt` (core family)
|
||
5. `chat_export_month_close_sanity.txt` (control lane)
|
||
|
||
Правило:
|
||
|
||
- один файл = один family/lane;
|
||
- mixed files не используются как family acceptance.
|
||
|
||
#### Acceptance
|
||
|
||
Все acceptance-артефакты lane-clean и сопоставимы между волнами.
|
||
|
||
### Подволна 4 — Final live rerun по изолированным lanes
|
||
|
||
#### Задача
|
||
|
||
Пересобрать финальный live rerun после исправления isolation/routing.
|
||
|
||
#### Обязательный набор кейсов
|
||
|
||
`settlements_60_62` (control lane):
|
||
|
||
1. supplier settlement (`55 200`)
|
||
2. buyer advance (`62.02`)
|
||
3. closure case без суммы
|
||
4. follow-up по тому же договору/документу
|
||
|
||
`VAT chain`:
|
||
|
||
1. услуги связи (`1 166,67 + НДС 233,33`)
|
||
2. счет-фактура / книга покупок
|
||
3. выпадение между документом и книгой
|
||
4. follow-up по той же VAT-цепочке
|
||
|
||
`RBP tail`:
|
||
|
||
1. `Списание РБП за Июль 2020` (`5 000`)
|
||
2. вариант без суммы
|
||
3. полнота закрытия
|
||
4. follow-up по объекту/документу
|
||
|
||
`FA amortization`:
|
||
|
||
1. `2 471,52 / 2 465,28 / 849,83`
|
||
2. expected vs actual set
|
||
3. missing object risk
|
||
4. follow-up по объекту ОС
|
||
|
||
`month_close_indirect_costs` (control lane):
|
||
|
||
1. базовый вопрос по косвенным расходам
|
||
2. зависший хвост
|
||
3. limitation-honesty после полного month-end
|
||
|
||
#### Acceptance
|
||
|
||
Новый live rerun показывает:
|
||
|
||
- route/claim isolation без cross-family leakage;
|
||
- корректную lane-классификацию;
|
||
- честный limited mode только по фактической нехватке данных.
|
||
|
||
## 5. Метрики corrective pack
|
||
|
||
### Добавить/вывести
|
||
|
||
- `wrong_family_route_rate`
|
||
- `wrong_claim_type_rate`
|
||
- `domain_purity_guard_lane_match_rate`
|
||
- `fa_route_lock_correctness_rate`
|
||
- `family_isolation_correctness_rate`
|
||
- `live_recipe_binding_rate`
|
||
- `false_grounded_answer_rate`
|
||
- `mechanism_discrimination_rate`
|
||
- `limited_answer_honesty_rate`
|
||
|
||
### Минимальные пороги (для контрольного набора этого pack)
|
||
|
||
- `wrong_family_route_rate = 0`
|
||
- `wrong_claim_type_rate = 0`
|
||
- `domain_purity_guard_lane_match_rate = 1.0` (для lanes с domain-card)
|
||
- `fa_route_lock_correctness_rate >= 0.95`
|
||
- `false_grounded_answer_rate = 0`
|
||
- `mechanism_discrimination_rate >= 0.90`
|
||
- `limited_answer_honesty_rate >= 0.95`
|
||
|
||
## 6. Что создать
|
||
|
||
### В `docs/ARCH`
|
||
|
||
1. `10 - family_isolation_and_claim_routing_corrective_pack_2026-03-29.md`
|
||
2. `10A - family_isolation_matrix.md`
|
||
3. `10B - wrong_claim_route_register.md`
|
||
4. `10C - clean_family_run_structure.md`
|
||
5. `10D - family_acceptance_policy_update.md`
|
||
6. `10E - cross_layer_domain_inference_parity.md`
|
||
|
||
### В `llm_normalizer/docs/runs/<new_run_pack>`
|
||
|
||
1. `run_summary.json`
|
||
2. `before_after_metrics.json`
|
||
3. `family_case_matrix.md`
|
||
4. `acceptance_note.md`
|
||
5. `chat_export_settlements.txt`
|
||
6. `chat_export_vat.txt`
|
||
7. `chat_export_rbp.txt`
|
||
8. `chat_export_fa.txt`
|
||
9. `chat_export_month_close_sanity.txt`
|
||
10. `debug_payloads/`
|
||
11. `routing_parity_diff.md`
|
||
|
||
## 7. Что нельзя делать
|
||
|
||
- не добавлять новые домены;
|
||
- не менять Stage 4 family-based model;
|
||
- не строить новый proof engine;
|
||
- не смешивать acceptance разных family/lane в одном файле;
|
||
- не закрывать acceptance по одному удачному ответу;
|
||
- не лечить leakage общим ростом generic retrieval.
|
||
|
||
## 8. Финальный verdict
|
||
|
||
Выдать:
|
||
|
||
- `FAMILY_ISOLATION_FIXED / NOT_FIXED`
|
||
- `CLAIM_ROUTING_FIXED / NOT_FIXED`
|
||
- `CLEAN_FAMILY_ACCEPTANCE_READY / NOT_READY`
|
||
|
||
Общий статус:
|
||
|
||
- `STAGE4_FAMILY_ISOLATION_PACK_ACCEPTED`
|
||
- или `STAGE4_FAMILY_ISOLATION_PACK_ACCEPTED_WITH_LIMITATIONS`
|
||
- или `STAGE4_FAMILY_ISOLATION_PACK_NOT_ACCEPTED`
|
||
|
||
## 9. Ожидаемый итог
|
||
|
||
После этого пакета:
|
||
|
||
- settlement-вопросы не уходят в VAT/FA claim;
|
||
- VAT-вопросы не ведутся через settlement-path;
|
||
- mixed-file приемка не используется;
|
||
- прогресс измеряется по чистым family/lane с сопоставимыми метриками и артефактами.
|