Initial import NDC_1C
This commit is contained in:
Binary file not shown.
+679
@@ -0,0 +1,679 @@
|
||||
# Assistant Mode Global Status Report
|
||||
|
||||
Date: 2026-03-24
|
||||
Scope: `llm_normalizer` + Assistant Mode pipeline + retrieval/explainability contours
|
||||
Prepared for: architectural checkpoint and next-step planning
|
||||
|
||||
## 0) Executive Summary
|
||||
|
||||
Current system is no longer a raw route demo: we now have a working end-to-end assistant loop with decomposition, routing, retrieval, grounding, explainable response shaping, session logging, and regression tests.
|
||||
|
||||
At the same time, the system is still not a full accountant-grade investigation assistant. Main reason: data/model/retrieval unit depth is still below causal accounting reasoning depth in several domains.
|
||||
|
||||
Key status snapshot:
|
||||
|
||||
- Backend build/tests: `tsc` OK, `vitest` OK (`25/25` tests passed).
|
||||
- Explainable contract: implemented (`requirements`, `coverage_report`, `answer_grounding_check`, explainable reply sections).
|
||||
- Retrieval-layer upgrade: `executeHybrid` moved from `GUID-or-full-scan` to semantic profile + semantic narrowing.
|
||||
- Proven narrowing example: for bank mismatch query with accounts `51/60`, narrowing reduced records from `262` to `75`.
|
||||
- Proven limitation: for generic cross-entity chain query without explicit account scope, narrowing still wide (`262` to `242`), so answer quality can remain too broad.
|
||||
|
||||
---
|
||||
|
||||
## 1) Data Contour
|
||||
|
||||
### 1.1 How it works now
|
||||
|
||||
- Assistant retrieval reads local snapshot bundle from `docs/ARCH/2020экспорт`.
|
||||
- Main files currently loaded in executor:
|
||||
- `03_snapshot_fragment_problem_cases.json`
|
||||
- `04_samples_SpisanieSRaschetnogoScheta.json`
|
||||
- `05_samples_RealizaciyaTovarovUslug.json`
|
||||
- `06_samples_PostuplenieTovarovUslug.json`
|
||||
- `07_samples_DocumentJournals.json`
|
||||
- `08_samples_NDS_registers.json`
|
||||
- `09_samples_key_fields_Recorder_Ref_Supplier_Buyer_Responsible.json`
|
||||
- Data access is read-only snapshot, not live 1C state.
|
||||
|
||||
### 1.2 What works
|
||||
|
||||
- Documents/journals/register records are available with links and key attributes.
|
||||
- Counterparty/document linkage and part of relation topology are usable.
|
||||
- Enough depth exists for POC-level chain/risk analysis and explainable evidence pack.
|
||||
|
||||
### 1.3 Constraints
|
||||
|
||||
- Live truth is absent in assistant retrieval path (snapshot-only).
|
||||
- Lifecycle/status semantics are incomplete and partly heuristic.
|
||||
- Some accounting contexts are represented as flattened fields instead of normalized graph nodes.
|
||||
|
||||
### 1.4 What assistant cannot do because of this
|
||||
|
||||
- Guarantee real-time explanation of current accounting state.
|
||||
- Reliably prove deep causal accounting chains in all domains (especially where lifecycle semantics are implicit).
|
||||
|
||||
### 1.5 Symptoms already seen in dialogs
|
||||
|
||||
- Repeated top entities across semantically different but broad queries.
|
||||
- “Looks relevant” answers with weak differentiating evidence for some generic prompts.
|
||||
|
||||
### 1.6 Local changes needed
|
||||
|
||||
- Add richer field extraction/parsing from snapshot for account/document/lifecycle signals.
|
||||
- Enforce tighter domain-specific filters for low-specificity queries.
|
||||
|
||||
### 1.7 Architectural changes needed
|
||||
|
||||
- Add live data bridge layer for on-demand truth check (hybrid snapshot + live drilldown).
|
||||
- Add normalized accounting graph storage layer for causal traversal.
|
||||
|
||||
### 1.8 Priority
|
||||
|
||||
- `P0`: stronger retrieval constraints and lifecycle signal extraction.
|
||||
- `P1`: live bridge for targeted verification.
|
||||
- `P2`: full graph-backed data model.
|
||||
|
||||
---
|
||||
|
||||
## 2) Ontology / Domain Model Contour
|
||||
|
||||
### 2.1 How it works now
|
||||
|
||||
- Entity/relation semantics exist as retrieval profile vocabulary plus heuristic signal extraction.
|
||||
- Domain labels include bank/suppliers/customers/VAT/fixed_assets/deferred_expense/period_close/settlements.
|
||||
- Relation patterns include:
|
||||
- `payment_to_settlement`
|
||||
- `document_to_posting`
|
||||
- `statement_to_document`
|
||||
- `asset_card_to_depreciation`
|
||||
- `deferred_expense_to_writeoff`
|
||||
- `invoice_to_vat`
|
||||
- `contract_to_documents`
|
||||
- `receipt_to_stock_movement`
|
||||
|
||||
### 2.2 What works
|
||||
|
||||
- Query intent can be translated into semantic retrieval profile.
|
||||
- Basic anomaly vocabulary exists and affects ranking/explanation.
|
||||
|
||||
### 2.3 Constraints
|
||||
|
||||
- No explicit ontology graph engine with typed nodes/edges and reasoning rules.
|
||||
- Lifecycle model is heuristic (`created/posted/partially_linked/no_continuation/period_boundary`) rather than formal accounting state machine.
|
||||
|
||||
### 2.4 What assistant cannot do because of this
|
||||
|
||||
- Stable causal proofs for complex cross-domain reconciliation.
|
||||
- Deterministic explanation of “why exactly this stage is broken” across all domains.
|
||||
|
||||
### 2.5 Symptoms
|
||||
|
||||
- Explanation can still be structurally correct but semantically generic.
|
||||
- Retrieval unit can still drift toward “counterparty-heavy” answer shape.
|
||||
|
||||
### 2.6 Local changes needed
|
||||
|
||||
- Expand structured anomaly dictionary with accountant-facing defect classes.
|
||||
- Promote lifecycle markers from heuristics to explicit modeled states where possible.
|
||||
|
||||
### 2.7 Architectural changes needed
|
||||
|
||||
- Build ontology/lifecycle core as first-class subsystem.
|
||||
- Move from “labels on records” to “typed causal nodes and edges”.
|
||||
|
||||
### 2.8 Priority
|
||||
|
||||
- `P0`: anomaly taxonomy hardening + lifecycle schema hardening.
|
||||
- `P1`: typed ontology graph.
|
||||
- `P2`: rule engine over ontology.
|
||||
|
||||
---
|
||||
|
||||
## 3) Retrieval / Query Execution Contour
|
||||
|
||||
### 3.1 How it works now
|
||||
|
||||
- Deterministic routed executors:
|
||||
- `store_feature_risk`
|
||||
- `hybrid_store_plus_live`
|
||||
- `batch_refresh_then_store`
|
||||
- `store_canonical`
|
||||
- `live_mcp_drilldown`
|
||||
- `executeHybrid` now uses `semantic_retrieval_profile` and semantic narrowing when GUID is absent.
|
||||
- Retrieval result now carries richer context in items and summary (`query_subject`, profile, ranking basis, narrowing metrics).
|
||||
|
||||
### 3.2 What works
|
||||
|
||||
- No hard fallback to pure full scan in hybrid path for non-GUID queries.
|
||||
- Query with explicit accounting scope (`51/60`, wrong document closure) produces stronger narrowing and different ranking.
|
||||
- Evidence pack is richer and usable by explainable answer layer.
|
||||
|
||||
### 3.3 Constraints
|
||||
|
||||
- Generic prompts without explicit scope can still produce wide narrowed sets.
|
||||
- Retrieval top unit still often converges to counterparty-centric grouping.
|
||||
- Not all routes have equal semantic depth.
|
||||
|
||||
### 3.4 What assistant cannot do because of this
|
||||
|
||||
- Consistently deliver problem-node-first output in every query class.
|
||||
- Guarantee high differentiation for all semantically close prompts.
|
||||
|
||||
### 3.5 Symptoms
|
||||
|
||||
- For some queries, narrowing reduction is still modest (example `262 -> 242`).
|
||||
- Answers can remain “good but broad”.
|
||||
|
||||
### 3.6 Local changes needed
|
||||
|
||||
- Tighten mandatory intersections for generic bank/cross-entity prompts.
|
||||
- Add domain-specific minimum evidence thresholds before final top ranking.
|
||||
|
||||
### 3.7 Architectural changes needed
|
||||
|
||||
- Introduce explicit “problem cluster” retrieval unit.
|
||||
- Add cross-branch retrieval policy (neighbor contour checks).
|
||||
|
||||
### 3.8 Priority
|
||||
|
||||
- `P0`: further narrowing hardening + anti-generic ranking guards.
|
||||
- `P1`: problem-cluster retrieval unit.
|
||||
- `P2`: multi-branch investigation retrieval policy.
|
||||
|
||||
---
|
||||
|
||||
## 4) LLM Layer and Decomposition Contour
|
||||
|
||||
### 4.1 How it works now
|
||||
|
||||
- Prompt/schema baseline: `normalizer_v2_0_2`.
|
||||
- Deterministic v2 routing summary with fallback types.
|
||||
- Requirements extraction + coverage report + dropped-intent tracking are implemented.
|
||||
|
||||
### 4.2 What works
|
||||
|
||||
- Route and execution readiness are explicit.
|
||||
- Coverage and grounding diagnostics are available per turn.
|
||||
- Route mismatch blocking is now less false-positive for non-critical contextual tokens.
|
||||
|
||||
### 4.3 Constraints
|
||||
|
||||
- Requirement extraction remains coarse in many cases (often 1 requirement per fragment).
|
||||
- Transliteration/noisy mixed-language prompts still degrade in-scope detection.
|
||||
|
||||
### 4.4 What assistant cannot do because of this
|
||||
|
||||
- Fine-grained multi-requirement planning for complex accounting requests.
|
||||
- Fully robust handling of colloquial/translit business language.
|
||||
|
||||
### 4.5 Symptoms
|
||||
|
||||
- Some translit prompts fall into `out_of_scope/clarification`.
|
||||
- Partial semantic intent may be compressed in long multi-part prompts.
|
||||
|
||||
### 4.6 Local changes needed
|
||||
|
||||
- Expand language normalization and translit alias mapping before decomposition.
|
||||
- Improve requirement extraction granularity inside one fragment.
|
||||
|
||||
### 4.7 Architectural changes needed
|
||||
|
||||
- Add dedicated semantic parser layer before normalizer for business-language canonicalization.
|
||||
- Add requirement graph (instead of flat list) for planning/execution.
|
||||
|
||||
### 4.8 Priority
|
||||
|
||||
- `P0`: translit/business alias normalization.
|
||||
- `P1`: requirement graph extraction.
|
||||
- `P2`: adaptive decomposition policy.
|
||||
|
||||
---
|
||||
|
||||
## 5) Answer Synthesis / Explanation Contour
|
||||
|
||||
### 5.1 How it works now
|
||||
|
||||
- Reply types include:
|
||||
- `factual_with_explanation`
|
||||
- `partial_coverage`
|
||||
- `clarification_required`
|
||||
- `no_grounded_answer`
|
||||
- `route_mismatch_blocked`
|
||||
- others
|
||||
- Response includes explainable sections: result, why included, selection basis, risk signs, business meaning, limitations, next step.
|
||||
|
||||
### 5.2 What works
|
||||
|
||||
- Core explainable contract is implemented and stable.
|
||||
- Blocking logic prevents clearly mismatched subject answers.
|
||||
|
||||
### 5.3 Constraints
|
||||
|
||||
- Generic wording still appears when retrieval unit is broad.
|
||||
- Explanations are still largely template-driven for some routes.
|
||||
|
||||
### 5.4 What assistant cannot do because of this
|
||||
|
||||
- Deliver fully case-unique accountant-level narratives in all scenarios.
|
||||
|
||||
### 5.5 Symptoms
|
||||
|
||||
- Two semantically close broad prompts may yield similar explanatory skeleton.
|
||||
|
||||
### 5.6 Local changes needed
|
||||
|
||||
- Route-specific explanation templates with stronger domain phrasing.
|
||||
- Explicit “mechanism-of-failure” fields in retrieval result for composer.
|
||||
|
||||
### 5.7 Architectural changes needed
|
||||
|
||||
- Separate explanation planner from template renderer.
|
||||
- Add accountant-facing narrative policy with domain lexicon packs.
|
||||
|
||||
### 5.8 Priority
|
||||
|
||||
- `P0`: route-specific explanation enrichment.
|
||||
- `P1`: mechanism-level explanation fields.
|
||||
- `P2`: explanation planner subsystem.
|
||||
|
||||
---
|
||||
|
||||
## 6) Memory / State / Session Continuity Contour
|
||||
|
||||
### 6.1 How it works now
|
||||
|
||||
- Session-scoped conversation state is persisted.
|
||||
- One JSON file per session with turn-level human-readable + technical blocks.
|
||||
|
||||
### 6.2 What works
|
||||
|
||||
- Stable conversation history and replay.
|
||||
- Explicit per-turn decomposition and response auditability.
|
||||
|
||||
### 6.3 Constraints
|
||||
|
||||
- No robust investigation state model (hypotheses/open checks/resolution graph).
|
||||
- Context memory is conversational, not analytical.
|
||||
|
||||
### 6.4 What assistant cannot do because of this
|
||||
|
||||
- True multi-step investigative reasoning with hypothesis tracking.
|
||||
|
||||
### 6.5 Symptoms
|
||||
|
||||
- Follow-up can be coherent but not yet “investigation-driven”.
|
||||
|
||||
### 6.6 Local changes needed
|
||||
|
||||
- Add per-session `investigation_state` object (focus, active entities, open hypotheses, unresolved branches).
|
||||
|
||||
### 6.7 Architectural changes needed
|
||||
|
||||
- Add working-memory layer for research workflow, not only chat continuity.
|
||||
|
||||
### 6.8 Priority
|
||||
|
||||
- `P0`: investigation_state schema + persistence.
|
||||
- `P1`: branch tracking and hypothesis status transitions.
|
||||
- `P2`: multi-turn analytical planning engine.
|
||||
|
||||
---
|
||||
|
||||
## 7) Orchestration / Routing / Control Policy Contour
|
||||
|
||||
### 7.1 How it works now
|
||||
|
||||
- Deterministic routing with fallback (`none/out_of_scope/clarification/partial`).
|
||||
- Linear execution plan per turn.
|
||||
|
||||
### 7.2 What works
|
||||
|
||||
- Clear route decisions and no-route reasons.
|
||||
- Strong deterministic observability.
|
||||
|
||||
### 7.3 Constraints
|
||||
|
||||
- Mostly route-driven linear pipeline.
|
||||
- Limited iterative branch exploration initiated by system policy.
|
||||
|
||||
### 7.4 What assistant cannot do because of this
|
||||
|
||||
- Automatically run neighbor contour verification when primary evidence is weak.
|
||||
|
||||
### 7.5 Symptoms
|
||||
|
||||
- Reasonable direct answers, but limited self-initiated investigation depth.
|
||||
|
||||
### 7.6 Local changes needed
|
||||
|
||||
- Introduce confidence-driven secondary retrieval triggers.
|
||||
|
||||
### 7.7 Architectural changes needed
|
||||
|
||||
- Orchestration policy engine with iterative reasoning loops and stop criteria.
|
||||
|
||||
### 7.8 Priority
|
||||
|
||||
- `P0`: confidence-based secondary checks.
|
||||
- `P1`: branch exploration policy.
|
||||
- `P2`: full investigation orchestrator.
|
||||
|
||||
---
|
||||
|
||||
## 8) Quality / Observability / Eval Contour
|
||||
|
||||
### 8.1 How it works now
|
||||
|
||||
- Structured runtime logs (stdout JSON).
|
||||
- Trace storage and session logs.
|
||||
- Regression tests for API behavior, grounding and retrieval semantics.
|
||||
|
||||
### 8.2 What works
|
||||
|
||||
- Technical observability is strong for current stage.
|
||||
- Automated test baseline is green (`25/25`).
|
||||
|
||||
### 8.3 Constraints
|
||||
|
||||
- Limited accountant-utility evaluation metrics.
|
||||
- No broad canonical scenario benchmark with decision-quality scoring.
|
||||
|
||||
### 8.4 What assistant cannot do because of this
|
||||
|
||||
- Provide hard quantitative proof of business usefulness across accounting domains.
|
||||
|
||||
### 8.5 Symptoms
|
||||
|
||||
- Technical success may still exceed practical user-perceived success.
|
||||
|
||||
### 8.6 Local changes needed
|
||||
|
||||
- Add eval metrics:
|
||||
- retrieval differentiation rate
|
||||
- generic explanation rate
|
||||
- accountant actionability score
|
||||
- false confidence rate
|
||||
|
||||
### 8.7 Architectural changes needed
|
||||
|
||||
- Build domain eval harness with canonical accounting scenarios and target outcomes.
|
||||
|
||||
### 8.8 Priority
|
||||
|
||||
- `P0`: metric instrumentation for practical usefulness.
|
||||
- `P1`: canonical benchmark suite (bank/60/97/OS/VAT/period close/multi-intent/translit/follow-up).
|
||||
- `P2`: continuous quality dashboard.
|
||||
|
||||
---
|
||||
|
||||
## 9) Evolutionary Architecture Contour
|
||||
|
||||
### 9.1 Missing pieces (high impact)
|
||||
|
||||
- Ontology graph core.
|
||||
- Lifecycle engine.
|
||||
- Problem-cluster retrieval unit.
|
||||
- Investigation memory/state.
|
||||
- Orchestration policy engine for iterative checks.
|
||||
- Live verification bridge for source-of-truth escalation.
|
||||
|
||||
### 9.2 Current ceiling
|
||||
|
||||
- Without deeper ontology/lifecycle/state layers, system remains strong “explainable routed assistant”, but not full accountant investigation copilot.
|
||||
|
||||
### 9.3 Local vs architectural changes
|
||||
|
||||
- Local: better filters, better templates, more metrics, better parser.
|
||||
- Architectural: graph model, lifecycle engine, investigation state, multi-step orchestrator.
|
||||
|
||||
### 9.4 Priority
|
||||
|
||||
- `P0`: finish semantic retrieval hardening + practical eval metrics + investigation_state baseline.
|
||||
- `P1`: ontology/lifecycle formalization + problem-cluster retrieval.
|
||||
- `P2`: iterative orchestrator + live verification framework.
|
||||
|
||||
---
|
||||
|
||||
## 10) Answers to 12 Mandatory Questions
|
||||
|
||||
1. What data reaches assistant and where detail is lost:
|
||||
Data reaches from snapshot package with links/attributes; detail loss happens in flattening/grouping and lack of formal lifecycle semantics.
|
||||
|
||||
2. Full domain model exists:
|
||||
Partially. Semantic labels and patterns exist, formal ontology graph does not.
|
||||
|
||||
3. Primary retrieval unit:
|
||||
Mostly counterparty-grouped chain/risk clusters; not yet universal problem-node unit.
|
||||
|
||||
4. Real constraints and wide-scan risk:
|
||||
Constraints now executed in hybrid semantic profile, but generic queries can still remain broad.
|
||||
|
||||
5. What LLM receives before answer:
|
||||
Normalizer output + route summary + normalized retrieval payload + grounding/coverage diagnostics.
|
||||
|
||||
6. What is lost in decomposition:
|
||||
Fine-grained multi-requirement structure can still compress; translit/noisy input can lose intent quality.
|
||||
|
||||
7. Why explanation still generic in places:
|
||||
Broad retrieval unit + template-driven synthesis with limited mechanism-specific fields.
|
||||
|
||||
8. Can system explain mechanism (not only labels):
|
||||
Partially. Better than before, still constrained by retrieval evidence depth.
|
||||
|
||||
9. Working state/memory for multi-step analysis:
|
||||
Conversation memory exists; investigation memory model is missing.
|
||||
|
||||
10. Can system explore neighbor accounting branches automatically:
|
||||
Not yet as policy standard; mostly linear route execution.
|
||||
|
||||
11. How usefulness is measured:
|
||||
Technical pipeline quality is measured; accountant-facing utility metrics are not complete yet.
|
||||
|
||||
12. Missing architectural entities preventing next quality tier:
|
||||
Ontology graph, lifecycle engine, problem-cluster unit, investigation state, iterative orchestration.
|
||||
|
||||
---
|
||||
|
||||
## 11) Current Phase Status (Condensed)
|
||||
|
||||
- Phase status: `Functional MVP+` (explainable routed assistant with semantic retrieval upgrade).
|
||||
- Not yet: `Production accountant copilot`.
|
||||
- Immediate gate to next phase: tighten broad-query narrowing + add practical accountant eval metrics + investigation state schema.
|
||||
|
||||
---
|
||||
|
||||
## 12) Recommended Next Step Pack
|
||||
|
||||
### P0 (next iteration)
|
||||
|
||||
- Tighten generic-query semantic narrowing in hybrid route.
|
||||
- Add investigation state object in session model.
|
||||
- Add practical eval metrics (differentiation/actionability/generic-rate).
|
||||
|
||||
### P1 (after P0 stabilization)
|
||||
|
||||
- Formalize ontology + lifecycle layers.
|
||||
- Shift retrieval output from entity-heavy to problem-cluster-heavy for key domains.
|
||||
|
||||
### P2 (strategic)
|
||||
|
||||
- Add iterative orchestration with neighbor-branch verification.
|
||||
- Add live source-of-truth verification path for high-confidence conclusions.
|
||||
|
||||
---
|
||||
|
||||
## 13) Data Loss Map (Source to LLM)
|
||||
|
||||
This section is the explicit loss map requested for architecture decisions.
|
||||
|
||||
| Source Layer | Current Internal Representation | Lost/Weakened Signals | Observable Assistant Symptom | Required Fix Layer |
|
||||
|---|---|---|---|---|
|
||||
| 1C document/journal/register snapshot record | flattened `SnapshotRecord` + heuristic signal extraction | formal business status transitions, typed lifecycle stage semantics | explanation can be structurally correct but semantically generic | lifecycle model + ontology graph |
|
||||
| document + posting relation hints | relation pattern labels inferred by regex/rules | deterministic causal edge type and confidence | “close to right chain” answers without strict mechanism proof | typed relation graph + relation confidence |
|
||||
| account hints from query and record fields | `account_scope` and inferred `account_context` arrays | strong account-role semantics (main vs side context) | broad retrieval if account scope is not explicit | account-role policy in retrieval profile |
|
||||
| anomaly signs (`unknown links`, `zero guid`, etc.) | anomaly pattern tags (`missing_link`, `broken_lifecycle`, etc.) | accountant-grade defect class and business consequence mapping | same anomaly labels across semantically different defects | anomaly catalog and mapping engine |
|
||||
| session chat turns | conversation list + turn log | investigation branch state and hypothesis state | follow-up can be coherent but not deeply investigative | investigation_state subsystem |
|
||||
| snapshot-only truth | no guaranteed live verification step in assistant route | real-time status confirmation | high-quality but potentially stale conclusion in sensitive cases | live verification bridge |
|
||||
|
||||
### 13.1 Diagnostic implication
|
||||
|
||||
The dominant ceiling is not “weak wording” but “insufficiently structured causal context before synthesis”.
|
||||
|
||||
---
|
||||
|
||||
## 14) Query Class vs Required Architecture Depth
|
||||
|
||||
| User Query Class | Required Layers | Current Readiness | Ceiling Cause | Next Upgrade |
|
||||
|---|---|---|---|---|
|
||||
| simple factual object lookup | routing + canonical retrieval + basic grounding | medium/high | snapshot-only verification | optional live drilldown |
|
||||
| anomaly ranking (one contour) | semantic profile + risk retrieval + explainable synthesis | medium | anomaly semantics still heuristic | anomaly catalog hardening |
|
||||
| causal chain in one contour | relation patterns + chain retrieval + evidence pack | medium | retrieval unit still entity-heavy in broad prompts | problem-cluster unit |
|
||||
| cross-domain reconciliation | ontology + lifecycle + neighbor branch policy | low/medium | no formal cross-domain causal graph | ontology graph + branch policy |
|
||||
| period-close impact analysis | lifecycle + period-risk model + orchestration | low/medium | lifecycle model incomplete | lifecycle engine |
|
||||
| multi-step investigation with follow-up | investigation_state + orchestration loops + hypothesis tracking | low | memory is conversational, not investigative | investigation mode layer |
|
||||
| ambiguity-heavy/translit business language | semantic parser + alias normalization + decomposition guard | low/medium | parser limitations before routing | pre-normalization parser layer |
|
||||
|
||||
### 14.1 Decision implication
|
||||
|
||||
Prompt/model tuning alone cannot close low-readiness classes above; they are architecture-depth dependent.
|
||||
|
||||
---
|
||||
|
||||
## 15) Retrieval Unit Diagnosis (Core Bottleneck)
|
||||
|
||||
### 15.1 Current dominant unit
|
||||
|
||||
- Dominant unit in hybrid route is still often `counterparty group`, even after semantic narrowing.
|
||||
|
||||
### 15.2 Where this unit is acceptable
|
||||
|
||||
- quick ranking
|
||||
- initial risk surfacing
|
||||
- broad operational scanning
|
||||
|
||||
### 15.3 Where this unit breaks answer quality
|
||||
|
||||
- “what exactly is broken in chain”
|
||||
- “closed by wrong document type”
|
||||
- “which lifecycle stage is inconsistent”
|
||||
- “what blocks period close and why”
|
||||
|
||||
### 15.4 Target retrieval units (must become first-class)
|
||||
|
||||
- `document_conflict`
|
||||
- `broken_chain_segment`
|
||||
- `lifecycle_anomaly_node`
|
||||
- `unresolved_settlement_cluster`
|
||||
- `period_risk_cluster`
|
||||
- `cross_branch_inconsistency_cluster`
|
||||
|
||||
### 15.5 Transition plan
|
||||
|
||||
- Step 1 (`P0`): keep counterparty groups but add explicit `mechanism_of_failure` + `failed_expected_edge`.
|
||||
- Step 2 (`P1`): introduce mixed-unit ranking (problem cluster first, entity second).
|
||||
- Step 3 (`P2`): use problem-cluster as default answer unit for chain/anomaly/period-risk routes.
|
||||
|
||||
---
|
||||
|
||||
## 16) LLM Ceiling Boundaries (Not Solvable by Prompt Alone)
|
||||
|
||||
The following limitations remain even with stronger models/prompts unless architecture changes:
|
||||
|
||||
1. no formal lifecycle state machine on input -> model cannot produce deterministic lifecycle diagnosis;
|
||||
2. no typed causal graph edges -> model cannot consistently prove mechanism, only infer plausible narrative;
|
||||
3. entity-heavy retrieval unit -> model can explain “who is risky”, but not always “what exact mechanism broke”;
|
||||
4. missing investigation_state -> model cannot reliably manage long hypothesis trees across turns;
|
||||
5. no mandatory live verification gate -> model cannot guarantee real-time truth in high-stakes answers.
|
||||
|
||||
### 16.1 Governance rule
|
||||
|
||||
When limitations above are active, quality work must target data/model/orchestration layers first; LLM tuning is secondary.
|
||||
|
||||
---
|
||||
|
||||
## 17) Investigation Mode Specification (Required Next Architecture)
|
||||
|
||||
### 17.1 Minimal `investigation_state` schema
|
||||
|
||||
```json
|
||||
{
|
||||
"session_id": "asst-...",
|
||||
"focus": {
|
||||
"domain": "bank_settlements",
|
||||
"period": "2020-06",
|
||||
"primary_accounts": ["51", "60"]
|
||||
},
|
||||
"active_entities": [
|
||||
{ "type": "counterparty", "id": "..." },
|
||||
{ "type": "document", "id": "..." }
|
||||
],
|
||||
"open_hypotheses": [
|
||||
{
|
||||
"hypothesis_id": "H1",
|
||||
"statement": "closure performed by wrong document type",
|
||||
"status": "open",
|
||||
"evidence_for": [],
|
||||
"evidence_against": []
|
||||
}
|
||||
],
|
||||
"branches": [
|
||||
{
|
||||
"branch_id": "B1",
|
||||
"name": "bank->settlement",
|
||||
"status": "in_progress",
|
||||
"unresolved_reason": null
|
||||
}
|
||||
],
|
||||
"resolved_findings": [],
|
||||
"next_actions": []
|
||||
}
|
||||
```
|
||||
|
||||
### 17.2 Required branch lifecycle
|
||||
|
||||
- `open` -> `in_progress` -> `confirmed` or `rejected` -> `closed`
|
||||
|
||||
### 17.3 System-initiated branch rule (minimum)
|
||||
|
||||
If primary route confidence is high but mechanism evidence is weak, assistant should launch one neighbor branch check before final high-confidence conclusion.
|
||||
|
||||
---
|
||||
|
||||
## 18) Symptom to Root Cause to Required Layer
|
||||
|
||||
| Symptom | Root Cause | Required Layer |
|
||||
|---|---|---|
|
||||
| generic explanation despite “ok” reply | mechanism fields missing in retrieval payload | retrieval schema + answer planner |
|
||||
| similar answers for broad prompts | weak semantic narrowing for low-specificity queries | retrieval policy |
|
||||
| follow-up does not deepen analysis | no hypothesis/branch state | investigation_state |
|
||||
| strong dependence on explicit account hints | weak semantic parser/ontology grounding | parser + ontology |
|
||||
| lifecycle conclusions not stable | lifecycle semantics heuristic only | lifecycle engine |
|
||||
| high confidence on snapshot-only route | no live verification gate | live verification bridge |
|
||||
|
||||
---
|
||||
|
||||
## 19) Value-Impact Roadmap (Decision Table)
|
||||
|
||||
| Change | Complexity | Quality Gain | Accountant Usefulness Gain | Multi-step Investigation Gain | Priority |
|
||||
|---|---|---|---|---|---|
|
||||
| tighten generic semantic narrowing | low/medium | high | high | medium | P0 |
|
||||
| add `mechanism_of_failure` retrieval fields | medium | high | high | medium | P0 |
|
||||
| add `investigation_state` persistence | medium | medium/high | high | high | P0 |
|
||||
| add practical utility eval metrics | low/medium | medium | high | medium | P0 |
|
||||
| formalize anomaly catalog | medium | medium/high | high | medium | P1 |
|
||||
| ontology graph core | high | high | high | high | P1 |
|
||||
| lifecycle engine | high | high | high | high | P1 |
|
||||
| problem-cluster retrieval unit | high | high | high | high | P1 |
|
||||
| iterative orchestration engine | high | high | high | very high | P2 |
|
||||
| live verification bridge | high | medium/high | high | medium/high | P2 |
|
||||
|
||||
---
|
||||
|
||||
## 20) What Not To Do (Explicit Guardrails)
|
||||
|
||||
1. Do not attempt to solve mechanism-level quality only with prompt edits.
|
||||
2. Do not treat richer wording as substitute for stronger retrieval unit.
|
||||
3. Do not scale explanation templates without adding mechanism evidence fields.
|
||||
4. Do not equate long conversation history with investigation_state.
|
||||
5. Do not claim production-grade confidence without live verification path for critical answers.
|
||||
|
||||
+63
@@ -0,0 +1,63 @@
|
||||
# Assistant Mode Global Status Appendix
|
||||
|
||||
Date: 2026-03-24
|
||||
|
||||
## A) Verification Commands
|
||||
|
||||
```powershell
|
||||
cd X:\1C\NDC_1C\llm_normalizer\backend
|
||||
npm.cmd run build
|
||||
npm.cmd run test
|
||||
```
|
||||
|
||||
Observed result:
|
||||
|
||||
- TypeScript build: success
|
||||
- Test suite: success (`25/25`)
|
||||
|
||||
## B) Retrieval Narrowing Evidence
|
||||
|
||||
### Case 1: bank mismatch with explicit account scope
|
||||
|
||||
- Session: `asst-FuRihiL5Bp`
|
||||
- Query subject: `bank_settlement_mismatch`
|
||||
- Source records: `262`
|
||||
- Filtered after narrowing: `75`
|
||||
- Semantic narrowing applied: `true`
|
||||
|
||||
### Case 2: generic cross-entity bank chain
|
||||
|
||||
- Session: `asst-j9spgqdY7k`
|
||||
- Query subject: `cross_entity_breakage`
|
||||
- Source records: `262`
|
||||
- Filtered after narrowing: `242`
|
||||
- Semantic narrowing applied: `true`
|
||||
|
||||
Interpretation:
|
||||
|
||||
- Semantic narrowing is active and effective for constrained accounting scope.
|
||||
- Generic prompts still need stronger narrowing policy.
|
||||
|
||||
## C) Key Implementation Anchors
|
||||
|
||||
- Semantic profile contract and builder:
|
||||
- `X:\1C\NDC_1C\llm_normalizer\backend\src\services\assistantDataLayer.ts`
|
||||
- Hybrid narrowing and enriched evidence pack:
|
||||
- `X:\1C\NDC_1C\llm_normalizer\backend\src\services\assistantDataLayer.ts`
|
||||
- API regression test for semantic narrowing:
|
||||
- `X:\1C\NDC_1C\llm_normalizer\backend\tests\assistantEndpoint.test.ts`
|
||||
|
||||
## D) v1.1 Report Reinforcement Checklist
|
||||
|
||||
All 4 requested reinforcements are now explicitly present in the main report:
|
||||
|
||||
1. Data-loss path map (`Source -> Internal -> Lost -> Symptom -> Fix layer`)
|
||||
2. Query-class vs architecture-depth matrix
|
||||
3. Dedicated retrieval-unit diagnosis block (current vs target units)
|
||||
4. Investigation mode schema and control-policy baseline
|
||||
|
||||
Also added:
|
||||
|
||||
- symptom -> root cause -> required layer matrix
|
||||
- value-impact roadmap table
|
||||
- explicit “what not to do” guardrails
|
||||
@@ -0,0 +1,555 @@
|
||||
Да, сейчас как раз надо **перевернуть логику** и идти **от целевой архитектуры назад**, а не от текущих латок вперёд.
|
||||
|
||||
Потому что по вашему же статус-репорту уже видно: текущая система — это не “почти готовый ассистент”, а **explainable routed assistant**, который умеет разбирать вопрос, запускать retrieval и собирать ответ, но ещё не является полноценным бухгалтерским investigation copilot. Главные потолки уже названы прямо: snapshot-only truth, неполный lifecycle, entity-heavy retrieval unit, отсутствие investigation_state, отсутствие итеративной оркестрации и live verification.
|
||||
|
||||
И ещё одна очень важная вещь из отчёта: доминирующий потолок — это **не слабые формулировки**, а **недостаточно структурированный причинный контекст до synthesis**. То есть лечить всё “ещё одной LLM” или “ещё одним промптом” — это тупиковый путь.
|
||||
|
||||
Ниже дам тебе не просто roadmap, а именно **модель проектирования от идеального результата**.
|
||||
|
||||
---
|
||||
|
||||
# 1. Сначала фиксируем, что такое идеальный результат
|
||||
|
||||
Идеальный бухгалтерский ассистент для вас — это не чат, который “умеет отвечать на пару типов вопросов”.
|
||||
|
||||
Это система, которая умеет делать **три полноценных режима**.
|
||||
|
||||
## Режим A. Точечный причинно-следственный ответ
|
||||
|
||||
Пользователь задаёт короткий вопрос, но система понимает, что за ним стоит сложный поиск.
|
||||
|
||||
Пример:
|
||||
“Какие проблемы по 51 счёту?”
|
||||
Нормальный ответ здесь — это не список контрагентов и не абстрактные risk labels, а:
|
||||
|
||||
* где именно найден разрыв,
|
||||
* какие документы участвуют,
|
||||
* какая проводка или связь не бьётся,
|
||||
* что это значит practically,
|
||||
* на какие документы смотреть.
|
||||
|
||||
Для этого нужен не простой search, а **causal reconstruction**.
|
||||
|
||||
## Режим B. Многосоставной исследовательский вопрос
|
||||
|
||||
Пользователь задаёт сложный вопрос с гипотезами:
|
||||
|
||||
* проверь хвосты,
|
||||
* выдели те, что ломают закрытие периода,
|
||||
* отдельно покажи те, где проблема не в сумме, а в lifecycle,
|
||||
* сравни с соседним контуром.
|
||||
|
||||
Это уже не single-shot answer.
|
||||
Это мини-расследование.
|
||||
|
||||
## Режим C. Глобальный аналитический прогон
|
||||
|
||||
“Проведи полный анализ периода / зоны / класса рисков”.
|
||||
|
||||
Это уже не обычный ответ на чат-запрос, а **пакетное исследование**:
|
||||
|
||||
* сбор большого массива проблемных узлов,
|
||||
* группировка,
|
||||
* ранжирование,
|
||||
* объяснение паттернов,
|
||||
* вывод агрегированного состояния.
|
||||
|
||||
Для такого режима нужен отдельный execution mode, а не тот же самый lightweight pipeline, что и для короткого вопроса.
|
||||
|
||||
---
|
||||
|
||||
# 2. Отсюда вывод: у вас должен быть не один ассистент, а 3 архитектурных режима
|
||||
|
||||
Это очень важная развилка.
|
||||
|
||||
Сейчас вы, похоже, местами пытаетесь одним и тем же контуром обслужить:
|
||||
|
||||
* короткий factual вопрос,
|
||||
* сложный multi-intent вопрос,
|
||||
* широкий audit / overview.
|
||||
|
||||
Так нельзя.
|
||||
Нужно проектировать **три режима исполнения**, даже если внешне они живут в одном чате.
|
||||
|
||||
## Mode 1: Direct Answer
|
||||
|
||||
Для узких или средних вопросов.
|
||||
Цель: дать сильный ответ быстро.
|
||||
|
||||
## Mode 2: Investigation
|
||||
|
||||
Для сложных вопросов с гипотезами, ветками и follow-up.
|
||||
Цель: вести исследование, а не просто отвечать.
|
||||
|
||||
## Mode 3: Audit / Batch Analysis
|
||||
|
||||
Для глобальных прогонов по периоду/зоне/классу проблем.
|
||||
Цель: строить обзор состояния, кластеры рисков и приоритеты проверки.
|
||||
|
||||
Если это не разделить, вы будете всё время получать один и тот же эффект:
|
||||
либо система поверхностна, либо слишком грузная, либо делает вид, что исследует, но на самом деле просто пересказывает одну выборку.
|
||||
|
||||
---
|
||||
|
||||
# 3. Что должно быть в целевой взрослой архитектуре
|
||||
|
||||
Если идти от конца, то у вас в “высшей планке” должны быть **7 обязательных архитектурных слоёв**.
|
||||
|
||||
## Слой 1. Data truth layer
|
||||
|
||||
Система должна иметь доступ не только к плоскому снапшоту, но и к:
|
||||
|
||||
* документам,
|
||||
* проводкам,
|
||||
* регистрам,
|
||||
* статусам,
|
||||
* связям,
|
||||
* live-подтверждению для high-stakes вопросов.
|
||||
|
||||
Сейчас у вас retrieval идёт из snapshot bundle, а live truth в assistant path отсутствует. Это сразу ставит потолок на достоверность.
|
||||
|
||||
## Слой 2. Accounting ontology graph
|
||||
|
||||
Нужен не просто набор labels, а типизированный граф:
|
||||
|
||||
* документ,
|
||||
* проводка,
|
||||
* движение регистра,
|
||||
* счет,
|
||||
* субсчет,
|
||||
* контрагент,
|
||||
* договор,
|
||||
* ОС,
|
||||
* РБП,
|
||||
* НДС,
|
||||
* период,
|
||||
* закрытие,
|
||||
* и связи между ними.
|
||||
|
||||
Сейчас semantic vocabulary есть, formal ontology graph нет.
|
||||
|
||||
## Слой 3. Lifecycle engine
|
||||
|
||||
Для большинства бухгалтерских аномалий важен не сам объект, а его жизненный цикл:
|
||||
|
||||
* создан,
|
||||
* проведён,
|
||||
* связан,
|
||||
* закрыт,
|
||||
* частично закрыт,
|
||||
* завис,
|
||||
* закрыт не тем документом,
|
||||
* противоречит соседнему контуру.
|
||||
|
||||
Сейчас lifecycle у вас heuristic, а не formal state machine.
|
||||
|
||||
## Слой 4. Problem-cluster retrieval
|
||||
|
||||
Не entity-first retrieval, а retrieval по проблемным узлам:
|
||||
|
||||
* document_conflict
|
||||
* broken_chain_segment
|
||||
* lifecycle_anomaly_node
|
||||
* unresolved_settlement_cluster
|
||||
* period_risk_cluster
|
||||
* cross_branch_inconsistency_cluster
|
||||
|
||||
Это прямо сформулировано в отчёте как следующий архитектурный переход.
|
||||
|
||||
## Слой 5. Investigation state
|
||||
|
||||
Нужна не просто память чата, а память расследования:
|
||||
|
||||
* current focus,
|
||||
* active hypotheses,
|
||||
* checked branches,
|
||||
* unresolved branches,
|
||||
* evidence collected,
|
||||
* confidence,
|
||||
* next recommended checks.
|
||||
|
||||
Сейчас conversation memory есть, investigation memory model отсутствует.
|
||||
|
||||
## Слой 6. Iterative orchestration
|
||||
|
||||
Система должна уметь не только выполнять один route, а:
|
||||
|
||||
* делать secondary checks,
|
||||
* идти в соседнюю ветку,
|
||||
* усиливать доказательства,
|
||||
* останавливать исследование по критериям,
|
||||
* переключаться между локальным ответом и расследованием.
|
||||
|
||||
Сейчас pipeline в основном linear и route-driven.
|
||||
|
||||
## Слой 7. Accountant-grade answer synthesis
|
||||
|
||||
Ответ должен строиться не по лейблам, а по механике нарушения:
|
||||
|
||||
* что именно сломано,
|
||||
* где,
|
||||
* между чем и чем,
|
||||
* почему это признано проблемой,
|
||||
* что это блокирует,
|
||||
* что проверить дальше.
|
||||
|
||||
Сейчас generic explanation ещё остаётся из-за broad retrieval unit и limited mechanism-specific fields.
|
||||
|
||||
---
|
||||
|
||||
# 4. Ключевая мысль: вам надо проектировать не “ассистента”, а бухгалтерический investigation engine
|
||||
|
||||
Вот здесь и есть разворот мышления.
|
||||
|
||||
Проблема не в том, что текущая система “простая”.
|
||||
Проблема в том, что её базовая логика пока ближе к:
|
||||
|
||||
* normalize
|
||||
* route
|
||||
* retrieve
|
||||
* synthesize
|
||||
|
||||
А целевая система должна быть ближе к:
|
||||
|
||||
* understand
|
||||
* model
|
||||
* investigate
|
||||
* verify
|
||||
* explain
|
||||
* continue
|
||||
|
||||
То есть вы строите не просто retrieval assistant, а **engine исследования учётной причинности**.
|
||||
|
||||
И это означает, что ядром архитектуры должен стать не normalizer и не answer composer, а вот эта связка:
|
||||
|
||||
**ontology graph + lifecycle engine + problem-cluster retrieval + investigation state + orchestration policy**
|
||||
|
||||
---
|
||||
|
||||
# 5. Что делать дальше: реальная дорожная карта
|
||||
|
||||
Ниже даю дорожную карту **от целевой архитектуры назад**, а не от текущих мелких фиксов вперёд.
|
||||
|
||||
## Этап 0. Зафиксировать, что дальше вы строите не чат-надстройку, а investigation architecture
|
||||
|
||||
Это организационный этап, но он критичен.
|
||||
|
||||
Нужно формально принять:
|
||||
|
||||
* есть 3 execution modes;
|
||||
* есть архитектурные сущности, без которых потолок не пробить;
|
||||
* LLM tuning больше не главный вектор;
|
||||
* данные, ontology, lifecycle, retrieval unit и orchestration становятся основой.
|
||||
|
||||
Без этого вы снова утонете в “давайте ещё немножко улучшим ответы”.
|
||||
|
||||
---
|
||||
|
||||
## Этап 1. Закрыть фундаментальные дыры текущего слоя
|
||||
|
||||
Это не “идеал”, это санитарный минимум, чтобы было на что опираться.
|
||||
|
||||
### Что сделать
|
||||
|
||||
1. Дожать semantic retrieval hardening для broad/generic prompts.
|
||||
Сейчас даже в отчёте видно: constrained query narrowing работает, generic cross-entity — всё ещё слишком широкая.
|
||||
|
||||
2. Добавить accountant-facing eval metrics:
|
||||
|
||||
* retrieval differentiation rate
|
||||
* generic explanation rate
|
||||
* accountant actionability score
|
||||
* false confidence rate
|
||||
|
||||
3. Ввести baseline `investigation_state` в session model.
|
||||
Не полный engine, а хотя бы:
|
||||
|
||||
* focus,
|
||||
* domain,
|
||||
* period,
|
||||
* hypotheses,
|
||||
* checked objects,
|
||||
* unresolved branches,
|
||||
* last evidence pack.
|
||||
|
||||
### Критерий выхода
|
||||
|
||||
Система не просто отвечает, а начинает **держать предмет расследования** и не терять его между ходами.
|
||||
|
||||
---
|
||||
|
||||
## Этап 2. Сменить retrieval unit
|
||||
|
||||
Это, по-хорошему, самый важный следующий технический шаг.
|
||||
|
||||
### Что сделать
|
||||
|
||||
Перестать считать `counterparty group` базовой единицей для chain/anomaly вопросов.
|
||||
Оставить её как вспомогательную, но наверх выводить problem clusters.
|
||||
|
||||
### Нужные target units
|
||||
|
||||
* document_conflict
|
||||
* broken_chain_segment
|
||||
* lifecycle_anomaly_node
|
||||
* unresolved_settlement_cluster
|
||||
* period_risk_cluster
|
||||
* cross_branch_inconsistency_cluster
|
||||
|
||||
### Что это даст
|
||||
|
||||
Только после этого ответы начнут переходить от:
|
||||
“какие контрагенты шумные”
|
||||
к
|
||||
“что именно сломано и где”.
|
||||
|
||||
### Критерий выхода
|
||||
|
||||
На вопрос типа “что закрыли не тем документом” top-объектом ответа становится не контрагент, а **конкретный конфликтный узел**.
|
||||
|
||||
---
|
||||
|
||||
## Этап 3. Формализовать lifecycle
|
||||
|
||||
Без этого вы не сделаете хороший бухгалтерский reasoning.
|
||||
|
||||
### Что сделать
|
||||
|
||||
Для ключевых доменов ввести явные state models:
|
||||
|
||||
* bank/settlements
|
||||
* suppliers
|
||||
* customers
|
||||
* fixed assets
|
||||
* deferred expenses
|
||||
* VAT
|
||||
* period close
|
||||
|
||||
### Для каждого домена
|
||||
|
||||
Определить:
|
||||
|
||||
* допустимые стадии,
|
||||
* допустимые переходы,
|
||||
* типовые нарушения,
|
||||
* бизнес-последствия.
|
||||
|
||||
### Что это даст
|
||||
|
||||
Система сможет объяснять не “broken_lifecycle”, а:
|
||||
|
||||
* платёж дошёл, обязательство не закрылось;
|
||||
* объект ОС принят, но переход в стадию эксплуатации/амортизации неконсистентен;
|
||||
* РБП живёт за пределами ожидаемого срока списания;
|
||||
* налоговый контур противоречит документному.
|
||||
|
||||
### Критерий выхода
|
||||
|
||||
Система умеет называть **тип поломки стадии**, а не просто общий risk label.
|
||||
|
||||
---
|
||||
|
||||
## Этап 4. Построить ontology graph
|
||||
|
||||
Это уже первый реально взрослый архитектурный шаг.
|
||||
|
||||
### Что сделать
|
||||
|
||||
Выделить typed nodes and edges:
|
||||
|
||||
* document
|
||||
* posting
|
||||
* register movement
|
||||
* account
|
||||
* counterparty
|
||||
* contract
|
||||
* asset
|
||||
* deferred expense
|
||||
* invoice
|
||||
* VAT node
|
||||
* period close operation
|
||||
* etc.
|
||||
|
||||
И отдельно typed edges:
|
||||
|
||||
* created_by
|
||||
* posted_to
|
||||
* settles
|
||||
* refers_to
|
||||
* closes
|
||||
* writes_off
|
||||
* depreciates
|
||||
* affects_period
|
||||
* conflicts_with
|
||||
* missing_expected_edge
|
||||
|
||||
### Что это даст
|
||||
|
||||
1. Нормальный causal traversal
|
||||
2. Нормальный cross-domain reconciliation
|
||||
3. Возможность rule engine поверх графа
|
||||
4. Сильный вход в LLM
|
||||
|
||||
### Критерий выхода
|
||||
|
||||
На сложный вопрос система может доказательно пройти не только “рядом лежащие записи”, а **типизированную цепочку бухгалтерской причинности**.
|
||||
|
||||
---
|
||||
|
||||
## Этап 5. Построить investigation mode
|
||||
|
||||
Это уже переход от ассистента к сопилоту.
|
||||
|
||||
### Что сделать
|
||||
|
||||
Поверх graph + lifecycle + retrieval unit ввести investigation engine:
|
||||
|
||||
* hypothesis registration
|
||||
* branch tracking
|
||||
* neighbor branch policy
|
||||
* confidence-driven secondary checks
|
||||
* stop criteria
|
||||
* escalation to live drilldown
|
||||
|
||||
### Как это работает
|
||||
|
||||
Пользователь задаёт вопрос → система не просто отвечает, а открывает investigation state:
|
||||
|
||||
* главная гипотеза,
|
||||
* какие ветки уже проверены,
|
||||
* чего не хватает,
|
||||
* куда надо сходить ещё,
|
||||
* что уже доказано,
|
||||
* что пока только вероятно.
|
||||
|
||||
### Критерий выхода
|
||||
|
||||
Follow-up превращается не в “ещё один независимый вопрос”, а в продолжение одного расследования.
|
||||
|
||||
---
|
||||
|
||||
## Этап 6. Добавить live verification bridge
|
||||
|
||||
Для high-stakes ответов snapshot-only пути недостаточно. Это уже прямо отражено в статус-репорте.
|
||||
|
||||
### Что сделать
|
||||
|
||||
Добавить режим точечного live drilldown:
|
||||
|
||||
* по конкретному документу,
|
||||
* проводке,
|
||||
* объекту,
|
||||
* текущему статусу,
|
||||
* source-of-record.
|
||||
|
||||
### Что это даст
|
||||
|
||||
1. Реальную актуальность
|
||||
2. Меньше ложной уверенности
|
||||
3. Возможность делать сильные выводы там, где snapshot устарел
|
||||
|
||||
### Критерий выхода
|
||||
|
||||
Система умеет честно разделять:
|
||||
|
||||
* вывод по snapshot,
|
||||
* вывод, подтверждённый live.
|
||||
|
||||
---
|
||||
|
||||
## Этап 7. Развести execution modes в продукте
|
||||
|
||||
К этому моменту нужно уже не только архитектурно, но и продуктово развести 3 режима.
|
||||
|
||||
### Direct Answer
|
||||
|
||||
Быстрый ответ по объекту / проблеме / счёту.
|
||||
|
||||
### Investigation
|
||||
|
||||
Пошаговое исследование с ветками и накоплением доказательств.
|
||||
|
||||
### Audit / Batch
|
||||
|
||||
Долгий прогон по периоду/зоне с итоговым risk report.
|
||||
|
||||
Это можно оставить в одном UI, но внутри это должны быть три разных execution policies.
|
||||
|
||||
---
|
||||
|
||||
# 6. Как отвечать на твой главный страх: “мы очень далеко”
|
||||
|
||||
Да, вы далеко.
|
||||
Но это **нормально**, потому что цель у вас не “добавить чат к 1С”, а построить довольно серьёзный reasoning layer над бухгалтерской реальностью.
|
||||
|
||||
По отчёту ваш текущий уровень — это действительно примерно:
|
||||
**functional MVP+**, но не accountant-grade copilot. Это уже честно зафиксировано и там, и это правильная оценка.
|
||||
|
||||
Плохая новость:
|
||||
простыми кирпичиками от текущего пайплайна до идеала не дойти.
|
||||
|
||||
Хорошая новость:
|
||||
сейчас уже видно, **какие именно сущности отсутствуют**.
|
||||
То есть вы уже не в тумане.
|
||||
Вы уже можете перестать лечить симптомы и начать проектировать взрослую систему.
|
||||
|
||||
---
|
||||
|
||||
# 7. Чего точно не надо делать дальше
|
||||
|
||||
Это прям важно.
|
||||
|
||||
## Не надо:
|
||||
|
||||
* лечить всё промптами;
|
||||
* надеяться, что более сильная LLM сама “додумает бухгалтерию”;
|
||||
* продолжать делать entity-heavy ответы и просто украшать их текстом;
|
||||
* считать длинную историю чата полноценным investigation state;
|
||||
* пытаться одним execution loop закрывать и короткий factual вопрос, и долгий audit;
|
||||
* строить perceived quality вместо реальной причинной глубины.
|
||||
|
||||
Это всё уже противоречит вашему же отчёту.
|
||||
|
||||
---
|
||||
|
||||
# 8. Если совсем коротко: что делать прямо сейчас
|
||||
|
||||
Если перевести всё в управленческое решение, то я бы сказал так.
|
||||
|
||||
## Ближайший обязательный пакет
|
||||
|
||||
1. baseline investigation_state
|
||||
2. практические accountant-метрики
|
||||
3. дожим generic narrowing
|
||||
4. mechanism-specific fields в retrieval result
|
||||
5. переход к mixed retrieval unit
|
||||
|
||||
## Следующий архитектурный пакет
|
||||
|
||||
1. lifecycle formalization
|
||||
2. anomaly catalog accountant-grade
|
||||
3. ontology graph core
|
||||
4. problem-cluster retrieval default for chain/anomaly routes
|
||||
|
||||
## Стратегический пакет
|
||||
|
||||
1. investigation orchestrator
|
||||
2. neighbor-branch policy
|
||||
3. live verification bridge
|
||||
4. product split на Direct / Investigation / Audit
|
||||
|
||||
---
|
||||
|
||||
# 9. Мой итоговый вердикт
|
||||
|
||||
Вам реально нужно **перестать мыслить от текущего pipeline** и начать мыслить от такой целевой конструкции:
|
||||
|
||||
**Бухгалтерский ассистент = accounting graph + lifecycle engine + problem-cluster retrieval + investigation state + iterative orchestrator + live verification + explanation layer**
|
||||
|
||||
LLM там важна, но она не центр системы.
|
||||
Она — интерпретатор, планировщик, синтезатор и интерфейс reasoning.
|
||||
А reasoning должен жить в архитектуре, а не только в модели.
|
||||
|
||||
Вот это и есть взрослая развилка.
|
||||
|
||||
Если хочешь, следующим сообщением я соберу это уже в виде **жёсткой roadmap-таблицы: этап / цель / что внедряем / критерий выхода / что это даёт пользователю**.
|
||||
BIN
Binary file not shown.
+1386
File diff suppressed because it is too large
Load Diff
Binary file not shown.
+776
@@ -0,0 +1,776 @@
|
||||
|
||||
# ТЗ Этап 1
|
||||
|
||||
## Foundation Hardening для Assistant Mode
|
||||
|
||||
## 0. Смысл этапа
|
||||
|
||||
Этот этап **не должен** строить взрослую финальную архитектуру.
|
||||
Он должен сделать другое:
|
||||
|
||||
**превратить текущий explainable routed assistant из “формально работающего контура” в устойчивый базовый слой, на который уже можно ставить problem-cluster retrieval, lifecycle formalization и investigation engine.**
|
||||
|
||||
То есть задача этапа не “улучшить ответы вообще”, а:
|
||||
|
||||
* убрать самые опасные архитектурные слабости текущего слоя;
|
||||
* перестать терять предмет анализа между шагами;
|
||||
* перестать собирать слишком широкие broad answers;
|
||||
* перестать генерировать explanation, в котором есть labels, но нет механики;
|
||||
* ввести измеримость качества именно с точки зрения бухгалтера.
|
||||
|
||||
---
|
||||
|
||||
# 1. От чего идём: целевая способность системы
|
||||
|
||||
Если смотреть от финальной цели назад, то уже на первом этапе система должна приобрести **четыре базовые способности**, без которых всё дальнейшее бессмысленно.
|
||||
|
||||
### 1. Удержание предмета расследования
|
||||
|
||||
Система должна помнить не только историю чата, а **что именно сейчас проверяется**, какие гипотезы открыты, какие сущности уже подняты, какой период и какой контур в фокусе.
|
||||
|
||||
Сейчас этого нет: conversation memory есть, investigation memory model отсутствует.
|
||||
|
||||
### 2. Сужение broad-вопросов до управляемого бухгалтерского профиля
|
||||
|
||||
Система должна перестать считать успехом ситуацию, когда generic chain query narrowed “формально”, но по факту остался почти весь датасет. Это уже подтверждено на текущем контуре: для explicit account scope narrowing сильное, а для generic cross-entity prompts всё ещё слишком широкое.
|
||||
|
||||
### 3. Поднятие механики проблемы в retrieval result
|
||||
|
||||
LLM сейчас получает normalizer output, route summary, normalized retrieval payload и grounding/coverage diagnostics. Но explanation остаётся generic именно потому, что retrieval evidence ещё недостаточно механизмоспецифичен.
|
||||
На первом этапе надо не “сделать тексты красивее”, а поднять вверх поля, из которых можно строить конкретное объяснение.
|
||||
|
||||
### 4. Переход от технической оценки к бухгалтерской полезности
|
||||
|
||||
Сейчас меряется technical pipeline quality, но accountant-facing utility metrics ещё неполные. Это нужно закрыть именно сейчас, иначе дальше система будет “развиваться” по ложным индикаторам.
|
||||
|
||||
---
|
||||
|
||||
# 2. Что сохраняем, а что меняем
|
||||
|
||||
## 2.1. Что сохраняем без архитектурного слома
|
||||
|
||||
Ниже то, что на первом этапе **не переписываем**, а используем как базу:
|
||||
|
||||
* существующий assistant loop;
|
||||
* deterministic routing summary;
|
||||
* normalizer pipeline `normalizer_v2_0_2`;
|
||||
* explainable contract (`requirements`, `coverage_report`, `answer_grounding_check`);
|
||||
* semantic retrieval profile в `executeHybrid`;
|
||||
* debug drawer;
|
||||
* session-scoped conversation continuity;
|
||||
* route set (`store_feature_risk`, `hybrid_store_plus_live`, `batch_refresh_then_store`, `store_canonical`, `live_mcp_drilldown`).
|
||||
|
||||
Это важно: Этап 1 не должен устроить архитектурную ломку.
|
||||
Он должен **усилить текущий контур**, а не заменить его “идеальной системой”.
|
||||
|
||||
---
|
||||
|
||||
## 2.2. Что меняем принципиально
|
||||
|
||||
На первом этапе меняются не все слои, а конкретные места, где уже зафиксирован потолок:
|
||||
|
||||
1. retrieval policy for broad/generic prompts
|
||||
2. retrieval result schema
|
||||
3. answer synthesis policy
|
||||
4. session model
|
||||
5. eval layer
|
||||
6. decomposition guardrail для noisy/translit и multi-intent compression
|
||||
|
||||
---
|
||||
|
||||
## 2.3. От чего сознательно отказываемся на этапе 1
|
||||
|
||||
На этом этапе **не строим**:
|
||||
|
||||
* полноценный ontology graph;
|
||||
* полноценный lifecycle engine;
|
||||
* полноценный investigation orchestrator;
|
||||
* полноценный live verification bridge;
|
||||
* финальный problem-cluster retrieval как default unit.
|
||||
|
||||
Это всё уже названо как следующий архитектурный слой, но не как ближайший P0.
|
||||
|
||||
Но:
|
||||
|
||||
* подготавливаем данные и контракты под эти сущности;
|
||||
* убираем то, что потом будет мешать их внедрению;
|
||||
* не пишем времянки, противоречащие target architecture.
|
||||
|
||||
---
|
||||
|
||||
# 3. Архитектурная цель этапа 1
|
||||
|
||||
К концу этапа текущая система должна перейти из состояния:
|
||||
|
||||
**“работающий explainable routed assistant с semantic narrowing upgrade”**
|
||||
|
||||
в состояние:
|
||||
|
||||
**“устойчивый accountant-facing assistant baseline с session investigation state, усиленным narrowing, mechanism-aware evidence pack и предметными метриками качества”**
|
||||
|
||||
---
|
||||
|
||||
# 4. Главные сущности этапа 1
|
||||
|
||||
Теперь по сущностям — не просто перечисление, а **что с ними делаем и зачем**.
|
||||
|
||||
---
|
||||
|
||||
## 4.1. Сущность №1 — `investigation_state`
|
||||
|
||||
### Почему она нужна
|
||||
|
||||
Сейчас в системе есть session conversation, но нет модели расследования. Это прямо зафиксировано как архитектурный пробел.
|
||||
Из-за этого follow-up может быть связным по чату, но не становится настоящим продолжением анализа.
|
||||
|
||||
### Что не устраивает в текущем состоянии
|
||||
|
||||
Текущая session memory:
|
||||
|
||||
* хранит историю сообщений;
|
||||
* пригодна для continuity;
|
||||
* непригодна для hypothesis-driven analysis.
|
||||
|
||||
Это и есть разрыв между “чатом” и “расследованием”.
|
||||
|
||||
### Что делаем
|
||||
|
||||
Вводим новый слой session model: `investigation_state`.
|
||||
|
||||
### Что именно должно появиться
|
||||
|
||||
Минимальная сущность должна включать:
|
||||
|
||||
* `session_id`
|
||||
* `focus`
|
||||
|
||||
* domain
|
||||
* period
|
||||
* primary_accounts
|
||||
* active_query_subject
|
||||
* `active_entities`
|
||||
* `open_hypotheses`
|
||||
* `checked_hypotheses`
|
||||
* `branches`
|
||||
* `resolved_findings`
|
||||
* `unresolved_findings`
|
||||
* `next_actions`
|
||||
* `evidence_summary`
|
||||
* `working_assumptions`
|
||||
* `query_mode_hint` (`direct_answer` / `investigation_candidate`)
|
||||
|
||||
Базовый schema direction уже есть в отчёте, но на этапе 1 его надо превратить из спецификации в рабочий backend contract.
|
||||
|
||||
### Что не делаем пока
|
||||
|
||||
Не строим полный branch engine и не запускаем автоматическое исследование соседних веток как policy standard. Это следующий слой. Сейчас фиксируем **контейнер состояния**, а не весь investigation orchestrator.
|
||||
|
||||
### Что это даст
|
||||
|
||||
* follow-up перестанет быть просто ещё одним запросом;
|
||||
* broad causal questions можно будет удерживать внутри одного аналитического контекста;
|
||||
* позже сюда без боли встанет hypothesis tracking.
|
||||
|
||||
---
|
||||
|
||||
## 4.2. Сущность №2 — `semantic_retrieval_profile` (усиление, не замена)
|
||||
|
||||
### Почему она нужна
|
||||
|
||||
Она уже есть и уже улучшила retrieval, особенно на explicit accounting scope. Но generic prompts всё ещё narrowing’ятся слишком слабо.
|
||||
|
||||
### Что не устраивает
|
||||
|
||||
Профиль пока:
|
||||
|
||||
* лучше старого GUID-or-full-scan;
|
||||
* но ещё недостаточно жёсткий на широких вопросах;
|
||||
* не всегда переводит broad chain query в достаточно узкий бухгалтерский поиск.
|
||||
|
||||
### Что делаем
|
||||
|
||||
Не переписываем профиль заново, а вводим **mandatory narrowing policy** для проблемных классов запросов.
|
||||
|
||||
### Что добавляем в профиль как обязательные рабочие поля
|
||||
|
||||
Сейчас у вас уже есть account/domain/document/relation/anomaly intersections. На первом этапе надо зафиксировать обязательные блоки:
|
||||
|
||||
* `query_subject`
|
||||
* `account_scope`
|
||||
* `domain_scope`
|
||||
* `document_types`
|
||||
* `entity_types`
|
||||
* `relation_patterns`
|
||||
* `anomaly_patterns`
|
||||
* `ranking_basis`
|
||||
* `explanation_focus`
|
||||
* `minimum_evidence_requirements`
|
||||
* `broad_query_guard`
|
||||
* `scope_confidence`
|
||||
|
||||
### Что меняем в логике
|
||||
|
||||
Если query broad и нет явного account scope, retrieval **не имеет права** просто сделать “semantic narrowing = true” и оставить 242 из 262.
|
||||
Он должен пройти через guardrail policy:
|
||||
|
||||
1. попытка достроить предметный scope из:
|
||||
|
||||
* session focus
|
||||
* domain hints
|
||||
* document hints
|
||||
* relation hints
|
||||
2. если после этого narrowing всё ещё рыхлый:
|
||||
|
||||
* понизить confidence,
|
||||
* пометить result как broad,
|
||||
* ограничить final answer depth,
|
||||
* предложить controlled clarification или drilldown direction.
|
||||
|
||||
### То, от чего отказываемся
|
||||
|
||||
От практики считать успешным любой routed answer, где technically есть profile и narrowing flag. Это ложный индикатор качества.
|
||||
|
||||
### Что это даст
|
||||
|
||||
* меньше pseudo-relevant broad answers;
|
||||
* меньше одинаковых или слишком похожих выдач;
|
||||
* более честная работа с low-specificity prompts.
|
||||
|
||||
---
|
||||
|
||||
## 4.3. Сущность №3 — `mechanism-aware evidence pack`
|
||||
|
||||
### Почему нужна
|
||||
|
||||
В отчёте уже сказано, что explanation generic из-за broad retrieval unit и limited mechanism-specific fields.
|
||||
То есть проблема не в том, что composer не умеет писать, а в том, что наверх приходит недостаточно причинной информации.
|
||||
|
||||
### Что не устраивает сейчас
|
||||
|
||||
Сейчас evidence часто выглядит как:
|
||||
|
||||
* risk factors,
|
||||
* labels,
|
||||
* selection reasons общего типа,
|
||||
* business interpretation шаблонного характера.
|
||||
|
||||
Из-за этого ответ может быть структурно правильным, но семантически слабым. Это видно и по логам: там уже есть “broken_lifecycle”, “posting_mismatch”, “cross_domain_inconsistency”, но эти признаки ещё не собираются в конкретный механизм поломки.
|
||||
|
||||
### Что делаем
|
||||
|
||||
Для `hybrid_store_plus_live` и `store_feature_risk` вводим обязательный `mechanism-aware evidence pack`.
|
||||
|
||||
### Какие поля должны появиться у top item
|
||||
|
||||
Не на уровне идеальной графовой модели, а на текущем data contour:
|
||||
|
||||
* `mechanism_of_failure`
|
||||
* `failed_expected_edge`
|
||||
* `expected_next_step`
|
||||
* `actual_detected_step`
|
||||
* `mechanism_confidence`
|
||||
* `affected_documents`
|
||||
* `affected_postings`
|
||||
* `affected_accounts`
|
||||
* `period_impact_hint`
|
||||
* `business_defect_class`
|
||||
* `requires_neighbor_check`
|
||||
* `is_snapshot_limited`
|
||||
|
||||
### Пример логики
|
||||
|
||||
Не просто:
|
||||
|
||||
* `broken_lifecycle`
|
||||
|
||||
А:
|
||||
|
||||
* expected_next_step = “settlement closure by linked calculation document”
|
||||
* actual_detected_step = “payment reflected, linked closure path not confirmed”
|
||||
* failed_expected_edge = “statement_to_document -> settlement closure”
|
||||
* mechanism_of_failure = “payment recorded without confirmed closure in expected chain”
|
||||
|
||||
### Что сохраняем
|
||||
|
||||
Risk labels остаются, но становятся вторичным слоем, а не единственным объясняющим слоем.
|
||||
|
||||
### Что это даст
|
||||
|
||||
* composer получит материал для case-specific explanation;
|
||||
* даже без ontology graph ответы станут более предметными;
|
||||
* станет видно, где retrieval реально понимает механизм, а где нет.
|
||||
|
||||
---
|
||||
|
||||
## 4.4. Сущность №4 — `answer contract v1.1`
|
||||
|
||||
### Почему нужна
|
||||
|
||||
Формально explainable contract уже реализован. Но user-facing ответы всё ещё могут быть generic и слишком top-entity-heavy.
|
||||
|
||||
### Что не устраивает
|
||||
|
||||
Текущие ответы:
|
||||
|
||||
* лучше, чем раньше;
|
||||
* но всё ещё часто объясняют “по какому профилю искали”, а не “что именно сломано”.
|
||||
|
||||
### Что делаем
|
||||
|
||||
Не переписываем composer с нуля.
|
||||
Меняем policy сборки ответа.
|
||||
|
||||
### Новый принцип
|
||||
|
||||
Ответ должен строиться в следующем порядке:
|
||||
|
||||
1. **что именно найдено**
|
||||
2. **что именно в этом проблемно**
|
||||
3. **какой механизм поломки предполагается**
|
||||
4. **на чём это основано**
|
||||
5. **какие документы/связи это подтверждают**
|
||||
6. **что ограничивает вывод**
|
||||
7. **что проверить дальше**
|
||||
|
||||
А не так:
|
||||
|
||||
* какой route,
|
||||
* какой profile,
|
||||
* какие labels.
|
||||
|
||||
### Что меняем в сборке
|
||||
|
||||
Для problem/explanation answers composer обязан:
|
||||
|
||||
* использовать `mechanism_of_failure` как главный narrative anchor;
|
||||
* использовать `affected_documents` как конкретные опорные объекты;
|
||||
* понижать уверенность, если есть только labels без mechanism;
|
||||
* не выстраивать top narrative вокруг counterparty count, если вопрос не про ranking контрагентов.
|
||||
|
||||
### От чего отказываемся
|
||||
|
||||
От generic text scaffolding вроде:
|
||||
|
||||
* “результат отражает структурные признаки разрыва цепочки”
|
||||
* “объекты приоритетны для проверки”
|
||||
если за этим не следует конкретный case.
|
||||
|
||||
Именно это сейчас делает ответы убедительнее внешне, чем они есть по сути.
|
||||
|
||||
### Что это даст
|
||||
|
||||
Даже без нового retrieval unit ответы уже перестанут быть purely decorative.
|
||||
|
||||
---
|
||||
|
||||
## 4.5. Сущность №5 — `decomposition guardrail`
|
||||
|
||||
### Почему нужна
|
||||
|
||||
Тонкая multi-requirement структура всё ещё может compress’иться, noisy/translit input может терять intent quality. Это уже зафиксировано.
|
||||
|
||||
### Что не устраивает
|
||||
|
||||
Даже если routing и retrieval сильнее, пользовательский вопрос может быть испорчен на раннем этапе:
|
||||
|
||||
* часть требований схлопнулась;
|
||||
* важная гипотеза потерялась;
|
||||
* транслит или бытовая бухгалтерская формулировка испортили intent.
|
||||
|
||||
### Что делаем
|
||||
|
||||
Добавляем не новый LLM-слой, а **guardrail around decomposition**.
|
||||
|
||||
### Что должно появиться
|
||||
|
||||
1. pre-normalization alias layer:
|
||||
|
||||
* транслит,
|
||||
* бытовые бухгалтерские выражения,
|
||||
* alias dictionary
|
||||
2. multi-requirement preservation rule:
|
||||
|
||||
* если в вопросе обнаружено несколько смысловых действий, planner не имеет права silently compress их в один fragment без отметки потери
|
||||
3. decomposition quality flag:
|
||||
|
||||
* `high`
|
||||
* `soft_assumptions_used`
|
||||
* `intent_loss_risk`
|
||||
* `clarification_recommended`
|
||||
|
||||
### От чего отказываемся
|
||||
|
||||
От негласной практики “если route найден, значит декомпозиция достаточная”.
|
||||
|
||||
### Что это даст
|
||||
|
||||
* меньше ложных “зелёных” обработок;
|
||||
* больше честности там, где вопрос реально разобран не полностью;
|
||||
* меньше false out_of_scope и ложных soft assumptions.
|
||||
|
||||
---
|
||||
|
||||
## 4.6. Сущность №6 — `accountant eval layer`
|
||||
|
||||
### Почему нужна
|
||||
|
||||
Сейчас pipeline quality меряется, а accountant-facing utility metrics ещё нет в завершённом виде. Это уже признано P0.
|
||||
|
||||
### Что не устраивает
|
||||
|
||||
Пока нет правильной оценки, команда может улучшать то, что не даёт реальной ценности бухгалтеру.
|
||||
|
||||
### Что делаем
|
||||
|
||||
Строим evaluation layer именно под user value.
|
||||
|
||||
### Обязательные метрики этапа 1
|
||||
|
||||
1. `retrieval_differentiation_rate`
|
||||
2. `generic_explanation_rate`
|
||||
3. `accountant_actionability_score`
|
||||
4. `false_confidence_rate`
|
||||
5. `broad_answer_rate`
|
||||
6. `mechanism_specificity_score`
|
||||
7. `followup_context_retention_score`
|
||||
|
||||
Первые четыре уже названы в отчёте как локально необходимые.
|
||||
|
||||
### Что должно появиться кроме метрик
|
||||
|
||||
Набор канонических сценариев:
|
||||
|
||||
* 51 / неверный тип закрытия
|
||||
* 60 / хвосты поставщиков
|
||||
* 97 / lifecycle anomaly
|
||||
* ОС / карточка vs начисления
|
||||
* НДС / cross-domain contradiction
|
||||
* period close impact
|
||||
* multi-intent
|
||||
* translit
|
||||
* follow-up investigation
|
||||
|
||||
### От чего отказываемся
|
||||
|
||||
От оценки ассистента только по:
|
||||
|
||||
* tests passed,
|
||||
* routed successfully,
|
||||
* grounding green,
|
||||
* coverage 1/1.
|
||||
|
||||
Этого недостаточно.
|
||||
|
||||
### Что это даст
|
||||
|
||||
После Этапа 1 вы впервые сможете мерить не “система работает?”, а “она стала полезнее бухгалтеру или нет”.
|
||||
|
||||
---
|
||||
|
||||
# 5. Полная цепь изменений по контуру
|
||||
|
||||
Теперь соберу это не по сущностям, а по **полной цепи выполнения**.
|
||||
|
||||
---
|
||||
|
||||
## 5.1. Вход сообщения
|
||||
|
||||
### Сейчас
|
||||
|
||||
Сообщение идёт в normalizer, потом в deterministic routing summary.
|
||||
|
||||
### Что меняем
|
||||
|
||||
Перед normalizer добавляется тонкий pre-normalization parser:
|
||||
|
||||
* alias normalization
|
||||
* translit normalization
|
||||
* бытовые бухгалтерские alias
|
||||
* явная фиксация потенциальных multi-requirement markers
|
||||
|
||||
### Цель
|
||||
|
||||
Не дать системе потерять смысл до decomposition.
|
||||
|
||||
---
|
||||
|
||||
## 5.2. Декомпозиция
|
||||
|
||||
### Сейчас
|
||||
|
||||
Есть requirements extraction, coverage report, dropped-intent tracking, но fine-grained multi-requirement structure всё ещё может compress’иться.
|
||||
|
||||
### Что меняем
|
||||
|
||||
* вводим decomposition quality flag;
|
||||
* вводим обязательную маркировку `intent_loss_risk`;
|
||||
* soft assumptions становятся видимыми не только в debug, но и влияют на итоговую reply policy;
|
||||
* broad multi-intent prompts при недостаточном качестве больше не идут в “тихо routed factual answer”.
|
||||
|
||||
### Цель
|
||||
|
||||
Не скрывать слабую декомпозицию за уверенным downstream answer.
|
||||
|
||||
---
|
||||
|
||||
## 5.3. Session model
|
||||
|
||||
### Сейчас
|
||||
|
||||
Есть conversation continuity in-memory, но нет investigation memory.
|
||||
|
||||
### Что меняем
|
||||
|
||||
В backend session store добавляется `investigation_state`.
|
||||
|
||||
### Цель
|
||||
|
||||
Связать текущий вопрос с текущим предметом анализа, а не только с текстом чата.
|
||||
|
||||
---
|
||||
|
||||
## 5.4. Retrieval planning
|
||||
|
||||
### Сейчас
|
||||
|
||||
Semantic retrieval profile есть; generic prompts всё ещё рыхлые.
|
||||
|
||||
### Что меняем
|
||||
|
||||
В profile builder добавляем:
|
||||
|
||||
* broad query guard
|
||||
* minimum evidence requirements
|
||||
* explanation focus
|
||||
* scope confidence
|
||||
* degraded answer policy hints
|
||||
|
||||
### Цель
|
||||
|
||||
Чтобы retrieval перестал быть technically narrowed, но semantically broad.
|
||||
|
||||
---
|
||||
|
||||
## 5.5. Retrieval execution
|
||||
|
||||
### Сейчас
|
||||
|
||||
`executeHybrid` уже использует semantic profile и narrowing; это существенный прогресс. Но generic bank/cross-entity queries всё ещё могут давать слишком широкий набор.
|
||||
|
||||
### Что меняем
|
||||
|
||||
* вводим domain-specific minimum intersections для generic prompts;
|
||||
* добавляем anti-generic ranking guards;
|
||||
* усиливаем lifecycle/account/document extraction из snapshot;
|
||||
* поднимаем mechanism-aware evidence.
|
||||
|
||||
### Цель
|
||||
|
||||
Не просто narrowed retrieval, а retrieval, который уже несёт механизм проблемы.
|
||||
|
||||
---
|
||||
|
||||
## 5.6. Result normalization
|
||||
|
||||
### Сейчас
|
||||
|
||||
Есть normalized retrieval payload, grounding/coverage diagnostics.
|
||||
|
||||
### Что меняем
|
||||
|
||||
Расширяем normalized payload так, чтобы composer получал:
|
||||
|
||||
* mechanism fields
|
||||
* defect class
|
||||
* expected/actual step delta
|
||||
* period impact hint
|
||||
* snapshot limitation flag
|
||||
|
||||
### Цель
|
||||
|
||||
Убрать разрыв между retrieval и answer synthesis.
|
||||
|
||||
---
|
||||
|
||||
## 5.7. Answer synthesis
|
||||
|
||||
### Сейчас
|
||||
|
||||
Composer базовый, sufficient for MVP loop, но не policy-grade layer.
|
||||
|
||||
### Что меняем
|
||||
|
||||
Новый answer policy:
|
||||
|
||||
* route/profile diagnostics уходят на второй план;
|
||||
* основной narrative anchor = mechanism_of_failure;
|
||||
* if mechanism weak -> response confidence down;
|
||||
* if answer broad -> explicit limitation instead of strong conclusion;
|
||||
* if investigation_state active -> answer binds itself to current focus.
|
||||
|
||||
### Цель
|
||||
|
||||
Сделать ответ не более красивым, а более предметным.
|
||||
|
||||
---
|
||||
|
||||
## 5.8. Eval and observability
|
||||
|
||||
### Сейчас
|
||||
|
||||
Есть tests/build/session/debug traces, но нет полного accountant eval harness.
|
||||
|
||||
### Что меняем
|
||||
|
||||
* вводим value-oriented metrics;
|
||||
* фиксируем canonical scenario suite;
|
||||
* отдельно логируем generic explanation rate, broad answer rate, mechanism specificity.
|
||||
|
||||
### Цель
|
||||
|
||||
Сделать качество управляемым, а не субъективным.
|
||||
|
||||
---
|
||||
|
||||
# 6. Что должно быть переписано, а что только усилено
|
||||
|
||||
Это важный раздел, потому что ты просил не общие слова, а прям понять: **что переделываем, а что сохраняем**.
|
||||
|
||||
## Полностью переписывать на этапе 1 не надо:
|
||||
|
||||
* normalizer целиком;
|
||||
* routing engine;
|
||||
* assistant endpoint;
|
||||
* frontend orchestration;
|
||||
* debug plane;
|
||||
* existing assistant loop.
|
||||
|
||||
## Существенно переделываем:
|
||||
|
||||
* session data contract
|
||||
* retrieval profile builder policy
|
||||
* retrieval evidence schema
|
||||
* answer assembly policy
|
||||
* eval harness
|
||||
|
||||
## Частично усиливаем:
|
||||
|
||||
* translit/noisy parser
|
||||
* domain-specific narrowing rules
|
||||
* decomposition loss detection
|
||||
* ranking guards
|
||||
* snapshot signal extraction
|
||||
|
||||
## Осознанно оставляем на следующий этап:
|
||||
|
||||
* ontology graph
|
||||
* lifecycle engine formal
|
||||
* problem-cluster retrieval as default
|
||||
* iterative orchestrator
|
||||
* live verification bridge
|
||||
|
||||
---
|
||||
|
||||
# 7. Архитектурные артефакты, которые должны появиться по итогам этапа
|
||||
|
||||
К концу этапа должны появиться не только кодовые изменения, но и новые артефакты.
|
||||
|
||||
## Обязательные артефакты
|
||||
|
||||
1. `investigation_state` schema
|
||||
2. `semantic_retrieval_profile` vNext contract
|
||||
3. `mechanism_aware_evidence_pack` schema
|
||||
4. `answer_policy_v1_1` spec
|
||||
5. `decomposition_guardrail` spec
|
||||
6. `accountant_eval_harness` spec
|
||||
7. canonical benchmark list
|
||||
8. regression scenarios for broad query narrowing
|
||||
|
||||
---
|
||||
|
||||
# 8. Критерии приёмки этапа
|
||||
|
||||
Этап считается выполненным не когда “код написан”, а когда выполнены следующие условия.
|
||||
|
||||
## 8.1. По состоянию анализа
|
||||
|
||||
* сессия хранит `investigation_state`;
|
||||
* follow-up использует не только chat history, но и active focus / hypotheses / entities;
|
||||
* система умеет явно продолжать предмет анализа в рамках одной темы.
|
||||
|
||||
## 8.2. По retrieval
|
||||
|
||||
* generic cross-entity prompts больше не дают “почти полный” narrowed set без понижения confidence и ограничения depth;
|
||||
* для проблемных route-классов работает broad-query guard;
|
||||
* retrieval result содержит mechanism-aware evidence fields.
|
||||
|
||||
## 8.3. По ответу
|
||||
|
||||
* доля generic explanation заметно снижается;
|
||||
* в ответе появляется конкретная механика дефекта там, где retrieval это реально подтвердил;
|
||||
* ответ больше не строится вокруг labels, если есть mechanism fields;
|
||||
* broad answer не выдаётся как strong factual conclusion.
|
||||
|
||||
## 8.4. По eval
|
||||
|
||||
* введены accountant-facing метрики;
|
||||
* есть канонический benchmark suite;
|
||||
* есть baseline before/after comparison.
|
||||
|
||||
## 8.5. По архитектурной чистоте
|
||||
|
||||
* stage 1 не вносит временных решений, противоречащих последующему ontology/lifecycle/problem-cluster переходу.
|
||||
|
||||
---
|
||||
|
||||
# 9. Что не считается результатом этапа
|
||||
|
||||
Это тоже надо жёстко зафиксировать.
|
||||
|
||||
Этап **не считается выполненным**, если произошло что-то из этого:
|
||||
|
||||
* просто улучшили wording ответов;
|
||||
* просто добавили ещё labels в explanation;
|
||||
* просто сделали narrowing чуть жёстче без broad-query policy;
|
||||
* просто расширили session history;
|
||||
* просто усилили промпт;
|
||||
* просто добавили новые тесты без accountant eval metrics.
|
||||
|
||||
Потому что всё это даёт perceived progress, но не закрывает архитектурную задачу.
|
||||
|
||||
---
|
||||
|
||||
# 10. Практический идеальный результат этапа
|
||||
|
||||
Вот как надо понимать идеальный результат Этапа 1.
|
||||
|
||||
После него система **ещё не будет идеальным бухгалтерским ассистентом**.
|
||||
Но она уже должна перестать быть:
|
||||
|
||||
* случайно умной,
|
||||
* избыточно широкой,
|
||||
* слишком label-driven,
|
||||
* слишком route-centric,
|
||||
* слишком chat-memory-based.
|
||||
|
||||
И должна стать:
|
||||
|
||||
* устойчивой в broad/focused режимах,
|
||||
* способной удерживать предмет анализа,
|
||||
* честной в ограничениях,
|
||||
* механизмо-ориентированной в evidence,
|
||||
* измеримой по бухгалтерской полезности.
|
||||
|
||||
---
|
||||
|
||||
# 11. Короткое управленческое резюме этапа
|
||||
|
||||
Если совсем сжато:
|
||||
|
||||
**Этап 1 — это не попытка построить бухгалтерский copilot.
|
||||
Это этап приведения текущего explainable routed assistant к такому состоянию, в котором он перестаёт разваливаться на broad queries, перестаёт терять предмет расследования, начинает собирать mechanism-aware evidence и начинает измеряться по полезности для бухгалтера.
|
||||
Именно после этого становится рационально переходить к следующему архитектурному слою: problem-cluster retrieval, lifecycle formalization и ontology graph.**
|
||||
|
||||
---
|
||||
|
||||
Следующим сообщением я могу сделать из этого уже **формальный документ ТЗ в жёсткой структуре** — с разделами “цель / границы / изменения по модулям / контракты / acceptance criteria / out of scope”, чтобы это можно было почти без переработки отдавать в работу.
|
||||
+985
@@ -0,0 +1,985 @@
|
||||
# ТЗ Этап 2 — Retrieval Unit Shift для Assistant Mode
|
||||
|
||||
Дата: 2026-03-24
|
||||
Статус документа: рабочее ТЗ на второй этап развития бухгалтерского ассистента
|
||||
Назначение: перевод Assistant Mode от entity-heavy retrieval к problem-centric retrieval и problem-centric answer layer
|
||||
|
||||
---
|
||||
|
||||
# 0. Смысл этапа
|
||||
|
||||
Этап 2 — это первый по-настоящему архитектурный поворот после Foundation Hardening.
|
||||
|
||||
Если Этап 1 должен сделать текущий контур устойчивее, честнее и полезнее для бухгалтера, то Этап 2 меняет саму **единицу смысла**, с которой ассистент работает при поиске, ранжировании и ответе.
|
||||
|
||||
До этого момента система в основном живёт вокруг сущностей:
|
||||
- контрагент;
|
||||
- документ;
|
||||
- группа операций;
|
||||
- набор записей вокруг счёта или контура;
|
||||
- агрегированный риск-профиль по entity group.
|
||||
|
||||
Для бухгалтерского ассистента этого недостаточно. В большинстве реальных пользовательских вопросов предметом интереса является не сущность как таковая, а **механизм дефекта**, **разрыв цепочки**, **конфликтный узел**, **зависший участок жизненного цикла** или **группа связанных несогласованностей**.
|
||||
|
||||
Поэтому задача Этапа 2 — не просто “улучшить retrieval”, а перевести систему от модели:
|
||||
|
||||
**вопрос → поиск сущностей → ranking сущностей → ответ**
|
||||
|
||||
к модели:
|
||||
|
||||
**вопрос → поиск candidate evidence → сборка problem units → ranking problem units → ответ по problem units**
|
||||
|
||||
Это означает, что в Assistant Mode появляется новый обязательный архитектурный слой:
|
||||
|
||||
## Problem Unit Layer
|
||||
|
||||
Именно он должен стать переходом от explainable routed assistant к системе, которая начинает видеть бухгалтерские проблемы как самостоятельные объекты анализа.
|
||||
|
||||
---
|
||||
|
||||
# 1. Исходная точка этапа
|
||||
|
||||
К началу Этапа 2 система уже должна иметь результаты Этапа 1:
|
||||
|
||||
- baseline `investigation_state`;
|
||||
- усиленный `semantic_retrieval_profile`;
|
||||
- `mechanism-aware evidence pack`;
|
||||
- `answer_policy_v1_1`;
|
||||
- `decomposition_guardrail`;
|
||||
- accountant-facing eval metrics;
|
||||
- broad-query guard для generic prompts.
|
||||
|
||||
Этап 2 **не переписывает** эти сущности, а использует их как фундамент.
|
||||
|
||||
Этап 2 стартует из состояния, в котором:
|
||||
- retrieval уже не является чистым GUID-or-full-scan;
|
||||
- narrowing по explicit accounting scope уже работает заметно лучше;
|
||||
- evidence pack уже богаче, чем на MVP-этапе;
|
||||
- но dominant retrieval unit по-прежнему часто остаётся counterparty-heavy;
|
||||
- explanation всё ещё склонен строиться вокруг entities, а не вокруг механизмов дефекта;
|
||||
- broad causal questions всё ещё могут приводить к ответу “кто шумит”, а не “что сломано и почему”.
|
||||
|
||||
Именно это состояние является точкой входа для Этапа 2.
|
||||
|
||||
---
|
||||
|
||||
# 2. Целевая способность этапа
|
||||
|
||||
На выходе Этапа 2 система должна уметь не только находить релевантные бухгалтерские сущности, но и формировать **problem-centric view**.
|
||||
|
||||
В user-facing и internal retrieval логике базовой единицей ответа для problem/anomaly/chain/period-risk запросов должна стать не только сущность, а один из problem unit типов.
|
||||
|
||||
## Базовые target units второго этапа
|
||||
|
||||
1. `document_conflict`
|
||||
2. `broken_chain_segment`
|
||||
3. `lifecycle_anomaly_node`
|
||||
4. `unresolved_settlement_cluster`
|
||||
5. `period_risk_cluster`
|
||||
6. `cross_branch_inconsistency_cluster`
|
||||
|
||||
После завершения этапа эти units должны стать first-class citizens в:
|
||||
- retrieval output;
|
||||
- normalized payload;
|
||||
- ranking;
|
||||
- answer composition;
|
||||
- eval.
|
||||
|
||||
---
|
||||
|
||||
# 3. Что именно не устраивает в текущей архитектуре
|
||||
|
||||
## 3.1. Entity-heavy retrieval unit
|
||||
|
||||
Текущий dominant retrieval unit часто сводится к counterparty group, группе документов или aggregate-risk группе. Это допустимо для:
|
||||
- quick ranking;
|
||||
- первичного surfacing;
|
||||
- общего operational scan.
|
||||
|
||||
Но это ломает качество ответа в вопросах вида:
|
||||
- что именно разорвано в цепочке;
|
||||
- что закрыто не тем документом;
|
||||
- какая стадия lifecycle противоречива;
|
||||
- что именно блокирует закрытие периода;
|
||||
- где банк, документ и проводка живут отдельно;
|
||||
- где проблема не в сумме, а в механике жизненного цикла.
|
||||
|
||||
Для этих вопросов entity-heavy top unit приводит к неправильному уровню abstraction. Пользователь получает:
|
||||
- контрагента;
|
||||
- счётчик документов;
|
||||
- общие labels;
|
||||
- общий risk summary.
|
||||
|
||||
Но не получает:
|
||||
- сам механизм поломки;
|
||||
- конкретный конфликт;
|
||||
- точку разрыва;
|
||||
- набор документов, образующих дефект;
|
||||
- бухгалтерский смысл дефекта как problem object.
|
||||
|
||||
## 3.2. Explanation по-прежнему слишком завязан на entities
|
||||
|
||||
Даже при наличии более богатого evidence answer layer склонен собирать narrative вокруг “кто оказался в top”, а не вокруг “что именно сломалось”.
|
||||
|
||||
В результате появляется ложная глубина:
|
||||
- labels становятся богаче;
|
||||
- текст становится длиннее;
|
||||
- retrieval narrowing становится аккуратнее;
|
||||
- но для бухгалтера всё ещё неочевидно, где именно problem node.
|
||||
|
||||
## 3.3. Нет промежуточного слоя problem assembly
|
||||
|
||||
Между retrieval и answer synthesis сейчас недостаточно оформлен слой, который из отдельных:
|
||||
- документов;
|
||||
- проводок;
|
||||
- relation hints;
|
||||
- lifecycle hints;
|
||||
- anomaly patterns;
|
||||
- linked entities
|
||||
|
||||
собирал бы **одну бухгалтерскую проблему** как отдельный объект.
|
||||
|
||||
Пока этого нет, answer composer вынужден работать почти напрямую по retrieval entities и агрегациям. Это и есть главный архитектурный предел текущего контура.
|
||||
|
||||
---
|
||||
|
||||
# 4. Цель этапа в одной фразе
|
||||
|
||||
**Этап 2 переводит Assistant Mode от поиска и ранжирования сущностей к поиску, сборке, ранжированию и объяснению problem units как самостоятельных бухгалтерских объектов анализа.**
|
||||
|
||||
---
|
||||
|
||||
# 5. Основная архитектурная идея этапа
|
||||
|
||||
Этап 2 вводит между retrieval execution и final answer composition новый слой:
|
||||
|
||||
## Problem Unit Assembler
|
||||
|
||||
Именно этот слой должен:
|
||||
- принимать candidate evidence от route executors;
|
||||
- группировать его в problem-centric узлы;
|
||||
- определять тип problem unit;
|
||||
- собирать mechanism summary;
|
||||
- собирать affected documents / postings / accounts / counterparties / contracts;
|
||||
- вычислять severity;
|
||||
- готовить ranking inputs;
|
||||
- передавать наверх уже не только entities, но и problem objects.
|
||||
|
||||
После этого answer composer должен строить narrative уже от problem unit.
|
||||
|
||||
---
|
||||
|
||||
# 6. Что сохраняем на Этапе 2
|
||||
|
||||
На Этапе 2 не ломаем базу Этапа 1. Сохраняются:
|
||||
|
||||
- `assistant loop`;
|
||||
- `normalizer_v2_0_2` и его successors без полной переписки;
|
||||
- deterministic routing summary;
|
||||
- `investigation_state` baseline;
|
||||
- `semantic_retrieval_profile`;
|
||||
- `mechanism-aware evidence pack`;
|
||||
- `answer_policy_v1_1` как базовый policy layer;
|
||||
- debug plane / trace logging / session logging;
|
||||
- broad-query guard;
|
||||
- accountant eval layer.
|
||||
|
||||
Этап 2 — это **надстройка архитектурной глубины**, а не слом текущего assistive loop.
|
||||
|
||||
---
|
||||
|
||||
# 7. Что меняем принципиально
|
||||
|
||||
На этом этапе принципиально меняются следующие узлы:
|
||||
|
||||
1. retrieval output model;
|
||||
2. result normalization;
|
||||
3. ranking model;
|
||||
4. answer assembly logic for anomaly/chain/problem classes;
|
||||
5. evaluation model for quality of problem identification.
|
||||
|
||||
То есть меняется не только “что retrieval нашёл”, но и **что считается итоговым объектом поиска**.
|
||||
|
||||
---
|
||||
|
||||
# 8. Проблемные единицы (problem units): полная предметная спецификация
|
||||
|
||||
Ниже перечислены problem unit типы, которые должны стать first-class retrieval units на этом этапе.
|
||||
|
||||
## 8.1. `document_conflict`
|
||||
|
||||
### Смысл
|
||||
`document_conflict` — это problem unit, в котором конфликт сосредоточен вокруг документа или набора документов, играющих противоречивую роль в ожидаемой бухгалтерской цепочке.
|
||||
|
||||
### Когда возникает
|
||||
- документ есть, но его тип не соответствует ожидаемой роли;
|
||||
- документ формально подтверждает этап, но не тот этап, который должен быть закрыт;
|
||||
- документ закрыл цепочку не тем способом;
|
||||
- один документ противоречит другому в рамках expected flow;
|
||||
- тип документа допустим технически, но бухгалтерски некорректен для конкретного механизма закрытия;
|
||||
- документ связан с проводкой или движением так, что возникает смысловой конфликт между документным и учетным контуром.
|
||||
|
||||
### Примеры в бухгалтерском контексте
|
||||
- закрытие расчёта прошло документом, не соответствующим ожидаемому settlement path;
|
||||
- по банку есть отражение движения, но расчётный документ, который должен был подтвердить closure, не найден или найден документ иного класса;
|
||||
- документ реализации/поступления в цепочке присутствует, но не подтверждает ту роль, которую system expected based on flow;
|
||||
- в period close задействована ручная операция, которая подменяет ожидаемую типовую связку.
|
||||
|
||||
### Какие сущности из 1С обычно участвуют
|
||||
- `Document_*` объекты из snapshot;
|
||||
- журнал документов;
|
||||
- linked recorder refs;
|
||||
- register-related movements;
|
||||
- payment / bank statement documents;
|
||||
- realization / receipt / invoice docs;
|
||||
- manual operations / adjustment docs;
|
||||
- posting evidence.
|
||||
|
||||
### Какие связи обязательны
|
||||
- `document_to_posting`;
|
||||
- `statement_to_document`;
|
||||
- `contract_to_documents`;
|
||||
- expected document class vs actual document class.
|
||||
|
||||
### Какой вопрос этот unit должен закрывать
|
||||
- чем именно этот документ конфликтен;
|
||||
- какую роль он должен был играть;
|
||||
- какую роль он играет фактически;
|
||||
- почему это problem, а не просто запись по контрагенту.
|
||||
|
||||
---
|
||||
|
||||
## 8.2. `broken_chain_segment`
|
||||
|
||||
### Смысл
|
||||
`broken_chain_segment` — это problem unit, в котором проблемой является не единичная сущность, а разрыв или дефект в expected accounting chain.
|
||||
|
||||
### Когда возникает
|
||||
- шаги цепочки подтверждены не полностью;
|
||||
- одна связь в expected flow не подтверждена;
|
||||
- документы, проводки и регистры существуют, но не собираются в непротиворечивый segment;
|
||||
- движение денег отделено от расчётного закрытия;
|
||||
- документ есть, проводка есть, но chain continuity не доказана;
|
||||
- ожидаемый next step не найден.
|
||||
|
||||
### Примеры в бухгалтерском контексте
|
||||
- выписка есть, но корректное подтверждение расчётного closure не найдено;
|
||||
- документ и проводка живут отдельно друг от друга;
|
||||
- поступление и расчётный контур не дошли до ожидаемого завершения;
|
||||
- запись в одном контуре есть, но соседний участок не подтверждает expected continuation.
|
||||
|
||||
### Какие сущности из 1С участвуют
|
||||
- bank statements;
|
||||
- settlement documents;
|
||||
- postings;
|
||||
- document journals;
|
||||
- recorder refs;
|
||||
- contracts;
|
||||
- counterparties;
|
||||
- associated registers.
|
||||
|
||||
### Какие relation patterns обязательны
|
||||
- `payment_to_settlement`;
|
||||
- `statement_to_document`;
|
||||
- `document_to_posting`;
|
||||
- `contract_to_documents`.
|
||||
|
||||
### Что должен уметь объяснить unit
|
||||
- где именно chain breaks;
|
||||
- какой шаг expected, но не найден;
|
||||
- что подтверждено, а что нет;
|
||||
- почему дефект относится к цепочке, а не к одной записи.
|
||||
|
||||
---
|
||||
|
||||
## 8.3. `lifecycle_anomaly_node`
|
||||
|
||||
### Смысл
|
||||
`lifecycle_anomaly_node` — это problem unit для объектов, у которых ключевой дефект заключается в противоречивом, зависшем или неестественном жизненном цикле.
|
||||
|
||||
### Когда возникает
|
||||
- объект завис между ожидаемыми стадиями;
|
||||
- объект формально активен, но по смыслу уже должен был перейти дальше;
|
||||
- жизненный цикл не завершён там, где ожидалось завершение;
|
||||
- есть contradictory lifecycle signs;
|
||||
- expected continuation missing.
|
||||
|
||||
### Ключевые бухгалтерские зоны
|
||||
- `97` / расходы будущих периодов;
|
||||
- ОС (`01/02/08`);
|
||||
- авансы / расчёты;
|
||||
- НДС / вычетный контур;
|
||||
- period close affecting residual objects.
|
||||
|
||||
### Какие сущности участвуют
|
||||
- object card / object-like document representation;
|
||||
- amortization or writeoff signals;
|
||||
- linked postings;
|
||||
- document references;
|
||||
- dates and period boundaries;
|
||||
- close-related records.
|
||||
|
||||
### Примеры
|
||||
- РБП живёт дольше ожидаемого срока списания;
|
||||
- объект ОС принят, но следующий lifecycle stage не подтверждён или противоречив;
|
||||
- начисления идут, а карточка/статус не подтверждают expected lifecycle;
|
||||
- объект завис в промежуточной стадии перед close.
|
||||
|
||||
### Что unit должен уметь объяснить
|
||||
- в какой стадии объект находится фактически;
|
||||
- какая стадия ожидалась;
|
||||
- почему это anomaly;
|
||||
- чем это опасно для бухгалтера или close.
|
||||
|
||||
---
|
||||
|
||||
## 8.4. `unresolved_settlement_cluster`
|
||||
|
||||
### Смысл
|
||||
Это cluster, в котором проблема живёт не в одном документе и не в одной записи, а в группе взаимосвязанных незакрытых, конфликтующих или спорящих settlement elements.
|
||||
|
||||
### Когда возникает
|
||||
- несколько документов/платежей/связей претендуют на одно closure;
|
||||
- есть незакрытая группа обязательств;
|
||||
- payment path и settlement path расходятся на группе объектов;
|
||||
- проблема повторяется в пределах одного контрагента, договора или расчётного участка;
|
||||
- cluster нельзя корректно свести к одному document conflict.
|
||||
|
||||
### Где особенно важен
|
||||
- расчёты с поставщиками (`60`);
|
||||
- расчёты с покупателями (`62`);
|
||||
- банковый и расчётный контур (`51/60`, `51/62`);
|
||||
- прочие расчёты (`76`).
|
||||
|
||||
### Какие сущности участвуют
|
||||
- counterparty;
|
||||
- contract;
|
||||
- payment docs;
|
||||
- settlement docs;
|
||||
- postings;
|
||||
- bank statements;
|
||||
- grouped residual/problem records.
|
||||
|
||||
### Что должно быть видно бухгалтеру
|
||||
- что проблема не в одном объекте, а в cluster;
|
||||
- какие документы и контуры в него входят;
|
||||
- почему cluster unresolved;
|
||||
- какой механизм незавершённости в нём доминирует.
|
||||
|
||||
---
|
||||
|
||||
## 8.5. `period_risk_cluster`
|
||||
|
||||
### Смысл
|
||||
Это problem unit, в котором основным критерием значимости становится не просто anomaly, а влияние на закрытие периода и period-sensitive correctness.
|
||||
|
||||
### Когда возникает
|
||||
- дефект затрагивает регламентные операции;
|
||||
- есть residuals/разрывы, критичные для month-end;
|
||||
- есть cluster, который не даёт корректно завершить period close;
|
||||
- есть серия дефектов, которые individually невелики, но collectively опасны для закрытия.
|
||||
|
||||
### Какие сущности участвуют
|
||||
- period close markers;
|
||||
- closing operations;
|
||||
- residual/problem records;
|
||||
- deferred expenses;
|
||||
- VAT-related records;
|
||||
- unresolved settlements;
|
||||
- lifecycle anomalies around period boundary.
|
||||
|
||||
### Что unit должен объяснить
|
||||
- как именно эта проблема влияет на close;
|
||||
- на какой период / boundary она ложится;
|
||||
- это локальный хвост или systemic close risk.
|
||||
|
||||
---
|
||||
|
||||
## 8.6. `cross_branch_inconsistency_cluster`
|
||||
|
||||
### Смысл
|
||||
Это cluster, в котором проблема проявляется как расхождение между соседними ветками учёта.
|
||||
|
||||
### Когда возникает
|
||||
- один контур подтверждает наличие шага, другой — нет;
|
||||
- документный контур и проводочный контур расходятся;
|
||||
- расчётный и банковый контур не согласованы;
|
||||
- карточка объекта и фактические начисления противоречат друг другу;
|
||||
- налоговый контур и документный контур расходятся.
|
||||
|
||||
### Где это особенно важно
|
||||
- банк / расчёты;
|
||||
- ОС / начисления;
|
||||
- НДС / документное основание;
|
||||
- close / остатки / lifecycle-sensitive objects.
|
||||
|
||||
### Какие сущности участвуют
|
||||
- минимум две ветки учёта;
|
||||
- relation hints между ними;
|
||||
- conflict evidence;
|
||||
- documents/postings/register movements from both sides.
|
||||
|
||||
### Что unit должен объяснить
|
||||
- какие ветки не согласованы;
|
||||
- в чём именно противоречие;
|
||||
- какая ветка говорит одно, а какая другое;
|
||||
- почему это problem для бухгалтера.
|
||||
|
||||
---
|
||||
|
||||
# 9. Новый архитектурный слой: Problem Unit Assembler
|
||||
|
||||
## 9.1. Назначение
|
||||
|
||||
`ProblemUnitAssembler` — это обязательный backend-слой между route retrieval и final answer composition.
|
||||
|
||||
Его задача:
|
||||
- принимать candidate evidence from executors;
|
||||
- строить промежуточные problem hypotheses;
|
||||
- агрегировать evidence в problem-centric объекты;
|
||||
- нормализовать их в единый schema;
|
||||
- передавать problem units в ranking pipeline и answer synthesis.
|
||||
|
||||
## 9.2. Почему нужен отдельный слой
|
||||
|
||||
Если просто попытаться “ранжировать problem units прямо в retrieval executor”, логика быстро расползётся:
|
||||
- domain-specific heuristics смешаются с retrieval;
|
||||
- answer layer по-прежнему будет видеть сырой payload;
|
||||
- unit transition будет неполным;
|
||||
- тестирование будет хуже.
|
||||
|
||||
Assembler нужен именно как отдельная ответственность:
|
||||
|
||||
- retrieval = найти candidate evidence;
|
||||
- assembler = понять, какие evidence образуют одну проблему;
|
||||
- ranking = определить приоритет problem unit;
|
||||
- answer layer = объяснить problem unit бухгалтеру.
|
||||
|
||||
## 9.3. Входные данные assembler
|
||||
|
||||
Assembler должен принимать:
|
||||
- normalized retrieval items;
|
||||
- relation pattern hits;
|
||||
- anomaly patterns;
|
||||
- mechanism-aware evidence fields;
|
||||
- selected route metadata;
|
||||
- current `investigation_state` focus;
|
||||
- ranking basis;
|
||||
- confidence hints.
|
||||
|
||||
## 9.4. Выходные данные assembler
|
||||
|
||||
Assembler должен отдавать список `problem_units`.
|
||||
|
||||
Каждый problem unit должен включать:
|
||||
- `problem_unit_id`
|
||||
- `problem_unit_type`
|
||||
- `title`
|
||||
- `mechanism_summary`
|
||||
- `business_defect_class`
|
||||
- `severity`
|
||||
- `confidence`
|
||||
- `affected_entities`
|
||||
- `affected_documents`
|
||||
- `affected_postings`
|
||||
- `affected_accounts`
|
||||
- `affected_counterparties`
|
||||
- `affected_contracts`
|
||||
- `expected_state`
|
||||
- `actual_state`
|
||||
- `failed_expected_edge`
|
||||
- `period_impact`
|
||||
- `evidence_pack`
|
||||
- `entity_backlinks`
|
||||
- `requires_neighbor_check`
|
||||
- `snapshot_limitations`
|
||||
|
||||
## 9.5. Базовая логика сборки
|
||||
|
||||
Assembler обязан работать в несколько шагов:
|
||||
|
||||
### Шаг 1. Candidate evidence clustering
|
||||
Группировка candidate evidence по:
|
||||
- общим документам;
|
||||
- общим expected/actual mechanism patterns;
|
||||
- общему settlement path;
|
||||
- общему lifecycle defect signature;
|
||||
- пересекающимся contracts/counterparties/accounts;
|
||||
- period boundary.
|
||||
|
||||
### Шаг 2. Problem hypothesis detection
|
||||
Для каждой candidate cluster assembler пытается понять, является ли cluster:
|
||||
- document conflict;
|
||||
- broken chain;
|
||||
- lifecycle anomaly;
|
||||
- unresolved settlement;
|
||||
- period risk;
|
||||
- cross-branch inconsistency.
|
||||
|
||||
### Шаг 3. Problem normalization
|
||||
Cluster превращается в normalized problem unit.
|
||||
|
||||
### Шаг 4. Duplicate collapse
|
||||
Разные evidence, относящиеся к одной и той же проблеме, должны быть collapsed в один problem unit.
|
||||
|
||||
### Шаг 5. Severity scoring inputs
|
||||
На unit наслаиваются severity и ranking signals.
|
||||
|
||||
---
|
||||
|
||||
# 10. Схема данных problem unit
|
||||
|
||||
Ниже — обязательный target schema второго этапа.
|
||||
|
||||
```json
|
||||
{
|
||||
"problem_unit_id": "pu_...",
|
||||
"problem_unit_type": "document_conflict",
|
||||
"title": "Платёж отражён, но ожидаемое закрытие обязательства не подтверждено",
|
||||
"mechanism_summary": "По цепочке payment -> settlement closure найдено отражение оплаты, но не подтверждён ожидаемый документный шаг закрытия",
|
||||
"business_defect_class": "wrong_closure_path",
|
||||
"severity": {
|
||||
"score": 0.0,
|
||||
"grade": "high"
|
||||
},
|
||||
"confidence": {
|
||||
"score": 0.0,
|
||||
"grade": "medium"
|
||||
},
|
||||
"affected_entities": [],
|
||||
"affected_documents": [],
|
||||
"affected_postings": [],
|
||||
"affected_accounts": [],
|
||||
"affected_counterparties": [],
|
||||
"affected_contracts": [],
|
||||
"expected_state": "closure by linked settlement chain",
|
||||
"actual_state": "payment reflected without confirmed closure edge",
|
||||
"failed_expected_edge": "statement_to_document -> payment_to_settlement",
|
||||
"period_impact": {
|
||||
"is_period_sensitive": true,
|
||||
"impact_class": "close_risk"
|
||||
},
|
||||
"requires_neighbor_check": true,
|
||||
"snapshot_limitations": [],
|
||||
"evidence_pack": [],
|
||||
"entity_backlinks": []
|
||||
}
|
||||
```
|
||||
|
||||
Эта схема должна быть реализована как first-class backend contract.
|
||||
|
||||
---
|
||||
|
||||
# 11. Ranking второго этапа
|
||||
|
||||
## 11.1. Общий принцип
|
||||
|
||||
Ranking больше не должен быть entity-first.
|
||||
|
||||
На этом этапе ranking должен отвечать на вопрос:
|
||||
**какая problem unit важнее для бухгалтера**, а не **какая entity чаще всплыла**.
|
||||
|
||||
## 11.2. Базовые ranking factors
|
||||
|
||||
Для problem unit ranking обязателен набор факторов:
|
||||
- mechanism severity;
|
||||
- confidence of mechanism;
|
||||
- period impact;
|
||||
- repeatability;
|
||||
- cross-branch involvement;
|
||||
- number of affected documents/postings;
|
||||
- unresolved state persistence;
|
||||
- financial impact (не единственный и не всегда доминирующий);
|
||||
- settlement criticality;
|
||||
- lifecycle defect severity;
|
||||
- manual intervention suspicion;
|
||||
- cluster completeness.
|
||||
|
||||
## 11.3. Особое правило
|
||||
|
||||
Если пользователь explicitly спрашивает про:
|
||||
- wrong document type;
|
||||
- lifecycle defect;
|
||||
- chain break;
|
||||
- period close impact;
|
||||
|
||||
то ranking **не имеет права** доминировать по amount/frequency alone.
|
||||
|
||||
## 11.4. Mixed-unit transition policy
|
||||
|
||||
На втором этапе допускается mixed ranking:
|
||||
- primary ranking unit = problem unit;
|
||||
- secondary context = entity context (counterparty/document/account).
|
||||
|
||||
Но итоговый answer layer должен строиться от problem unit.
|
||||
|
||||
---
|
||||
|
||||
# 12. Изменения по модулям и слоям
|
||||
|
||||
## 12.1. `assistantDataLayer.ts` / route executors
|
||||
|
||||
### Что не меняем
|
||||
- существующие route executors;
|
||||
- semantic retrieval profile;
|
||||
- retrieval narrowing logic как базу.
|
||||
|
||||
### Что добавляем
|
||||
- обязательный output contract для candidate evidence;
|
||||
- более жёсткую нормализацию relation pattern evidence;
|
||||
- grouping-friendly identifiers;
|
||||
- explicit expected/actual fields;
|
||||
- normalized document references suitable for clustering.
|
||||
|
||||
### Что важно
|
||||
Executors на этом этапе **не должны** превращаться в полноценные graph reasoners. Их задача — готовить candidate evidence, а не подменять assembler.
|
||||
|
||||
---
|
||||
|
||||
## 12.2. Новый модуль `problemUnitAssembler`
|
||||
|
||||
### Назначение
|
||||
Собирает problem units из candidate evidence.
|
||||
|
||||
### Обязательные подфункции
|
||||
- `clusterCandidateEvidence(...)`
|
||||
- `detectProblemUnitType(...)`
|
||||
- `buildProblemUnit(...)`
|
||||
- `collapseDuplicates(...)`
|
||||
- `scoreProblemSeverity(...)`
|
||||
- `linkBackToEntities(...)`
|
||||
|
||||
### Что должно быть отдельно
|
||||
Domain helpers могут быть вынесены в:
|
||||
- bank/settlements;
|
||||
- suppliers/customers;
|
||||
- deferred expenses;
|
||||
- fixed assets;
|
||||
- VAT;
|
||||
- period close.
|
||||
|
||||
Но core assembler должен оставаться общим.
|
||||
|
||||
---
|
||||
|
||||
## 12.3. `resultNormalization`
|
||||
|
||||
### Что меняем
|
||||
Normalized payload должен научиться содержать два уровня:
|
||||
- `raw_entities`
|
||||
- `problem_units`
|
||||
|
||||
Для backward compatibility entity payload сохраняется.
|
||||
|
||||
### Новый принцип
|
||||
Answer layer для определённых query classes работает прежде всего по `problem_units`.
|
||||
|
||||
---
|
||||
|
||||
## 12.4. `answerComposer`
|
||||
|
||||
### Что меняем
|
||||
Composer должен получить новый режим сборки:
|
||||
|
||||
- direct factual / entity mode;
|
||||
- problem-centric mode.
|
||||
|
||||
### Когда использовать problem-centric mode
|
||||
- chain/anomaly questions;
|
||||
- wrong-document questions;
|
||||
- period-risk questions;
|
||||
- lifecycle questions;
|
||||
- cross-branch inconsistency questions.
|
||||
|
||||
### Новый narrative order
|
||||
Для problem-centric mode answer composer обязан строить ответ в порядке:
|
||||
1. problem unit;
|
||||
2. mechanism;
|
||||
3. affected documents/entities;
|
||||
4. why this matters;
|
||||
5. limitation / confidence;
|
||||
6. next check.
|
||||
|
||||
### От чего отказываемся
|
||||
От top-entity narrative по умолчанию для chain/anomaly/period-risk routes.
|
||||
|
||||
---
|
||||
|
||||
## 12.5. `assistantSessionStore` / session model
|
||||
|
||||
### Что меняем
|
||||
`investigation_state` должен уметь хранить ссылки не только на entities, но и на `problem_units`.
|
||||
|
||||
### Что добавляем
|
||||
- `active_problem_units`
|
||||
- `resolved_problem_units`
|
||||
- `problem_unit_backlinks`
|
||||
- `investigation_focus.problem_types`
|
||||
|
||||
### Зачем
|
||||
Чтобы follow-up мог продолжать анализ уже не по entities alone, а по problem structure.
|
||||
|
||||
---
|
||||
|
||||
## 12.6. Eval / benchmark harness
|
||||
|
||||
### Что добавляем
|
||||
Новые метрики второго этапа:
|
||||
- `problem_unit_precision`
|
||||
- `problem_unit_recall_proxy`
|
||||
- `duplicate_collapse_rate`
|
||||
- `mechanism_coherence_score`
|
||||
- `problem_clarity_score`
|
||||
- `problem_first_answer_rate`
|
||||
- `entity_leakage_rate`
|
||||
|
||||
### Новый benchmark suite
|
||||
Канонические сценарии должны проверять, что top ответа — это problem unit, а не просто entity group.
|
||||
|
||||
---
|
||||
|
||||
# 13. Предметная привязка к данным 1С
|
||||
|
||||
Второй этап должен быть не абстрактным AI-слоем, а слоем, который структурно использует реальные сущности, забираемые из 1С snapshot/access contour.
|
||||
|
||||
## 13.1. Базовые типы данных, которые должны участвовать в problem assembly
|
||||
|
||||
### Документы
|
||||
- банковские документы;
|
||||
- платёжные документы;
|
||||
- поступление товаров/услуг;
|
||||
- реализация;
|
||||
- счёт-фактура;
|
||||
- корректировки;
|
||||
- ручные операции;
|
||||
- документы, связанные с РБП;
|
||||
- документы ОС;
|
||||
- close/period-sensitive docs.
|
||||
|
||||
### Проводки
|
||||
- posting evidence;
|
||||
- posting contexts;
|
||||
- account hits;
|
||||
- expected account-role vs actual account-role.
|
||||
|
||||
### Регистры
|
||||
- VAT-related register records;
|
||||
- accumulation/register evidence;
|
||||
- other record types available in snapshot.
|
||||
|
||||
### Справочные сущности
|
||||
- контрагент;
|
||||
- договор;
|
||||
- организация;
|
||||
- ответственное лицо;
|
||||
- объект ОС;
|
||||
- object-like identifiers from snapshot.
|
||||
|
||||
### Периодные поля
|
||||
- даты;
|
||||
- boundary markers;
|
||||
- period-sensitive groupings.
|
||||
|
||||
## 13.2. Как использовать эти данные
|
||||
|
||||
Нельзя ограничиться тем, чтобы просто передать их в answer layer.
|
||||
|
||||
Нужно:
|
||||
- сгруппировать их в problem-centric clusters;
|
||||
- определить, какая комбинация документов и проводок образует defect class;
|
||||
- определить expected flow и actual flow;
|
||||
- показать, как 1С-объекты подтверждают mechanism.
|
||||
|
||||
---
|
||||
|
||||
# 14. Реализация по классам бухгалтерских контуров
|
||||
|
||||
На Этапе 2 не надо покрывать всю бухгалтерию одинаково глубоко. Но нужно выбрать ключевые контуры, в которых problem-centric retrieval особенно нужен.
|
||||
|
||||
## 14.1. Банк / расчёты (`51/60`, `51/62`)
|
||||
|
||||
### Почему это P0-домен
|
||||
Именно здесь чаще всего видны:
|
||||
- wrong closure path;
|
||||
- chain breaks;
|
||||
- settlement inconsistencies;
|
||||
- bank/document/posting divergence.
|
||||
|
||||
### Что должно появиться
|
||||
- `document_conflict` по wrong closure type;
|
||||
- `broken_chain_segment` для bank → document → settlement;
|
||||
- `unresolved_settlement_cluster` по payment + closure mismatch.
|
||||
|
||||
---
|
||||
|
||||
## 14.2. Поставщики / покупатели (`60`, `62`, `76`)
|
||||
|
||||
### Что должно появиться
|
||||
- clusters незакрытых расчётов;
|
||||
- conflict groups, где несколько документов и оплат спорят между собой;
|
||||
- problem units по repeated settlement issues.
|
||||
|
||||
---
|
||||
|
||||
## 14.3. `97` / deferred expenses
|
||||
|
||||
### Что должно появиться
|
||||
- `lifecycle_anomaly_node`;
|
||||
- period-sensitive risk cluster;
|
||||
- explicit expected/actual lifecycle description.
|
||||
|
||||
---
|
||||
|
||||
## 14.4. ОС (`01/02/08`)
|
||||
|
||||
### Что должно появиться
|
||||
- lifecycle anomaly units;
|
||||
- cross-branch inconsistency between card/state and actual accounting behavior;
|
||||
- period-sensitive risk where relevant.
|
||||
|
||||
---
|
||||
|
||||
## 14.5. НДС / tax-related cross-branch zones
|
||||
|
||||
### Что должно появиться
|
||||
- `cross_branch_inconsistency_cluster`;
|
||||
- problem unit between document basis and tax reflection;
|
||||
- period-close-sensitive tax risk clusters where evidence supports it.
|
||||
|
||||
---
|
||||
|
||||
# 15. Порядок выполнения внутри этапа
|
||||
|
||||
Чтобы этап не расползся, он должен идти в строгой последовательности.
|
||||
|
||||
## Шаг 1. Спецификация problem units
|
||||
|
||||
Нужно зафиксировать:
|
||||
- полный schema;
|
||||
- типы units;
|
||||
- базовые domain mappings;
|
||||
- ranking inputs;
|
||||
- answer requirements.
|
||||
|
||||
## Шаг 2. Candidate evidence contract hardening
|
||||
|
||||
Executors и normalization должны начать отдавать grouping-friendly evidence.
|
||||
|
||||
## Шаг 3. Реализация Problem Unit Assembler
|
||||
|
||||
Assembler должен появиться как отдельный backend service.
|
||||
|
||||
## Шаг 4. Mixed ranking
|
||||
|
||||
Переход от entity-first ranking к problem-first ranking.
|
||||
|
||||
## Шаг 5. Problem-centric answer mode
|
||||
|
||||
Answer composer должен уметь строить narrative от problem units.
|
||||
|
||||
## Шаг 6. Benchmarks и eval
|
||||
|
||||
Проверяем, что система реально стала problem-centric, а не только переименовала top entities.
|
||||
|
||||
---
|
||||
|
||||
# 16. Что не делаем на этапе 2
|
||||
|
||||
На этом этапе **не надо**:
|
||||
|
||||
- строить полный ontology graph;
|
||||
- строить полный lifecycle engine с state machine по всем доменам;
|
||||
- строить full investigation orchestrator;
|
||||
- строить live verification bridge;
|
||||
- охватывать абсолютно все бухгалтерские домены одинаково глубоко;
|
||||
- превращать assembler в rule engine уровня полной онтологии;
|
||||
- просто переименовывать entity groups в problem clusters без смены mechanics.
|
||||
|
||||
Особенно важно:
|
||||
|
||||
## Нельзя считать этап выполненным, если
|
||||
- top retrieval unit всё ещё по сути entity-heavy;
|
||||
- answer всё ещё строится вокруг counterparty/doc counts;
|
||||
- problem cluster является только косметической группировкой;
|
||||
- mechanism summary не лучше старых risk labels.
|
||||
|
||||
---
|
||||
|
||||
# 17. Критерии приёмки
|
||||
|
||||
Этап 2 считается принятым только если выполнены все условия ниже.
|
||||
|
||||
## 17.1. Архитектурные критерии
|
||||
|
||||
- реализован отдельный `ProblemUnitAssembler`;
|
||||
- существует backend schema `problem_unit`;
|
||||
- normalized payload поддерживает `problem_units`;
|
||||
- session state умеет ссылаться на active/resolved problem units.
|
||||
|
||||
## 17.2. Retrieval criteria
|
||||
|
||||
- для key domains retrieval output может быть assembled в problem units;
|
||||
- duplicate entity evidence collapse работает;
|
||||
- ranking problem units работает отдельно от pure entity ranking.
|
||||
|
||||
## 17.3. User-facing criteria
|
||||
|
||||
- на вопрос “что именно сломано” top ответа — problem unit, а не просто entity group;
|
||||
- ответ показывает механизм дефекта;
|
||||
- ответ показывает затронутые документы/цепочки;
|
||||
- ответ показывает, почему это проблема, а не просто кто оказался в top.
|
||||
|
||||
## 17.4. Accounting-domain criteria
|
||||
|
||||
Минимум в ключевых доменах должны быть рабочие problem units:
|
||||
- bank/settlement chain;
|
||||
- supplier/customer unresolved settlements;
|
||||
- deferred expense lifecycle anomalies.
|
||||
|
||||
## 17.5. Eval criteria
|
||||
|
||||
- внедрены problem-centric metrics;
|
||||
- benchmark suite показывает снижение entity-heavy leakage;
|
||||
- есть before/after evidence по canonical scenarios.
|
||||
|
||||
---
|
||||
|
||||
# 18. Что не считается результатом этапа
|
||||
|
||||
Этап **не считается выполненным**, если сделано только одно из следующего:
|
||||
|
||||
- richer wording;
|
||||
- grouping by counterparty with prettier labels;
|
||||
- расширение current evidence pack без assembler;
|
||||
- top-entity answer с новым названием “problem cluster”;
|
||||
- новые шаблоны текста без смены retrieval unit.
|
||||
|
||||
Этап считается выполненным только в том случае, если problem unit действительно стал самостоятельной сущностью в архитектуре.
|
||||
|
||||
---
|
||||
|
||||
# 19. Идеальный результат этапа
|
||||
|
||||
После Этапа 2 система всё ещё не является финальным бухгалтерским copilot. Но она уже должна перестать быть ассистентом, который в основном знает “кто в top”, и начать быть ассистентом, который видит “что конкретно сломано”.
|
||||
|
||||
## На выходе этапа должно появиться:
|
||||
- problem-centric retrieval;
|
||||
- problem-centric ranking;
|
||||
- problem-centric answer layer;
|
||||
- problem-aware session continuity;
|
||||
- measurable reduction of entity-heavy answers.
|
||||
|
||||
Это и есть первая настоящая архитектурная точка, после которой уже рационально переходить к:
|
||||
- lifecycle formalization;
|
||||
- ontology graph core;
|
||||
- investigation engine.
|
||||
|
||||
---
|
||||
|
||||
# 20. Короткий итог
|
||||
|
||||
**Этап 2 не про то, чтобы лучше искать сущности. Он про то, чтобы научить систему искать, собирать, ранжировать и объяснять бухгалтерские проблемы как отдельные объекты.**
|
||||
|
||||
Без этого перехода дальнейшая формализация lifecycle и ontology graph будет подниматься наверх в виде всё тех же top-entities, а не problem reasoning.
|
||||
|
||||
Именно поэтому Этап 2 является критическим мостом между Foundation Hardening и взрослой бухгалтерской reasoning-архитектурой.
|
||||
+1043
File diff suppressed because it is too large
Load Diff
+912
@@ -0,0 +1,912 @@
|
||||
# ТЗ Этап 4
|
||||
## Accounting Ontology Graph Core для Assistant Mode
|
||||
|
||||
## 0. Смысл этапа
|
||||
|
||||
Этот этап не является попыткой «нарисовать онтологию бухгалтерии» как красивую абстракцию.
|
||||
Его задача — ввести **рабочее графовое ядро бухгалтерской предметной области**, которое станет общим причинно-следственным слоем для:
|
||||
|
||||
- retrieval;
|
||||
- lifecycle resolution;
|
||||
- problem unit assembly;
|
||||
- cross-branch analysis;
|
||||
- investigation mode следующего этапа;
|
||||
- future live verification bridge.
|
||||
|
||||
На предыдущих этапах система уже должна получить:
|
||||
|
||||
- усиленный текущий контур Assistant Mode;
|
||||
- `investigation_state` baseline;
|
||||
- mechanism-aware evidence pack;
|
||||
- accountant-facing eval layer;
|
||||
- problem-centric retrieval unit;
|
||||
- lifecycle formalization по ключевым доменам.
|
||||
|
||||
Но даже после этого система всё ещё рискует мыслить слишком локально:
|
||||
через набор сущностей, признаков, стадий и эвристических связок.
|
||||
|
||||
Чтобы перейти к следующему уровню reasoning, системе нужен **единый causal representation layer**, в котором:
|
||||
|
||||
- документ существует не сам по себе;
|
||||
- проводка существует не сама по себе;
|
||||
- контрагент не является главным контейнером смысла;
|
||||
- lifecycle не живёт отдельно от связей;
|
||||
- проблема существует как узел или подграф, а не как случайная выдача рядом лежащих сущностей.
|
||||
|
||||
Именно это и является предметом Этапа 4.
|
||||
|
||||
---
|
||||
|
||||
## 1. От чего идём: целевая способность системы
|
||||
|
||||
Если смотреть от конечной цели назад, то после Этапа 4 бухгалтерский ассистент должен приобрести следующую новую способность:
|
||||
|
||||
**работать не только с сущностями, problem units и lifecycle defects, а с типизированным графом бухгалтерской реальности, по которому можно проходить причинные маршруты, находить отсутствующие/конфликтующие связи и поднимать соседние ветки как архитектурно нормальную операцию.**
|
||||
|
||||
Это означает, что система должна уметь:
|
||||
|
||||
1. представлять бухгалтерские объекты как типизированные графовые узлы;
|
||||
2. представлять связи между ними как типизированные рёбра, а не как общую “связанность”;
|
||||
3. поддерживать причинные маршруты между документами, проводками, расчётами, налоговыми следствиями, lifecycle-переходами и влиянием на период;
|
||||
4. использовать этот граф в runtime, а не только в документации;
|
||||
5. улучшать retrieval, lifecycle reasoning и problem assembly именно за счёт graph layer.
|
||||
|
||||
---
|
||||
|
||||
## 2. Что не устраивает в текущем состоянии
|
||||
|
||||
По итогам предыдущих этапов у системы уже есть:
|
||||
|
||||
- нормализованные бухгалтерские сущности;
|
||||
- semantic retrieval profile;
|
||||
- problem-centric retrieval;
|
||||
- lifecycle модели;
|
||||
- evidence packs;
|
||||
- answer policy;
|
||||
- базовый investigation state.
|
||||
|
||||
Но даже в таком состоянии у неё остаются архитектурные ограничения:
|
||||
|
||||
### 2.1. Связи между сущностями ещё слишком локальны
|
||||
Даже если retrieval находит правильную проблему, соседние сущности часто поднимаются:
|
||||
|
||||
- по фильтрам;
|
||||
- по локальным relation patterns;
|
||||
- по heuristics;
|
||||
- по эвристическим rule bundles.
|
||||
|
||||
Это означает, что cross-domain traversal всё ещё слишком зависит от частных сценариев.
|
||||
|
||||
### 2.2. Нет единого пространства причинности
|
||||
Сейчас причина и следствие часто живут в разных местах:
|
||||
|
||||
- проблема определяется в retrieval;
|
||||
- lifecycle — в отдельном resolution слое;
|
||||
- соседняя ветка подтягивается по дополнительным правилам;
|
||||
- answer layer уже потом пытается из этого собрать narrative.
|
||||
|
||||
Без общего graph core такие reasoning-цепочки остаются хрупкими.
|
||||
|
||||
### 2.3. Missing/conflicting links ещё не являются first-class runtime objects
|
||||
Пока разрыв связи зачастую определяется как:
|
||||
|
||||
- эвристика;
|
||||
- дефект lifecycle;
|
||||
- conflict label;
|
||||
- absence of expected evidence.
|
||||
|
||||
Но система ещё не мыслит это как **типизированный дефект графа**:
|
||||
|
||||
- missing edge;
|
||||
- invalid edge;
|
||||
- conflicting edge;
|
||||
- weakly supported edge;
|
||||
- obsolete edge.
|
||||
|
||||
### 2.4. Investigation traversal ещё не имеет архитектурной базы
|
||||
Следующий этап должен будет ввести полноценный investigation engine. Но без graph core этот движок будет вынужден жить на ad hoc secondary retrieval, а не на нормальном traversal.
|
||||
|
||||
---
|
||||
|
||||
## 3. Главная архитектурная цель этапа
|
||||
|
||||
К концу Этапа 4 система должна перейти из состояния:
|
||||
|
||||
**problem-centric assistant with lifecycle-aware reasoning**
|
||||
|
||||
в состояние:
|
||||
|
||||
**graph-backed accounting assistant, в котором retrieval, lifecycle и problem assembly опираются на единое causal representation бухгалтерских сущностей и связей.**
|
||||
|
||||
---
|
||||
|
||||
## 4. Что сохраняем, а что меняем
|
||||
|
||||
### 4.1. Что сохраняем
|
||||
На этом этапе не ломаем уже построенные слои:
|
||||
|
||||
- `investigation_state` baseline;
|
||||
- `semantic_retrieval_profile`;
|
||||
- broad-query guard;
|
||||
- mechanism-aware evidence pack;
|
||||
- problem unit layer;
|
||||
- lifecycle registry и lifecycle resolver;
|
||||
- accountant-facing eval harness;
|
||||
- answer contract предыдущих этапов.
|
||||
|
||||
Graph core должен встроиться **под** эти слои и усилить их, а не заменить весь контур с нуля.
|
||||
|
||||
### 4.2. Что меняем принципиально
|
||||
На этом этапе меняем:
|
||||
|
||||
1. модель внутренних сущностей;
|
||||
2. модель связей;
|
||||
3. runtime-слой, который формирует causal representation;
|
||||
4. retrieval execution для graph-eligible queries;
|
||||
5. problem assembly, чтобы он использовал graph connectivity;
|
||||
6. lifecycle reasoning, чтобы он использовал graph-backed transitions;
|
||||
7. eval layer, чтобы она умела доказывать ценность graph layer.
|
||||
|
||||
### 4.3. От чего отказываемся
|
||||
На этом этапе нужно осознанно отказаться от следующих паттернов:
|
||||
|
||||
- retrieval “по соседству” без явной модели связей;
|
||||
- implicit relation semantics, зашитой в случайные правила;
|
||||
- ad hoc cross-branch checks без graph traversal;
|
||||
- формальной онтологии, которая не участвует в runtime;
|
||||
- мысли о том, что graph = просто JSON-структура для объяснения.
|
||||
|
||||
---
|
||||
|
||||
## 5. Главные сущности этапа
|
||||
|
||||
Ниже — ключевые сущности Этапа 4. Не в виде пустого списка, а с объяснением, зачем они нужны, как связаны с бухгалтерией и как должны работать в архитектуре.
|
||||
|
||||
---
|
||||
|
||||
## 5.1. Сущность №1 — `AccountingGraphNode`
|
||||
|
||||
### Почему нужна
|
||||
Система не может делать устойчивый traversal, пока объекты учёта существуют только как плоские normalized items.
|
||||
|
||||
Нужен единый типизированный контейнер для сущности в graph layer.
|
||||
|
||||
### Что это такое
|
||||
`AccountingGraphNode` — это базовая графовая сущность, представляющая конкретный бухгалтерский объект или агрегированную аналитическую единицу.
|
||||
|
||||
### Базовые поля
|
||||
- `node_id`
|
||||
- `node_type`
|
||||
- `source_type`
|
||||
- `source_id`
|
||||
- `domain`
|
||||
- `subdomain`
|
||||
- `attributes`
|
||||
- `period_scope`
|
||||
- `organization_scope`
|
||||
- `confidence`
|
||||
- `provenance`
|
||||
- `temporal_markers`
|
||||
- `lifecycle_binding`
|
||||
- `graph_status`
|
||||
|
||||
### Какие типы узлов должны быть поддержаны
|
||||
|
||||
#### Документные узлы
|
||||
- `BankStatementDocument`
|
||||
- `PaymentOrderDocument`
|
||||
- `ReceiptDocument`
|
||||
- `SalesDocument`
|
||||
- `InvoiceDocument`
|
||||
- `AdjustmentDocument`
|
||||
- `DeferredExpenseDocument`
|
||||
- `AssetAcceptanceDocument`
|
||||
- `AssetCommissioningDocument`
|
||||
- `DepreciationDocument`
|
||||
- `PeriodCloseOperation`
|
||||
- `ManualOperationDocument`
|
||||
|
||||
#### Учётные узлы
|
||||
- `Posting`
|
||||
- `RegisterMovement`
|
||||
- `Account`
|
||||
- `Subaccount`
|
||||
- `TaxEntry`
|
||||
- `VATPosition`
|
||||
- `DeferredExpensePosition`
|
||||
- `AssetCard`
|
||||
- `SettlementPosition`
|
||||
- `ReceivablePosition`
|
||||
- `PayablePosition`
|
||||
|
||||
#### Бизнес-узлы
|
||||
- `Counterparty`
|
||||
- `Contract`
|
||||
- `Organization`
|
||||
- `Department`
|
||||
- `Project`
|
||||
- `Warehouse`
|
||||
- `Nomenclature`
|
||||
- `AssetObject`
|
||||
|
||||
#### Аналитические узлы
|
||||
- `ProblemUnit`
|
||||
- `LifecycleStateNode`
|
||||
- `PeriodRiskNode`
|
||||
- `InvestigationFocusNode`
|
||||
|
||||
### Зачем это нужно бухгалтерски
|
||||
В 1С одна и та же проблема часто размазана по разным слоям:
|
||||
|
||||
- документ;
|
||||
- проводка;
|
||||
- регистр;
|
||||
- расчётная позиция;
|
||||
- контрагент;
|
||||
- договор;
|
||||
- период;
|
||||
- налоговое следствие.
|
||||
|
||||
Пока эти объекты не приведены к единому узловому представлению, система не может делать нормальный causal traversal.
|
||||
|
||||
---
|
||||
|
||||
## 5.2. Сущность №2 — `AccountingGraphEdge`
|
||||
|
||||
### Почему нужна
|
||||
Graph без typed edges — это не рабочая причинная модель, а просто связанный список объектов.
|
||||
|
||||
### Что это такое
|
||||
`AccountingGraphEdge` — типизированная связь между двумя graph nodes с чётким смыслом, confidence и provenance.
|
||||
|
||||
### Базовые поля
|
||||
- `edge_id`
|
||||
- `edge_type`
|
||||
- `from_node_id`
|
||||
- `to_node_id`
|
||||
- `direction`
|
||||
- `attributes`
|
||||
- `confidence`
|
||||
- `provenance`
|
||||
- `is_expected`
|
||||
- `is_observed`
|
||||
- `is_conflicting`
|
||||
- `is_missing_marker`
|
||||
- `temporal_markers`
|
||||
|
||||
### Базовые классы рёбер
|
||||
|
||||
#### Документно-учётные связи
|
||||
- `creates_posting`
|
||||
- `affects_register`
|
||||
- `references_document`
|
||||
- `based_on_document`
|
||||
- `generated_from`
|
||||
- `belongs_to_period`
|
||||
|
||||
#### Расчётные связи
|
||||
- `settles`
|
||||
- `partially_settles`
|
||||
- `linked_to_payment`
|
||||
- `linked_to_receivable`
|
||||
- `linked_to_payable`
|
||||
- `linked_to_contract`
|
||||
|
||||
#### Lifecycle-связи
|
||||
- `advances_to_state`
|
||||
- `expected_next_state`
|
||||
- `conflicts_with_state`
|
||||
- `closes`
|
||||
- `writes_off`
|
||||
- `commissions`
|
||||
- `depreciates`
|
||||
|
||||
#### Cross-domain связи
|
||||
- `affects_vat`
|
||||
- `affects_period_close`
|
||||
- `depends_on_branch`
|
||||
- `conflicts_with_branch`
|
||||
- `requires_neighbor_check`
|
||||
|
||||
#### Проблемно-аналитические связи
|
||||
- `evidence_for_problem`
|
||||
- `part_of_problem_cluster`
|
||||
- `supports_hypothesis`
|
||||
- `contradicts_hypothesis`
|
||||
|
||||
### Зачем это нужно бухгалтерски
|
||||
Для бухгалтера важно не только наличие объектов, а смысл связи между ними:
|
||||
|
||||
- документ создал проводку;
|
||||
- платёж должен закрывать обязательство;
|
||||
- РБП должно перейти в списание;
|
||||
- ввод ОС должен вести к амортизации;
|
||||
- счёт-фактура должна вести к налоговому следствию;
|
||||
- один контур влияет на закрытие другого.
|
||||
|
||||
Именно эти причинные связи и должны стать first-class runtime objects.
|
||||
|
||||
---
|
||||
|
||||
## 5.3. Сущность №3 — `GraphSchemaRegistry`
|
||||
|
||||
### Почему нужна
|
||||
Если node/edge типы живут в коде фрагментами, система быстро превратится в набор несогласованных graph rules.
|
||||
|
||||
### Что это такое
|
||||
Единый реестр graph schema, где определяются:
|
||||
|
||||
- допустимые node types;
|
||||
- допустимые edge types;
|
||||
- обязательные атрибуты;
|
||||
- domain bindings;
|
||||
- lifecycle bindings;
|
||||
- expected graph patterns;
|
||||
- graph validation rules.
|
||||
|
||||
### Что он должен содержать
|
||||
Для каждого node type:
|
||||
- required attributes;
|
||||
- optional attributes;
|
||||
- provenance sources;
|
||||
- domain membership;
|
||||
- period semantics;
|
||||
- lifecycle compatibility.
|
||||
|
||||
Для каждого edge type:
|
||||
- допустимые типы from/to;
|
||||
- допустимость направлений;
|
||||
- допустимость по домену;
|
||||
- допустимость по lifecycle;
|
||||
- confidence policy;
|
||||
- missing-edge semantics.
|
||||
|
||||
### Зачем это нужно
|
||||
Чтобы graph оставался управляемой архитектурной системой, а не хаотичным набором типов и связей.
|
||||
|
||||
---
|
||||
|
||||
## 5.4. Сущность №4 — `GraphBuilder`
|
||||
|
||||
### Почему нужна
|
||||
Graph schema без runtime-построения — это формальная документация, а не архитектурный слой.
|
||||
|
||||
### Что это такое
|
||||
`GraphBuilder` — runtime-компонент, который из normalized accounting entities, lifecycle outputs и relation evidence строит graph core.
|
||||
|
||||
### Что он принимает на вход
|
||||
- normalized documents;
|
||||
- postings;
|
||||
- register movements;
|
||||
- domain-specific entities;
|
||||
- lifecycle resolution outputs;
|
||||
- problem assembly signals;
|
||||
- source provenance metadata.
|
||||
|
||||
### Что он делает
|
||||
1. создаёт graph nodes;
|
||||
2. создаёт typed edges;
|
||||
3. маркирует expected vs observed relations;
|
||||
4. создаёт missing/conflicting edge markers;
|
||||
5. формирует graph layer для retrieval/problem assembly/investigation;
|
||||
6. присваивает confidence и provenance.
|
||||
|
||||
### Что важно
|
||||
GraphBuilder не должен быть чисто offline-процедурой “раз в день”.
|
||||
На этапе 4 допускается snapshot-based build, но он должен быть встроен в рабочий assistant runtime как доступный слой.
|
||||
|
||||
---
|
||||
|
||||
## 5.5. Сущность №5 — `GraphTraversalPolicy`
|
||||
|
||||
### Почему нужна
|
||||
Наличие graph само по себе не означает, что система умеет им пользоваться.
|
||||
|
||||
### Что это такое
|
||||
Политика traversal по graph layer для разных классов задач.
|
||||
|
||||
### Какие типы traversal должны быть поддержаны
|
||||
|
||||
#### Upstream traversal
|
||||
От проблемы назад к причинам.
|
||||
|
||||
#### Downstream traversal
|
||||
От объекта вперёд к последствиям.
|
||||
|
||||
#### Cross-domain traversal
|
||||
Из одного домена в другой:
|
||||
- банк → расчёты;
|
||||
- документ → НДС;
|
||||
- объект → период;
|
||||
- документ → lifecycle state;
|
||||
- issue → affected branches.
|
||||
|
||||
#### Period-impact traversal
|
||||
Поиск того, как локальная проблема влияет на закрытие периода.
|
||||
|
||||
#### Neighbor-branch traversal
|
||||
Переход в соседнюю ветку учёта для усиления доказательной базы.
|
||||
|
||||
### Что важно
|
||||
Traversal не должен быть свободным «гулянием по графу». Нужны жёсткие policies:
|
||||
|
||||
- allowed traversal depth;
|
||||
- allowed edge families;
|
||||
- purpose-specific traversal;
|
||||
- stop criteria;
|
||||
- evidence sufficiency rules.
|
||||
|
||||
---
|
||||
|
||||
## 5.6. Сущность №6 — `GraphBackedProblemAssembly`
|
||||
|
||||
### Почему нужна
|
||||
Problem unit layer второго этапа не должен оставаться чисто эвристическим, если мы уже строим graph core.
|
||||
|
||||
### Что это такое
|
||||
Слой problem assembly, который использует graph connectivity и graph defects как основу для формирования problem units.
|
||||
|
||||
### Что меняется по сравнению с этапом 2
|
||||
Раньше problem unit собирался в основном из:
|
||||
|
||||
- retrieval entities;
|
||||
- relation patterns;
|
||||
- lifecycle defects;
|
||||
- evidence pack fields.
|
||||
|
||||
Теперь problem unit должен собираться также из:
|
||||
|
||||
- graph-connected nodes;
|
||||
- missing edges;
|
||||
- conflicting edges;
|
||||
- weakly supported paths;
|
||||
- graph neighborhoods;
|
||||
- branch crossings.
|
||||
|
||||
### Что это даёт
|
||||
- более чёткое отделение одной проблемы от другой;
|
||||
- более сильное объяснение broken chain;
|
||||
- better cross-branch inconsistency detection;
|
||||
- better duplicate collapse;
|
||||
- better evidence completeness.
|
||||
|
||||
---
|
||||
|
||||
## 5.7. Сущность №7 — `GraphBackedLifecycleBinding`
|
||||
|
||||
### Почему нужна
|
||||
Lifecycle formalization из этапа 3 должна опираться на graph, а не существовать как отдельная state machine поверх плоских данных.
|
||||
|
||||
### Что это такое
|
||||
Связь lifecycle registry/runtime с graph core.
|
||||
|
||||
### Что должно происходить
|
||||
- lifecycle state node должен быть связан с domain object;
|
||||
- expected transitions должны отображаться через expected edges;
|
||||
- observed transitions должны отображаться через observed edges;
|
||||
- missing transition = missing expected edge;
|
||||
- invalid transition = conflicting edge pattern.
|
||||
|
||||
### Что это даст
|
||||
Lifecycle становится не только временной логикой, но и логикой структурных переходов в графе.
|
||||
|
||||
---
|
||||
|
||||
## 5.8. Сущность №8 — `GraphProvenanceLayer`
|
||||
|
||||
### Почему нужна
|
||||
В бухгалтерии нельзя строить reasoning по графу без ясного понимания, откуда взялась каждая связь.
|
||||
|
||||
### Что это такое
|
||||
Слой provenance для nodes и edges.
|
||||
|
||||
### Что должен хранить
|
||||
- источник (snapshot / live / inferred / derived);
|
||||
- origin entity ids;
|
||||
- confidence source;
|
||||
- timestamp / period;
|
||||
- inference path;
|
||||
- lifecycle dependence;
|
||||
- conflict flags.
|
||||
|
||||
### Зачем это нужно
|
||||
Иначе graph будет выглядеть умно, но не будет доказуемым и пригодным для бухгалтерского ассистента.
|
||||
|
||||
---
|
||||
|
||||
## 5.9. Сущность №9 — `GraphValidationLayer`
|
||||
|
||||
### Почему нужна
|
||||
Самый большой риск этапа — построить formal graph, который runtime почти не улучшает.
|
||||
|
||||
### Что это такое
|
||||
Слой валидации graph core по двум осям:
|
||||
|
||||
1. structural validity;
|
||||
2. product value validity.
|
||||
|
||||
### Structural validity
|
||||
- корректность node/edge типов;
|
||||
- корректность доменных связей;
|
||||
- корректность confidence/provenance;
|
||||
- отсутствие невалидных типов связей;
|
||||
- отсутствие циклов там, где они запрещены.
|
||||
|
||||
### Product value validity
|
||||
- улучшил ли graph causal retrieval;
|
||||
- улучшил ли graph cross-branch reasoning;
|
||||
- улучшил ли graph problem unit precision;
|
||||
- улучшил ли graph lifecycle explanation;
|
||||
- улучшил ли graph answer usefulness.
|
||||
|
||||
---
|
||||
|
||||
## 6. Домены этапа 4
|
||||
|
||||
Graph core должен строиться не для всей бухгалтерии сразу, а для ключевых доменов, уже подготовленных предыдущими этапами.
|
||||
|
||||
### 6.1. Банк / расчёты / 51–60
|
||||
Узлы:
|
||||
- выписка;
|
||||
- платёжное поручение;
|
||||
- проводка;
|
||||
- settlement position;
|
||||
- payable position;
|
||||
- counterparty;
|
||||
- contract.
|
||||
|
||||
Связи:
|
||||
- payment ↔ statement;
|
||||
- statement ↔ posting;
|
||||
- payment ↔ settlement;
|
||||
- settlement ↔ contract;
|
||||
- settlement ↔ payable closure.
|
||||
|
||||
### 6.2. Покупатели / 62
|
||||
Узлы:
|
||||
- реализация;
|
||||
- оплата;
|
||||
- receivable position;
|
||||
- contract;
|
||||
- tax entry.
|
||||
|
||||
Связи:
|
||||
- sales ↔ posting;
|
||||
- payment ↔ receivable;
|
||||
- receivable ↔ contract;
|
||||
- sales ↔ VAT effect.
|
||||
|
||||
### 6.3. РБП / 97
|
||||
Узлы:
|
||||
- deferred expense document;
|
||||
- deferred expense position;
|
||||
- writeoff movement;
|
||||
- period;
|
||||
- supporting basis.
|
||||
|
||||
Связи:
|
||||
- basis ↔ deferred expense;
|
||||
- deferred expense ↔ writeoff;
|
||||
- writeoff ↔ period;
|
||||
- deferred expense ↔ lifecycle state.
|
||||
|
||||
### 6.4. ОС / 08–01–02
|
||||
Узлы:
|
||||
- asset acceptance document;
|
||||
- asset commissioning document;
|
||||
- asset card;
|
||||
- depreciation movement;
|
||||
- asset object.
|
||||
|
||||
Связи:
|
||||
- acceptance ↔ asset card;
|
||||
- commissioning ↔ asset object;
|
||||
- asset object ↔ depreciation;
|
||||
- capitalized value ↔ commissioned asset.
|
||||
|
||||
### 6.5. НДС / 19–68
|
||||
Узлы:
|
||||
- invoice;
|
||||
- tax entry;
|
||||
- VAT position;
|
||||
- source document;
|
||||
- period.
|
||||
|
||||
Связи:
|
||||
- source document ↔ invoice;
|
||||
- invoice ↔ VAT position;
|
||||
- VAT position ↔ tax entry;
|
||||
- VAT position ↔ period.
|
||||
|
||||
### 6.6. Закрытие периода
|
||||
Узлы:
|
||||
- period close operation;
|
||||
- affected problem unit;
|
||||
- affected domain object;
|
||||
- period risk node.
|
||||
|
||||
Связи:
|
||||
- domain object ↔ period close;
|
||||
- problem unit ↔ period risk;
|
||||
- unresolved chain ↔ close blocker.
|
||||
|
||||
---
|
||||
|
||||
## 7. Что именно меняется по цепи выполнения
|
||||
|
||||
---
|
||||
|
||||
## 7.1. Вход данных
|
||||
|
||||
### Сейчас
|
||||
Система получает normalized accounting entities из snapshot/assistant data layer.
|
||||
|
||||
### Что меняем
|
||||
После normalized entity layer вводится graph construction layer.
|
||||
|
||||
### Новый фрагмент контура
|
||||
`Normalized entities → GraphBuilder → Graph core → retrieval / lifecycle / problem assembly / answer`
|
||||
|
||||
### Цель
|
||||
Сделать graph не параллельной документацией, а рабочим промежуточным слоем.
|
||||
|
||||
---
|
||||
|
||||
## 7.2. Retrieval planning
|
||||
|
||||
### Сейчас
|
||||
Retrieval planning строится на semantic profile и domain-specific filters.
|
||||
|
||||
### Что меняем
|
||||
Добавляем `graph_eligibility` и `graph_traversal_policy` в retrieval plan.
|
||||
|
||||
### Что должно появиться
|
||||
- для causal queries;
|
||||
- для cross-branch queries;
|
||||
- для period-impact queries;
|
||||
- для neighbor-check-worthy problem units.
|
||||
|
||||
Retrieval planner должен уметь решать:
|
||||
- нужен ли graph traversal;
|
||||
- какой traversal type нужен;
|
||||
- какая глубина допустима;
|
||||
- какие edge families допустимы.
|
||||
|
||||
---
|
||||
|
||||
## 7.3. Retrieval execution
|
||||
|
||||
### Сейчас
|
||||
Execution основан на semantic narrowing + problem-centric extraction.
|
||||
|
||||
### Что меняем
|
||||
В graph-eligible режимах retrieval должен использовать:
|
||||
- node lookup;
|
||||
- typed edge traversal;
|
||||
- missing/conflicting edge detection;
|
||||
- graph neighborhood assembly.
|
||||
|
||||
### Что важно
|
||||
Graph-backed retrieval не заменяет фильтры. Он расширяет их там, где нужен causal traversal.
|
||||
|
||||
---
|
||||
|
||||
## 7.4. Lifecycle reasoning
|
||||
|
||||
### Сейчас
|
||||
Lifecycle работает по domain state models и evidence.
|
||||
|
||||
### Что меняем
|
||||
Lifecycle resolver должен использовать graph edges для:
|
||||
- проверки ожидаемых переходов;
|
||||
- проверки observed transitions;
|
||||
- маркировки missing/invalid transitions;
|
||||
- cross-branch consistency.
|
||||
|
||||
---
|
||||
|
||||
## 7.5. Problem assembly
|
||||
|
||||
### Сейчас
|
||||
Problem units собираются по evidence и relation patterns.
|
||||
|
||||
### Что меняем
|
||||
Assembler должен использовать graph connectivity как первичный или равноправный признак assembly.
|
||||
|
||||
### Что это значит practically
|
||||
Если есть broken chain, то assembler должен видеть:
|
||||
- какие узлы входят в цепочку;
|
||||
- какая связь отсутствует;
|
||||
- какая связь конфликтует;
|
||||
- какие соседние узлы усиливают проблему.
|
||||
|
||||
---
|
||||
|
||||
## 7.6. Answer synthesis
|
||||
|
||||
### Сейчас
|
||||
Answer layer строит narrative по problem units и lifecycle-enriched evidence.
|
||||
|
||||
### Что меняем
|
||||
Composer должен уметь включать graph-backed explanation fragments:
|
||||
- между какими сущностями найден разрыв;
|
||||
- какая ожидаемая связь отсутствует;
|
||||
- какая ветка противоречит другой;
|
||||
- как проблема проходит по causal path.
|
||||
|
||||
### Цель
|
||||
Сделать explanation не просто case-specific, а структурно причинным.
|
||||
|
||||
---
|
||||
|
||||
## 8. Как не уткнуться в главный риск этапа
|
||||
|
||||
Пользователь специально просил отдельно раскрыть, как не скатиться в формальный этап. Это критично.
|
||||
|
||||
### Главный риск
|
||||
Сделать онтологию как формальную схему, которую можно красиво показать, но которая почти не влияет на runtime.
|
||||
|
||||
### Как это обычно выглядит
|
||||
- список узлов описан;
|
||||
- список рёбер описан;
|
||||
- graph builder формально есть;
|
||||
- maybe есть storage;
|
||||
- но retrieval почти не поменялся;
|
||||
- problem assembly почти не поменялся;
|
||||
- answer quality почти не выросло.
|
||||
|
||||
### Как этого избежать
|
||||
|
||||
#### 1. Graph должен иметь runtime-critical use cases
|
||||
С первого релиза этапа graph должен использоваться хотя бы в:
|
||||
- broken chain detection;
|
||||
- cross-branch inconsistency checks;
|
||||
- period-impact traversal;
|
||||
- problem unit assembly.
|
||||
|
||||
#### 2. Нужно сразу доказать value, а не только correctness
|
||||
Нужны before/after сценарии, где graph реально улучшает:
|
||||
- causal answers;
|
||||
- neighboring branch discovery;
|
||||
- distinction between one problem and another;
|
||||
- explanation clarity.
|
||||
|
||||
#### 3. Нельзя строить graph “вообще”
|
||||
Graph schema должен строиться под уже существующие бухгалтерские домены и problem classes.
|
||||
|
||||
#### 4. Нельзя делать слабые edge types
|
||||
“related_to” не подходит как основной тип связи.
|
||||
Нужны typed edges с бухгалтерским смыслом.
|
||||
|
||||
#### 5. Нельзя оставлять provenance опциональным
|
||||
Без provenance graph быстро превратится в недоказуемую inference-конструкцию.
|
||||
|
||||
#### 6. Нельзя считать этап успешным, если graph не вошёл в retrieval/problem assembly/lifecycle
|
||||
Документация и storage сами по себе не считаются результатом.
|
||||
|
||||
---
|
||||
|
||||
## 9. Что должно быть переписано, а что только усилено
|
||||
|
||||
### Полностью переписывать на этапе 4 не надо
|
||||
- весь assistant loop;
|
||||
- normalizer;
|
||||
- базовый routing engine;
|
||||
- answer contract с нуля;
|
||||
- lifecycle registry с нуля;
|
||||
- problem unit layer с нуля.
|
||||
|
||||
### Существенно переделываем
|
||||
- internal representation layer;
|
||||
- relation semantics;
|
||||
- graph-eligible retrieval execution;
|
||||
- graph-backed problem assembly;
|
||||
- lifecycle-to-graph binding;
|
||||
- eval harness для graph value.
|
||||
|
||||
### Частично усиливаем
|
||||
- evidence pack;
|
||||
- traversal hints в retrieval profile;
|
||||
- answer composer;
|
||||
- investigation state integration.
|
||||
|
||||
### Оставляем на следующий этап
|
||||
- полноценный investigation orchestrator;
|
||||
- full branch automation;
|
||||
- live verification bridge как core path;
|
||||
- full enterprise graph beyond accounting core.
|
||||
|
||||
---
|
||||
|
||||
## 10. Архитектурные артефакты этапа
|
||||
|
||||
К концу этапа должны появиться следующие артефакты:
|
||||
|
||||
1. `AccountingGraphNode` schema
|
||||
2. `AccountingGraphEdge` schema
|
||||
3. `GraphSchemaRegistry`
|
||||
4. `GraphBuilder` runtime spec
|
||||
5. `GraphTraversalPolicy` spec
|
||||
6. `GraphBackedProblemAssembly` spec
|
||||
7. `GraphBackedLifecycleBinding` spec
|
||||
8. `GraphProvenanceLayer` spec
|
||||
9. `GraphValidationLayer` spec
|
||||
10. domain graph definitions for selected accounting domains
|
||||
11. graph-backed benchmark suite
|
||||
12. graph value proof scenarios
|
||||
|
||||
---
|
||||
|
||||
## 11. Критерии приёмки этапа
|
||||
|
||||
Этап считается выполненным только при одновременном выполнении следующих условий.
|
||||
|
||||
### 11.1. По graph core
|
||||
- есть рабочая node/edge schema;
|
||||
- graph builder формирует runtime-usable graph;
|
||||
- nodes и edges имеют provenance и confidence;
|
||||
- graph покрывает agreed accounting domains.
|
||||
|
||||
### 11.2. По retrieval
|
||||
- graph-eligible queries реально используют graph traversal;
|
||||
- broken chain detection улучшается за счёт graph;
|
||||
- cross-branch checks перестают быть чисто эвристическими;
|
||||
- period-impact traversal использует graph relationships.
|
||||
|
||||
### 11.3. По problem assembly
|
||||
- problem units собираются по graph connectivity, а не только по filter proximity;
|
||||
- duplicate collapse quality улучшается;
|
||||
- distinction between separate vs shared problem clusters становится лучше.
|
||||
|
||||
### 11.4. По lifecycle
|
||||
- lifecycle resolver использует graph-backed transitions;
|
||||
- missing/invalid transitions определяются через graph semantics;
|
||||
- lifecycle explanation становится структурно точнее.
|
||||
|
||||
### 11.5. По answer usefulness
|
||||
- ответы лучше объясняют, между чем и чем разрыв;
|
||||
- ответы лучше показывают путь проблемы по связанным сущностям;
|
||||
- ответы лучше поднимают соседние контуры и влияние на период.
|
||||
|
||||
### 11.6. По продуктовой ценности
|
||||
- есть канонические сценарии before/after;
|
||||
- доказано, что graph layer улучшает не только внутреннюю красоту, но и user-facing полезность.
|
||||
|
||||
---
|
||||
|
||||
## 12. Что не считается результатом этапа
|
||||
|
||||
Этап не считается выполненным, если произошло только что-то из этого:
|
||||
|
||||
- появилась formal ontology documentation;
|
||||
- появилась graph storage representation;
|
||||
- появились node/edge definitions, но runtime их почти не использует;
|
||||
- graph builder есть, но retrieval/problem assembly почти не изменились;
|
||||
- answers не стали заметно более причинными;
|
||||
- graph оказался просто ещё одним способом сериализации старых entities.
|
||||
|
||||
---
|
||||
|
||||
## 13. Практический идеальный результат этапа
|
||||
|
||||
После завершения Этапа 4 система ещё не должна быть финальным бухгалтерским copilot.
|
||||
Но она уже должна перестать быть:
|
||||
|
||||
- набором локальных retrieval и lifecycle правил;
|
||||
- системой, которая тянет соседние сущности в основном по эвристике;
|
||||
- assistant’ом, который знает problem units, но не имеет общего пространства связей.
|
||||
|
||||
И должна стать:
|
||||
|
||||
- graph-backed accounting assistant;
|
||||
- системой, в которой causal traversal является нормальной архитектурной операцией;
|
||||
- системой, где retrieval, lifecycle и problem assembly живут в одном пространстве типизированных связей;
|
||||
- базой для Investigation Engine следующего этапа.
|
||||
|
||||
---
|
||||
|
||||
## 14. Короткое управленческое резюме этапа
|
||||
|
||||
**Этап 4 не строит “красивую онтологию”.
|
||||
Он строит рабочее графовое ядро бухгалтерских сущностей и связей, чтобы retrieval, lifecycle reasoning и problem assembly опирались на единое causal representation.
|
||||
Только после этого становится рационально строить полноценный investigation engine как следующий взрослый архитектурный слой.**
|
||||
+1058
File diff suppressed because it is too large
Load Diff
+985
@@ -0,0 +1,985 @@
|
||||
# ТЗ Этап 6 — Live Verification + Product Modes для Assistant Mode
|
||||
|
||||
## 0. Назначение этапа
|
||||
|
||||
Этап 6 завершает переход от архитектурного прототипа бухгалтерского ассистента к зрелой продуктовой системе.
|
||||
Если предыдущие этапы строили внутреннюю способность системы понимать данные, поднимать problem units, формализовать lifecycle, работать через graph core и вести bounded investigation, то этот этап отвечает уже за другое:
|
||||
|
||||
- как ассистент работает в разных продуктовых режимах;
|
||||
- когда он отвечает быстро, а когда запускает расследование;
|
||||
- когда он может опираться на snapshot и inference, а когда обязан или должен рекомендовать live verification;
|
||||
- как выполнять широкий audit / batch analysis, не превращая его в “очень длинный чат-ответ”;
|
||||
- как формально различать уровни доверия к результату;
|
||||
- как превратить reasoning-архитектуру в рабочий product contract.
|
||||
|
||||
Этап 6 не должен переписывать reasoning core.
|
||||
Он должен сделать уже построенные слои:
|
||||
|
||||
- Foundation Hardening;
|
||||
- Problem-centric Retrieval;
|
||||
- Lifecycle Formalization;
|
||||
- Accounting Ontology Graph Core;
|
||||
- Investigation Engine;
|
||||
|
||||
— **общим основанием для трёх разных режимов продукта**.
|
||||
|
||||
---
|
||||
|
||||
## 1. Смысл этапа
|
||||
|
||||
### 1.1. От какой проблемы идём
|
||||
|
||||
До Этапа 6 ассистент уже может быть умным и архитектурно глубоким, но всё ещё может оставаться системой, у которой:
|
||||
|
||||
- один основной conversational loop;
|
||||
- один базовый execution path;
|
||||
- разная глубина ответа, но не разные режимы работы;
|
||||
- нет формальной границы между direct answer, investigation и wide analysis;
|
||||
- нет штатного слоя live verification;
|
||||
- нет жёсткой модели доверия к результату.
|
||||
|
||||
Это означает, что даже сильный reasoning-движок остаётся продуктово не до конца оформленным.
|
||||
|
||||
### 1.2. Что должен решить этап
|
||||
|
||||
Этап 6 должен решить три системные задачи:
|
||||
|
||||
1. **развести execution modes**;
|
||||
2. **ввести live verification как штатный runtime capability**;
|
||||
3. **ввести trust / provenance model**, чтобы пользователь и система одинаково понимали, какой именно тип результата выдан.
|
||||
|
||||
---
|
||||
|
||||
## 2. Целевая способность системы после этапа
|
||||
|
||||
После завершения Этапа 6 ассистент должен поддерживать три полноценных режима:
|
||||
|
||||
### 2.1. Direct Answer Mode
|
||||
|
||||
Для локальных вопросов:
|
||||
|
||||
- что не бьётся;
|
||||
- где разрыв;
|
||||
- какие документы участвуют;
|
||||
- почему объект завис;
|
||||
- какие проблемы по конкретному счёту/контрагенту/объекту.
|
||||
|
||||
Система должна:
|
||||
|
||||
- отвечать быстро;
|
||||
- не запускать сложное расследование без веской причины;
|
||||
- уметь ограничить глубину;
|
||||
- маркировать уровень уверенности;
|
||||
- уметь рекомендовать escalation в investigation или live verification.
|
||||
|
||||
### 2.2. Investigation Mode
|
||||
|
||||
Для многосоставных и гипотезных вопросов:
|
||||
|
||||
- проверь несколько причин;
|
||||
- сравни ветки;
|
||||
- отдели локальный дефект от системного;
|
||||
- покажи, что подтверждено;
|
||||
- проверь влияние на соседний контур;
|
||||
- разберись, почему всё выглядит неконсистентно.
|
||||
|
||||
Система должна:
|
||||
|
||||
- открыть investigation case;
|
||||
- вести ветки и гипотезы;
|
||||
- выполнять bounded multi-step flow;
|
||||
- различать доказанное и вероятное;
|
||||
- при необходимости запускать live verification;
|
||||
- завершать расследование по формальным stop criteria.
|
||||
|
||||
### 2.3. Audit / Batch Analysis Mode
|
||||
|
||||
Для широких запросов:
|
||||
|
||||
- проведи полный анализ периода;
|
||||
- найди системные дефекты;
|
||||
- покажи recurring patterns;
|
||||
- собери зоны риска;
|
||||
- сгруппируй problem clusters;
|
||||
- дай приоритеты для дальнейшей проверки.
|
||||
|
||||
Система должна:
|
||||
|
||||
- запускать отдельный batch pipeline;
|
||||
- обрабатывать расширенный scope;
|
||||
- собирать много problem units;
|
||||
- агрегировать результаты;
|
||||
- выдавать отчётный итог, а не обычный чат-ответ.
|
||||
|
||||
---
|
||||
|
||||
## 3. Что сохраняем, а что меняем
|
||||
|
||||
### 3.1. Что сохраняем
|
||||
|
||||
Этап 6 **не переписывает** уже построенные reasoning-слои. Он опирается на них как на substrate.
|
||||
|
||||
Сохраняются:
|
||||
|
||||
- semantic_retrieval_profile;
|
||||
- mechanism-aware evidence pack;
|
||||
- problem unit model;
|
||||
- lifecycle knowledge layer;
|
||||
- graph core;
|
||||
- investigation case / hypothesis / branch / step model;
|
||||
- bounded orchestration policy;
|
||||
- answer contract;
|
||||
- accountant-facing eval framework.
|
||||
|
||||
### 3.2. Что меняем принципиально
|
||||
|
||||
На Этапе 6 меняются:
|
||||
|
||||
- execution governance;
|
||||
- mode selection;
|
||||
- runtime contracts для различных режимов;
|
||||
- provenance/trust model;
|
||||
- способ живой верификации;
|
||||
- отдельный audit pipeline;
|
||||
- user-facing result contracts в зависимости от режима.
|
||||
|
||||
### 3.3. От чего отказываемся
|
||||
|
||||
На этом этапе нужно **сознательно отказаться** от скрытого предположения, что один и тот же pipeline может одинаково качественно обслуживать:
|
||||
|
||||
- быстрый factual вопрос;
|
||||
- глубокое расследование;
|
||||
- широкий аналитический прогон.
|
||||
|
||||
Это неверно.
|
||||
|
||||
Этап 6 официально фиксирует, что продукт имеет несколько execution modes, а не один loop с разной длиной ответа.
|
||||
|
||||
---
|
||||
|
||||
## 4. Архитектурная цель этапа
|
||||
|
||||
К концу Этапа 6 текущая система должна перейти из состояния:
|
||||
|
||||
**“сильный reasoning assistant с investigation capability”**
|
||||
|
||||
в состояние:
|
||||
|
||||
**“зрелый бухгалтерский copilot с явными execution modes, live verification и формальной моделью доверия к результату”**.
|
||||
|
||||
---
|
||||
|
||||
## 5. Главные сущности этапа
|
||||
|
||||
Ниже перечислены ключевые сущности Этапа 6 и детально объясняется, зачем каждая нужна, что с ней делается и как она встраивается в архитектуру.
|
||||
|
||||
---
|
||||
|
||||
## 5.1. Сущность №1 — `execution_mode`
|
||||
|
||||
### Почему нужна
|
||||
|
||||
До Этапа 6 режим работы ассистента чаще всего подразумевается неявно. Это допустимо на ранних этапах, но недопустимо для зрелой системы.
|
||||
|
||||
Если `execution_mode` не формализован, то система:
|
||||
|
||||
- отвечает одинаковым контуром на вопросы принципиально разной глубины;
|
||||
- не может нормально управлять допустимой латентностью;
|
||||
- не может формально различать allowed depth и stop policy;
|
||||
- не может грамотно объяснять пользователю, почему в одном случае ответ быстрый, а в другом запускается расследование или audit.
|
||||
|
||||
### Что делаем
|
||||
|
||||
Вводим базовую продуктовую сущность `execution_mode`.
|
||||
|
||||
### Типы mode
|
||||
|
||||
- `direct_answer`
|
||||
- `investigation`
|
||||
- `audit_batch`
|
||||
|
||||
### Обязательные поля
|
||||
|
||||
- `mode_id`
|
||||
- `mode_type`
|
||||
- `allowed_depth`
|
||||
- `allowed_branching`
|
||||
- `allowed_secondary_checks`
|
||||
- `live_verification_policy`
|
||||
- `latency_profile`
|
||||
- `output_contract`
|
||||
- `stop_policy`
|
||||
- `clarification_policy`
|
||||
- `trust_display_policy`
|
||||
|
||||
### Что это даст
|
||||
|
||||
- система перестанет скрытно использовать один execution loop для всего;
|
||||
- появится product-grade governance;
|
||||
- можно будет жёстко различать не только ответы, но и внутреннюю стратегию исполнения.
|
||||
|
||||
---
|
||||
|
||||
## 5.2. Сущность №2 — `mode_router`
|
||||
|
||||
### Почему нужна
|
||||
|
||||
Semantic routing отвечает на вопрос: **по какому смысловому профилю искать и анализировать**.
|
||||
Но этого недостаточно.
|
||||
|
||||
Нужен слой выше, который отвечает на вопрос:
|
||||
|
||||
- это быстрый direct answer?
|
||||
- это investigation?
|
||||
- это audit?
|
||||
- требуется ли эскалация?
|
||||
- разрешена ли live verification?
|
||||
|
||||
### Что делаем
|
||||
|
||||
Вводим `mode_router` как отдельный runtime-layer над semantic routing.
|
||||
|
||||
### Входы в `mode_router`
|
||||
|
||||
- исходный user query;
|
||||
- decomposition result;
|
||||
- query complexity;
|
||||
- breadth estimate;
|
||||
- expected evidence volume;
|
||||
- active investigation_state;
|
||||
- user intent markers;
|
||||
- explicit requests типа “полный анализ”, “проверь глубоко”, “разберись”, “проведи аудит”, “сделай обзор”, “проверь гипотезу”;
|
||||
- cost/latency policy.
|
||||
|
||||
### Выходы `mode_router`
|
||||
|
||||
- `execution_mode`
|
||||
- `mode_confidence`
|
||||
- `escalation_hint`
|
||||
- `live_verification_allowed`
|
||||
- `expected_output_contract`
|
||||
|
||||
### Что меняется по смыслу
|
||||
|
||||
До этого момента система в основном решала: **какой смысловой маршрут и какие retrieval constraints**.
|
||||
Теперь она решает ещё и: **какой тип исполнения вообще уместен для данного запроса**.
|
||||
|
||||
---
|
||||
|
||||
## 5.3. Сущность №3 — `mode_transition_decision`
|
||||
|
||||
### Почему нужна
|
||||
|
||||
Даже если mode выбран на старте, в реальной работе ассистент может дойти до точки, где исходный режим перестаёт быть достаточным.
|
||||
|
||||
Примеры:
|
||||
|
||||
- direct answer упирается в противоречие и должен перейти в investigation;
|
||||
- investigation упирается в snapshot-неопределённость и требует live verification;
|
||||
- audit находит кластер высокой важности и предлагает drilldown;
|
||||
- direct answer понимает, что вопрос фактически batch-scale.
|
||||
|
||||
### Что делаем
|
||||
|
||||
Вводим сущность `mode_transition_decision`.
|
||||
|
||||
### Поля
|
||||
|
||||
- `decision_id`
|
||||
- `from_mode`
|
||||
- `to_mode`
|
||||
- `reason`
|
||||
- `triggering_evidence`
|
||||
- `confidence_before`
|
||||
- `confidence_after`
|
||||
- `user_visible`
|
||||
- `accepted_automatically`
|
||||
- `requires_user_confirmation`
|
||||
|
||||
### Что это даст
|
||||
|
||||
- режимы перестанут быть статичными;
|
||||
- появится управляемая эскалация;
|
||||
- переходы между режимами станут объяснимыми и контролируемыми.
|
||||
|
||||
---
|
||||
|
||||
## 5.4. Сущность №4 — `live_verification_request`
|
||||
|
||||
### Почему нужна
|
||||
|
||||
До Этапа 6 reasoning почти полностью опирается на:
|
||||
|
||||
- snapshot;
|
||||
- normalized accounting entities;
|
||||
- graph/lifecycle inference;
|
||||
- investigation.
|
||||
|
||||
Но для части high-stakes кейсов этого недостаточно.
|
||||
Нужен способ адресно проверять source-of-truth.
|
||||
|
||||
### Что делаем
|
||||
|
||||
Вводим `live_verification_request` как штатную сущность runtime.
|
||||
|
||||
### Поля
|
||||
|
||||
- `request_id`
|
||||
- `case_id`
|
||||
- `problem_unit_id`
|
||||
- `source_entity_type`
|
||||
- `source_entity_id`
|
||||
- `verification_goal`
|
||||
- `requested_fields`
|
||||
- `verification_scope`
|
||||
- `reason_for_verification`
|
||||
- `urgency`
|
||||
- `policy_basis`
|
||||
- `status`
|
||||
|
||||
### Возможные цели verification
|
||||
|
||||
- подтвердить существование документа;
|
||||
- подтвердить текущий статус;
|
||||
- подтвердить наличие или отсутствие связи;
|
||||
- подтвердить текущее состояние расчёта;
|
||||
- подтвердить lifecycle stage;
|
||||
- подтвердить периодную принадлежность;
|
||||
- снять конфликт snapshot vs expected chain.
|
||||
|
||||
### Что важно
|
||||
|
||||
Live verification — это не новый способ reasoning с нуля.
|
||||
Это механизм **подтверждения, эскалации и повышения доверия** к уже построенному reasoning.
|
||||
|
||||
---
|
||||
|
||||
## 5.5. Сущность №5 — `live_verification_result`
|
||||
|
||||
### Почему нужна
|
||||
|
||||
Недостаточно просто выполнить live-check.
|
||||
Нужно, чтобы результат проверки влиял на кейс, доверие и итоговый ответ.
|
||||
|
||||
### Что делаем
|
||||
|
||||
Вводим `live_verification_result`.
|
||||
|
||||
### Поля
|
||||
|
||||
- `request_id`
|
||||
- `verified_at`
|
||||
- `verified_source`
|
||||
- `verification_status`
|
||||
- `verified_values`
|
||||
- `missing_values`
|
||||
- `discrepancies_vs_snapshot`
|
||||
- `confidence_delta`
|
||||
- `impact_on_problem_unit`
|
||||
- `impact_on_hypothesis`
|
||||
- `impact_on_case`
|
||||
- `next_recommended_action`
|
||||
|
||||
### Что это даёт
|
||||
|
||||
- live verification становится частью расследования, а не внешней справкой;
|
||||
- можно объяснять пользователю, что именно подтверждено живыми данными;
|
||||
- появляется обновление trust state по кейсу.
|
||||
|
||||
---
|
||||
|
||||
## 5.6. Сущность №6 — `audit_run`
|
||||
|
||||
### Почему нужна
|
||||
|
||||
Широкий анализ нельзя обслуживать тем же контрактом, что и direct answer.
|
||||
Он имеет другой scope, другой темп, другой тип результата.
|
||||
|
||||
### Что делаем
|
||||
|
||||
Вводим `audit_run` как отдельную сущность пакетного анализа.
|
||||
|
||||
### Поля
|
||||
|
||||
- `run_id`
|
||||
- `requested_scope`
|
||||
- `time_window`
|
||||
- `included_domains`
|
||||
- `included_accounts`
|
||||
- `included_filters`
|
||||
- `execution_status`
|
||||
- `progress`
|
||||
- `problem_units_count`
|
||||
- `cluster_count`
|
||||
- `top_patterns`
|
||||
- `final_summary`
|
||||
- `report_artifacts`
|
||||
- `drilldown_recommendations`
|
||||
|
||||
### Что это даёт
|
||||
|
||||
- audit перестаёт быть giant-chat-response;
|
||||
- появляется отдельный batch-mode contract;
|
||||
- можно строить отчётную аналитическую логику поверх reasoning substrate.
|
||||
|
||||
---
|
||||
|
||||
## 5.7. Сущность №7 — `trust_state`
|
||||
|
||||
### Почему нужна
|
||||
|
||||
К моменту Этапа 6 система уже может выдавать результаты разной природы:
|
||||
|
||||
- snapshot-derived;
|
||||
- graph-backed;
|
||||
- lifecycle-enriched;
|
||||
- investigation-supported;
|
||||
- live-verified.
|
||||
|
||||
Если это не различать, то ассистент будет звучать одинаково уверенно там, где фактический уровень надёжности разный.
|
||||
|
||||
### Что делаем
|
||||
|
||||
Вводим `trust_state` как формальную сущность доверия к результату.
|
||||
|
||||
### Поля
|
||||
|
||||
- `trust_level`
|
||||
- `evidence_basis`
|
||||
- `snapshot_only`
|
||||
- `graph_supported`
|
||||
- `investigation_supported`
|
||||
- `live_verified`
|
||||
- `limitations`
|
||||
- `confidence_components`
|
||||
- `recommended_next_step`
|
||||
|
||||
### Уровни trust
|
||||
|
||||
Примерный набор:
|
||||
|
||||
- `snapshot_inferred`
|
||||
- `graph_lifecycle_supported`
|
||||
- `investigation_supported`
|
||||
- `live_confirmed`
|
||||
- `inconclusive`
|
||||
|
||||
### Что это даёт
|
||||
|
||||
- взрослая модель доверия;
|
||||
- честность в ответах;
|
||||
- контролируемое различение inferred vs confirmed.
|
||||
|
||||
---
|
||||
|
||||
## 5.8. Сущность №8 — `output_contract_by_mode`
|
||||
|
||||
### Почему нужна
|
||||
|
||||
Разные режимы не могут заканчиваться одинаковым ответом.
|
||||
|
||||
### Что делаем
|
||||
|
||||
Вводим разные result contracts для каждого режима.
|
||||
|
||||
### Для `direct_answer`
|
||||
|
||||
Результат должен содержать:
|
||||
|
||||
- краткий вывод;
|
||||
- mechanism summary;
|
||||
- ключевые документы/сущности;
|
||||
- уровень доверия;
|
||||
- ограничения;
|
||||
- при необходимости — recommendation to investigate/live-check.
|
||||
|
||||
### Для `investigation`
|
||||
|
||||
Результат должен содержать:
|
||||
|
||||
- главную гипотезу;
|
||||
- проверенные ветки;
|
||||
- что подтверждено;
|
||||
- что опровергнуто;
|
||||
- что осталось неопределённым;
|
||||
- trust state;
|
||||
- нужна ли live verification.
|
||||
|
||||
### Для `audit_batch`
|
||||
|
||||
Результат должен содержать:
|
||||
|
||||
- scope анализа;
|
||||
- grouped problem clusters;
|
||||
- recurring patterns;
|
||||
- top risk areas;
|
||||
- impact areas;
|
||||
- drilldown recommendations;
|
||||
- provenance/trust summary.
|
||||
|
||||
### Что это даёт
|
||||
|
||||
- режимы начинают различаться не только глубиной работы, но и формой результата;
|
||||
- пользователь начинает понимать, что система делает и чего ожидать.
|
||||
|
||||
---
|
||||
|
||||
## 6. Полная цепь изменений по архитектуре
|
||||
|
||||
Ниже изменения собраны не по сущностям, а по архитектурному контуру выполнения.
|
||||
|
||||
---
|
||||
|
||||
## 6.1. Вход сообщения и mode selection
|
||||
|
||||
### Сейчас
|
||||
|
||||
До Этапа 6 система в основном определяет semantic meaning и retrieval/investigation path.
|
||||
|
||||
### Что меняем
|
||||
|
||||
Добавляется `mode_router`, который до semantic execution определяет:
|
||||
|
||||
- это direct answer;
|
||||
- investigation;
|
||||
- audit;
|
||||
- возможна ли автоматическая live escalation;
|
||||
- нужен ли mode transition later.
|
||||
|
||||
### Цель
|
||||
|
||||
Ввести execution governance как отдельный слой.
|
||||
|
||||
---
|
||||
|
||||
## 6.2. Direct Answer Path
|
||||
|
||||
### Сейчас
|
||||
|
||||
Система может отвечать быстро, но ещё не отделяет это как отдельный продуктовый режим.
|
||||
|
||||
### Что меняем
|
||||
|
||||
Для `direct_answer` вводятся:
|
||||
|
||||
- ограниченная глубина анализа;
|
||||
- ограниченное число secondary checks;
|
||||
- явный отказ от неограниченного branching;
|
||||
- явная политика эскалации в investigation/live;
|
||||
- отдельный output contract.
|
||||
|
||||
### Цель
|
||||
|
||||
Сделать быстрый режим честным и продуктово предсказуемым.
|
||||
|
||||
---
|
||||
|
||||
## 6.3. Investigation Path
|
||||
|
||||
### Сейчас
|
||||
|
||||
После Этапа 5 bounded investigation уже существует как reasoning capability.
|
||||
|
||||
### Что меняем
|
||||
|
||||
Теперь investigation mode становится полноценным execution mode с:
|
||||
|
||||
- case lifecycle;
|
||||
- mode-aware orchestration;
|
||||
- live verification policy;
|
||||
- stop policy;
|
||||
- investigation-grade output contract.
|
||||
|
||||
### Цель
|
||||
|
||||
Перевести расследование из внутренней возможности в продуктовый режим.
|
||||
|
||||
---
|
||||
|
||||
## 6.4. Audit / Batch Path
|
||||
|
||||
### Сейчас
|
||||
|
||||
Широкие вопросы ещё потенциально могут идти через перегруженный conversational flow.
|
||||
|
||||
### Что меняем
|
||||
|
||||
Добавляется отдельный `audit_run` pipeline:
|
||||
|
||||
1. scope expansion;
|
||||
2. domain/account selection;
|
||||
3. retrieval over larger dataset;
|
||||
4. batch problem-unit assembly;
|
||||
5. lifecycle/graph enrichment;
|
||||
6. grouping and prioritization;
|
||||
7. report synthesis.
|
||||
|
||||
### Цель
|
||||
|
||||
Сделать широкий анализ отдельным execution contour.
|
||||
|
||||
---
|
||||
|
||||
## 6.5. Live Verification Path
|
||||
|
||||
### Сейчас
|
||||
|
||||
Живые проверки либо отсутствуют как штатный assistant path, либо не встроены в формальный trust model.
|
||||
|
||||
### Что меняем
|
||||
|
||||
Вводится два слоя:
|
||||
|
||||
- `live_verification_request`
|
||||
- `live_verification_result`
|
||||
|
||||
А также policy:
|
||||
|
||||
- когда verification разрешён;
|
||||
- когда он обязателен;
|
||||
- когда он только рекомендован;
|
||||
- как verification влияет на trust_state.
|
||||
|
||||
### Цель
|
||||
|
||||
Сделать live verification штатным способом подтверждения результата.
|
||||
|
||||
---
|
||||
|
||||
## 6.6. Trust / Provenance Layer
|
||||
|
||||
### Сейчас
|
||||
|
||||
Даже сильные ответы могут звучать слишком одинаково по степени уверенности.
|
||||
|
||||
### Что меняем
|
||||
|
||||
Каждый результат получает provenance/trust classification.
|
||||
|
||||
### Цель
|
||||
|
||||
Сделать выводы системы честными и операционно интерпретируемыми.
|
||||
|
||||
---
|
||||
|
||||
## 7. Правила mode router
|
||||
|
||||
### 7.1. Когда выбирать `direct_answer`
|
||||
|
||||
Использовать, если:
|
||||
|
||||
- вопрос узкий;
|
||||
- scope локальный;
|
||||
- ожидаемый evidence volume ограничен;
|
||||
- нет явного запроса на глубокий анализ;
|
||||
- достаточно snapshot + current reasoning;
|
||||
- вопрос может быть закрыт accountant-grade answer без investigation case.
|
||||
|
||||
### 7.2. Когда выбирать `investigation`
|
||||
|
||||
Использовать, если:
|
||||
|
||||
- запрос многосоставный;
|
||||
- есть гипотезы;
|
||||
- нужно проверить несколько веток;
|
||||
- нужен branch traversal;
|
||||
- требуется доказательное отделение подтверждённого от вероятного;
|
||||
- direct answer почти наверняка будет недостаточен.
|
||||
|
||||
### 7.3. Когда выбирать `audit_batch`
|
||||
|
||||
Использовать, если:
|
||||
|
||||
- пользователь просит полный анализ;
|
||||
- scope охватывает период/зону/класс рисков;
|
||||
- нужен обзор по множеству problem units;
|
||||
- ожидается групповая аналитика, а не один вывод.
|
||||
|
||||
### 7.4. Когда поднимать live verification
|
||||
|
||||
Использовать, если:
|
||||
|
||||
- кейс high-stakes;
|
||||
- snapshot явно недостаточен;
|
||||
- есть значимый конфликт snapshot vs reasoning;
|
||||
- без подтверждения source-of-truth вывод нельзя считать надёжным;
|
||||
- пользователь требует подтверждения актуального состояния.
|
||||
|
||||
---
|
||||
|
||||
## 8. Подробная модель доверия
|
||||
|
||||
### 8.1. Источники trust
|
||||
|
||||
`trust_state` должен опираться на:
|
||||
|
||||
- snapshot quality;
|
||||
- graph support;
|
||||
- lifecycle support;
|
||||
- problem unit completeness;
|
||||
- investigation completeness;
|
||||
- live verification;
|
||||
- internal contradictions;
|
||||
- unresolved branches.
|
||||
|
||||
### 8.2. Что нельзя делать
|
||||
|
||||
Нельзя вычислять trust только из “общей уверенности модели”.
|
||||
Нужен составной trust, который отражает архитектурные слои, реально участвовавшие в результате.
|
||||
|
||||
### 8.3. Пример trust-логики
|
||||
|
||||
- если вывод опирается только на snapshot + basic retrieval → `snapshot_inferred`
|
||||
- если есть graph + lifecycle + strong problem unit evidence → `graph_lifecycle_supported`
|
||||
- если пройдён bounded investigation с подтверждёнными ветками → `investigation_supported`
|
||||
- если ключевые точки подтверждены live → `live_confirmed`
|
||||
|
||||
---
|
||||
|
||||
## 9. Детальный разбор product modes
|
||||
|
||||
---
|
||||
|
||||
## 9.1. Direct Answer Mode — подробный смысл
|
||||
|
||||
Это режим, в котором ассистент должен отвечать быстро и предметно, не создавая лишней сложности.
|
||||
|
||||
### Что здесь важно
|
||||
|
||||
- не уходить в pseudo-investigation без причины;
|
||||
- не скрывать ограничения;
|
||||
- не делать вид, что direct answer доказал больше, чем реально доказал;
|
||||
- явно рекомендовать investigation/live, если это нужно.
|
||||
|
||||
### Что является хорошим результатом
|
||||
|
||||
- короткий accountant-grade ответ;
|
||||
- mechanism summary;
|
||||
- документы и связи названы конкретно;
|
||||
- trust level честно обозначен.
|
||||
|
||||
---
|
||||
|
||||
## 9.2. Investigation Mode — подробный смысл
|
||||
|
||||
Это режим, где система работает как bounded copilot for reasoning.
|
||||
|
||||
### Что здесь важно
|
||||
|
||||
- открытие investigation case;
|
||||
- branch/hypothesis execution;
|
||||
- evidence separation;
|
||||
- explicit stop criteria;
|
||||
- controlled escalation to live verification.
|
||||
|
||||
### Что является хорошим результатом
|
||||
|
||||
- пользователь видит логику расследования;
|
||||
- знает, что подтверждено;
|
||||
- понимает, что ещё не закрыто;
|
||||
- получает recommendation on next step.
|
||||
|
||||
---
|
||||
|
||||
## 9.3. Audit / Batch Mode — подробный смысл
|
||||
|
||||
Это режим, где система превращается во внутренний аналитический инструмент.
|
||||
|
||||
### Что здесь важно
|
||||
|
||||
- отдельный execution contour;
|
||||
- batch retrieval and assembly;
|
||||
- группировка и приоритизация;
|
||||
- итог не в форме “ответа на вопрос”, а в форме structured analytical output.
|
||||
|
||||
### Что является хорошим результатом
|
||||
|
||||
- зоны риска;
|
||||
- problem clusters;
|
||||
- recurring patterns;
|
||||
- приоритеты drilldown;
|
||||
- ясная граница между overview и detail.
|
||||
|
||||
---
|
||||
|
||||
## 10. Как не уткнуться в главный риск этапа
|
||||
|
||||
### Главный риск
|
||||
|
||||
Сделать режимы как UI-названия или разные “тона ответа”, но не как реально разные execution contracts.
|
||||
|
||||
Если:
|
||||
|
||||
- direct / investigation / audit отличаются только длиной ответа;
|
||||
- live verification существует, но не влияет на trust_state;
|
||||
- audit просто длиннее direct answer;
|
||||
- investigation просто делает 2–3 retrieval вместо одного;
|
||||
|
||||
— этап не выполнен.
|
||||
|
||||
### Что делать, чтобы этого не произошло
|
||||
|
||||
1. У каждого mode должны быть собственные:
|
||||
- allowed depth
|
||||
- branching policy
|
||||
- output contract
|
||||
- stop policy
|
||||
- live verification policy
|
||||
2. `mode_router` должен быть отдельным runtime-layer.
|
||||
3. `mode_transition_decision` должен быть формальной сущностью.
|
||||
4. `trust_state` должен быть обязательной частью результата.
|
||||
5. `audit_run` должен быть отдельным execution artifact.
|
||||
|
||||
---
|
||||
|
||||
## 11. Что именно должно быть разработано в коде и архитектуре
|
||||
|
||||
### 11.1. Новый runtime слой
|
||||
|
||||
- `mode_router`
|
||||
- `mode_transition_decision`
|
||||
- `execution_mode` config
|
||||
|
||||
### 11.2. Новый live слой
|
||||
|
||||
- `live_verification_request`
|
||||
- `live_verification_result`
|
||||
- `live_verification_policy`
|
||||
|
||||
### 11.3. Новый audit слой
|
||||
|
||||
- `audit_run`
|
||||
- batch execution pipeline
|
||||
- aggregation / grouping / reporting logic
|
||||
|
||||
### 11.4. Новый trust слой
|
||||
|
||||
- `trust_state`
|
||||
- provenance markers
|
||||
- trust computation policy
|
||||
|
||||
### 11.5. Новый output contract layer
|
||||
|
||||
- direct answer contract
|
||||
- investigation result contract
|
||||
- audit report contract
|
||||
|
||||
---
|
||||
|
||||
## 12. Что переписываем, а что только расширяем
|
||||
|
||||
### Не переписываем полностью
|
||||
|
||||
- retrieval core;
|
||||
- lifecycle core;
|
||||
- graph core;
|
||||
- investigation engine;
|
||||
- problem unit model.
|
||||
|
||||
### Существенно расширяем
|
||||
|
||||
- execution governance;
|
||||
- user-facing output contracts;
|
||||
- trust/provenance;
|
||||
- live source integration;
|
||||
- batch analysis contour.
|
||||
|
||||
### Частично усиливаем
|
||||
|
||||
- current assistant orchestration;
|
||||
- clarification/escalation logic;
|
||||
- benchmark/eval suite;
|
||||
- frontend presentation layer for result types.
|
||||
|
||||
---
|
||||
|
||||
## 13. Артефакты этапа
|
||||
|
||||
К концу Этапа 6 должны появиться следующие артефакты:
|
||||
|
||||
1. `execution_mode` schema and config
|
||||
2. `mode_router` specification
|
||||
3. `mode_transition_decision` schema
|
||||
4. `live_verification_request` schema
|
||||
5. `live_verification_result` schema
|
||||
6. `trust_state` specification
|
||||
7. `audit_run` schema
|
||||
8. `output_contract_by_mode` specification
|
||||
9. `live_verification_policy` document
|
||||
10. `mode_eval_harness` specification
|
||||
|
||||
---
|
||||
|
||||
## 14. Критерии приёмки этапа
|
||||
|
||||
Этап считается выполненным только если:
|
||||
|
||||
### 14.1. По execution modes
|
||||
|
||||
- система реально различает direct / investigation / audit;
|
||||
- у режимов разные execution policies;
|
||||
- mode selection объясним и предсказуем.
|
||||
|
||||
### 14.2. По live verification
|
||||
|
||||
- live verification существует как штатная сущность и runtime path;
|
||||
- live verification влияет на trust_state и итоговый результат;
|
||||
- система умеет честно разделять verified vs inferred.
|
||||
|
||||
### 14.3. По audit mode
|
||||
|
||||
- batch mode запускается как отдельный контур;
|
||||
- итог audit — это аналитический output, а не просто длинный answer;
|
||||
- есть grouped problem clusters и drilldown recommendations.
|
||||
|
||||
### 14.4. По trust/provenance
|
||||
|
||||
- каждый результат имеет trust/provenance classification;
|
||||
- разные уровни подтверждённости различимы пользователю и системе.
|
||||
|
||||
### 14.5. По продуктовой зрелости
|
||||
|
||||
- пользователь ощущает реальную разницу между режимами;
|
||||
- ассистент умеет не только думать, но и жить как product system.
|
||||
|
||||
---
|
||||
|
||||
## 15. Что не считается результатом этапа
|
||||
|
||||
Этап не считается выполненным, если произошло что-то из этого:
|
||||
|
||||
- просто добавили переключатель режима в UI;
|
||||
- investigation и audit отличаются только размером ответа;
|
||||
- live verification не встроен в trust/provenance;
|
||||
- snapshot/live-ответы звучат одинаково уверенно;
|
||||
- audit не имеет собственного execution artifact;
|
||||
- mode transitions не формализованы.
|
||||
|
||||
---
|
||||
|
||||
## 16. Идеальный результат этапа
|
||||
|
||||
После завершения Этапа 6 ассистент ещё не обязан быть полностью enterprise-scale системой, но он уже должен стать зрелым бухгалтерским copilot’ом, который:
|
||||
|
||||
- умеет быстро отвечать на узкие вопросы;
|
||||
- умеет вести bounded investigation;
|
||||
- умеет запускать широкий batch analysis;
|
||||
- умеет подтверждать выводы живыми данными;
|
||||
- умеет честно различать уровни доверия;
|
||||
- живёт как продукт, а не как набор архитектурных слоёв.
|
||||
|
||||
---
|
||||
|
||||
## 17. Управленческое резюме этапа
|
||||
|
||||
Этап 6 завершает формирование взрослой продуктовой архитектуры Assistant Mode.
|
||||
|
||||
Это этап, на котором:
|
||||
|
||||
- reasoning превращается в product behavior;
|
||||
- investigation превращается в официальный execution mode;
|
||||
- audit перестаёт быть перегруженным чат-ответом;
|
||||
- live verification становится штатным механизмом подтверждения;
|
||||
- trust/provenance перестаёт быть неявной уверенностью модели и становится формальным контрактом результата.
|
||||
|
||||
Именно после этого этапа ассистент можно считать не просто технически сильной системой, а зрелым бухгалтерским copilot’ом.
|
||||
+716
@@ -0,0 +1,716 @@
|
||||
ACCEPTANCE_CHECKLIST_STAGE_01.md
|
||||
|
||||
# ACCEPTANCE_CHECKLIST_STAGE_01
|
||||
|
||||
## Назначение документа
|
||||
|
||||
Этот документ используется для приёмки первой волны реализации Stage 1.
|
||||
Его задача — не проверить “что-то поменялось”, а убедиться, что:
|
||||
|
||||
- foundation layer действительно усилен;
|
||||
- текущий scope не расползся;
|
||||
- structural gaps реально закрыты;
|
||||
- изменения не маскируют проблемы косметикой;
|
||||
- заложена корректная база для следующих этапов.
|
||||
|
||||
Документ обязателен для:
|
||||
- Codex;
|
||||
- разработчика;
|
||||
- ручного review;
|
||||
- финальной фиксации результата по Stage 1.
|
||||
|
||||
---
|
||||
|
||||
## Статус документа
|
||||
|
||||
- Статус: чеклист приёмки Stage 1
|
||||
- Язык: русский
|
||||
- Режим использования: обязателен при завершении каждой волны и при финальной приёмке Stage 1
|
||||
- При конфликте по scope приоритет имеет `STAGE_01_TASK_CARD.md`
|
||||
- При конфликте по архитектурным ограничениям приоритет имеет `ARCHITECTURE_GUARDRAILS.md`
|
||||
- При конфликте по platform logic приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
|
||||
---
|
||||
|
||||
## Правила оценки
|
||||
|
||||
Для каждого пункта допускаются только следующие статусы:
|
||||
|
||||
- `PASS` — выполнено полностью
|
||||
- `PARTIAL` — выполнено частично, требуется доработка
|
||||
- `FAIL` — не выполнено
|
||||
- `N/A` — не применимо, только если это действительно обосновано
|
||||
|
||||
Для каждого пункта должен быть указан комментарий:
|
||||
- что проверялось;
|
||||
- где это реализовано;
|
||||
- чем подтверждается;
|
||||
- какие ограничения остались.
|
||||
|
||||
---
|
||||
|
||||
## Общая логика приёмки
|
||||
|
||||
Stage 1 считается принятым только если одновременно соблюдены условия:
|
||||
|
||||
1. Закрыт именно Stage 1, а не “произвольный улучшенный вариант”.
|
||||
2. Текущий рабочий контур не разрушен.
|
||||
3. Есть минимальный формальный `investigation_state`.
|
||||
4. Есть улучшение broad/generic question handling.
|
||||
5. Evidence стало более структурным.
|
||||
6. Ответы стали полезнее для бухгалтерского сценария.
|
||||
7. Есть baseline eval / benchmark harness.
|
||||
8. Есть accountant-facing метрики.
|
||||
9. Нет скрытого выезда в Stage 2–6.
|
||||
10. Изменения совместимы с platform core.
|
||||
|
||||
Если хотя бы один из этих пунктов провален, Stage 1 не считается завершённым.
|
||||
|
||||
---
|
||||
|
||||
# Блок A. Scope discipline
|
||||
|
||||
## A1. Реализован именно Stage 1
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- реализованы только foundation-hardening изменения;
|
||||
- не добавлена скрытая логика следующих этапов;
|
||||
- улучшения соответствуют текущему scope.
|
||||
|
||||
Критерии PASS:
|
||||
- все ключевые изменения относятся к Stage 1;
|
||||
- нет “заодно реализованных” future-stage подсистем.
|
||||
|
||||
---
|
||||
|
||||
## A2. Нет скрытого выезда в Stage 2
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- не внедрён полноценный `problem unit architecture`;
|
||||
- нет полной смены retrieval unit model;
|
||||
- нет явного runtime problem decomposition как core path.
|
||||
|
||||
Критерии PASS:
|
||||
- максимум заложена совместимость;
|
||||
- полноценный Stage 2 runtime не реализован.
|
||||
|
||||
---
|
||||
|
||||
## A3. Нет скрытого выезда в Stage 3
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- не внедрён lifecycle engine;
|
||||
- нет полноценной дефектной/событийной модели lifecycle как core path;
|
||||
- нет ранней формализации состояния документа/процесса на уровне Stage 3.
|
||||
|
||||
Критерии PASS:
|
||||
- lifecycle как будущий слой не реализован.
|
||||
|
||||
---
|
||||
|
||||
## A4. Нет скрытого выезда в Stage 4
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- не внедрён полноценный ontology/graph runtime;
|
||||
- не добавлена тяжёлая graph-логика как обязательный путь ответа;
|
||||
- не построен graph-first core.
|
||||
|
||||
Критерии PASS:
|
||||
- graph runtime отсутствует;
|
||||
- максимум есть совместимые контракты, но не core-layer.
|
||||
|
||||
---
|
||||
|
||||
## A5. Нет скрытого выезда в Stage 5
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- не внедрён full investigation engine;
|
||||
- нет полноценного branching case-runtime;
|
||||
- нет сложного bounded investigation orchestration.
|
||||
|
||||
Критерии PASS:
|
||||
- присутствует только minimal `investigation_state`, а не full engine.
|
||||
|
||||
---
|
||||
|
||||
## A6. Нет скрытого выезда в Stage 6
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- не внедрён live verification core;
|
||||
- нет product mode split `direct / investigation / audit` как основного runtime;
|
||||
- нет полноценного trust-state live contour.
|
||||
|
||||
Критерии PASS:
|
||||
- Stage 6 логика не реализована как текущий рабочий слой.
|
||||
|
||||
---
|
||||
|
||||
## A7. Не выполнен большой ненужный рефактор
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- не переписан transport layer без необходимости;
|
||||
- не переписан endpoint layer без необходимости;
|
||||
- не переписан base routing без необходимости;
|
||||
- не переписан assistant loop ради архитектурной красоты.
|
||||
|
||||
Критерии PASS:
|
||||
- изменения локальны и обоснованы;
|
||||
- рабочий контур сохранён.
|
||||
|
||||
---
|
||||
|
||||
# Блок B. Investigation state
|
||||
|
||||
## B1. Введён явный минимальный `investigation_state`
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- существует отдельная state-сущность или эквивалентный контракт;
|
||||
- state не размазан по случайным переменным;
|
||||
- state не заменён chat history.
|
||||
|
||||
Критерии PASS:
|
||||
- есть явный минимальный state layer;
|
||||
- его поля и правила обновления понятны.
|
||||
|
||||
---
|
||||
|
||||
## B2. `investigation_state` реально используется
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- state участвует в follow-up логике;
|
||||
- state влияет на обработку продолжения разговора;
|
||||
- state не является “мёртвой” сущностью.
|
||||
|
||||
Критерии PASS:
|
||||
- есть реальные runtime-точки использования;
|
||||
- поведение follow-up отличается от наивной одношаговой обработки.
|
||||
|
||||
---
|
||||
|
||||
## B3. `investigation_state` bounded и минимален
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- state не пытается хранить всё подряд;
|
||||
- нет скрытого full case-engine;
|
||||
- state ограничен по назначению.
|
||||
|
||||
Критерии PASS:
|
||||
- state минимален, но полезен;
|
||||
- state не превращён в premature investigation runtime.
|
||||
|
||||
---
|
||||
|
||||
## B4. `investigation_state` future-compatible
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- структура state не конфликтует с будущим Stage 5;
|
||||
- контракты не тупиковые;
|
||||
- state можно расширить без полного слома.
|
||||
|
||||
Критерии PASS:
|
||||
- заложена совместимость без premature implementation.
|
||||
|
||||
---
|
||||
|
||||
# Блок C. Broad / generic query handling
|
||||
|
||||
## C1. Выявление broad/generic questions стало явным
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- система различает широкий, недоопределённый и достаточно конкретный вопрос;
|
||||
- broadness не определяется только постфактум красивым ответом.
|
||||
|
||||
Критерии PASS:
|
||||
- есть явная логика или критерии определения broad/generic запросов.
|
||||
|
||||
---
|
||||
|
||||
## C2. Появился controlled narrowing
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- система умеет сузить вопрос;
|
||||
- либо умеет зафиксировать, что вопрос слишком общий;
|
||||
- либо предлагает следующий прикладной шаг.
|
||||
|
||||
Критерии PASS:
|
||||
- broad-вопрос не приводит автоматически к слабому общему ответу;
|
||||
- narrowing выполняется или честно сигнализируется.
|
||||
|
||||
---
|
||||
|
||||
## C3. Generic-answer rate снизился
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- по контрольному набору кейсов доля “общих, малооперабельных” ответов уменьшилась;
|
||||
- это подтверждается eval/ручным review.
|
||||
|
||||
Критерии PASS:
|
||||
- улучшение заметно и измеримо;
|
||||
- это не только субъективное ощущение.
|
||||
|
||||
---
|
||||
|
||||
## C4. Улучшение broad-handling не сводится к prompt-only
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- есть структурные изменения в логике;
|
||||
- не всё улучшение сделано за счёт переписывания системного промпта.
|
||||
|
||||
Критерии PASS:
|
||||
- prompt может помогать, но не является единственным решением.
|
||||
|
||||
---
|
||||
|
||||
# Блок D. Evidence structure
|
||||
|
||||
## D1. Evidence больше не является просто текстовым пересказом
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- evidence имеет отдельную структуру или явные поля;
|
||||
- evidence не существует только как часть prose-ответа.
|
||||
|
||||
Критерии PASS:
|
||||
- evidence выделено как отдельный элемент логики/контракта.
|
||||
|
||||
---
|
||||
|
||||
## D2. У evidence есть источник / происхождение
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- для evidence фиксируется source_type / source_ref / pointer или эквивалент;
|
||||
- источник не теряется при сборке ответа.
|
||||
|
||||
Критерии PASS:
|
||||
- происхождение каждого значимого evidence можно проследить.
|
||||
|
||||
---
|
||||
|
||||
## D3. У evidence есть связь с утверждением
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- ответные утверждения опираются на конкретные evidence items;
|
||||
- нет ситуации, где вывод существует отдельно от опоры.
|
||||
|
||||
Критерии PASS:
|
||||
- связка claim ↔ evidence читаема и проверяема.
|
||||
|
||||
---
|
||||
|
||||
## D4. У evidence есть механизм/основание
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- система показывает не только “что найдено”, но и “почему это подтверждает вывод”;
|
||||
- есть mechanism note / reason / basis или эквивалент.
|
||||
|
||||
Критерии PASS:
|
||||
- объяснение перестаёт быть чисто декларативным.
|
||||
|
||||
---
|
||||
|
||||
## D5. У evidence есть честная ограниченность / confidence
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- степень уверенности или ограниченности не скрыта;
|
||||
- не создаётся ложная определённость.
|
||||
|
||||
Критерии PASS:
|
||||
- uncertainty явно видна;
|
||||
- слабая опора не маскируется уверенным тоном.
|
||||
|
||||
---
|
||||
|
||||
# Блок E. Answer quality
|
||||
|
||||
## E1. Ответ стал полезнее для бухгалтерского сценария
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- ответы стали более прикладными;
|
||||
- пользователь понимает, что найдено, на чём основано и что делать дальше;
|
||||
- ответ не ограничивается пересказом данных.
|
||||
|
||||
Критерии PASS:
|
||||
- manual review показывает явный рост операбельности ответов.
|
||||
|
||||
---
|
||||
|
||||
## E2. Ответ стал более дисциплинированным по структуре
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- различаются summary, direct answer, evidence, uncertainty, next step или эквивалент;
|
||||
- ответ не разваливается в свободный текст.
|
||||
|
||||
Критерии PASS:
|
||||
- есть управляемая и повторяемая структура ответа.
|
||||
|
||||
---
|
||||
|
||||
## E3. Недостаток данных обрабатывается честно
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- если опоры недостаточно, система не симулирует точный вывод;
|
||||
- явно обозначается ограниченность;
|
||||
- предлагается следующий полезный шаг.
|
||||
|
||||
Критерии PASS:
|
||||
- honest uncertainty работает не только в теории.
|
||||
|
||||
---
|
||||
|
||||
## E4. Улучшение качества не является чисто косметическим
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- улучшение связано с state/evidence/narrowing;
|
||||
- это не просто более гладкий текст ответа.
|
||||
|
||||
Критерии PASS:
|
||||
- answer quality опирается на structural changes.
|
||||
|
||||
---
|
||||
|
||||
# Блок F. Eval / metrics
|
||||
|
||||
## F1. Добавлен baseline benchmark / eval harness
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- существует минимальный воспроизводимый eval-контур;
|
||||
- можно запускать сравнение до/после;
|
||||
- можно фиксировать регрессии.
|
||||
|
||||
Критерии PASS:
|
||||
- eval не остаётся ручной и разовой активностью.
|
||||
|
||||
---
|
||||
|
||||
## F2. Есть контрольный набор кейсов
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- есть набор representative вопросов;
|
||||
- в набор входят broad/generic/follow-up/evidence-sensitive кейсы;
|
||||
- набор пригоден для повторного запуска.
|
||||
|
||||
Критерии PASS:
|
||||
- eval основан на зафиксированном наборе, а не на случайных примерах.
|
||||
|
||||
---
|
||||
|
||||
## F3. Появились accountant-facing метрики
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- измеряется не только техническая проходимость;
|
||||
- есть метрики полезности ответа;
|
||||
- есть метрики genericness / evidence quality / narrowing usefulness или эквиваленты.
|
||||
|
||||
Критерии PASS:
|
||||
- продуктовая полезность стала измеримой.
|
||||
|
||||
---
|
||||
|
||||
## F4. Можно сравнить поведение до/после
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- есть baseline;
|
||||
- есть результаты после изменений;
|
||||
- можно показать, что конкретно улучшилось или ухудшилось.
|
||||
|
||||
Критерии PASS:
|
||||
- есть сравнимость, а не просто “кажется стало лучше”.
|
||||
|
||||
---
|
||||
|
||||
## F5. Green tests не являются единственным доказательством готовности
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- решение не принято только на основании unit/integration success;
|
||||
- есть ручной review и/или accountant-facing оценка.
|
||||
|
||||
Критерии PASS:
|
||||
- продуктовая приёмка не подменена технической.
|
||||
|
||||
---
|
||||
|
||||
# Блок G. Observability / diagnostics
|
||||
|
||||
## G1. Новая логика диагностируема
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- можно понять, как было принято решение;
|
||||
- можно увидеть, что произошло при broad-handling/state/evidence assembly;
|
||||
- при сбое путь анализа не непрозрачен.
|
||||
|
||||
Критерии PASS:
|
||||
- есть хотя бы минимальная наблюдаемость новых решений.
|
||||
|
||||
---
|
||||
|
||||
## G2. Новая логика тестируема
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- есть тесты или проверяемые контуры;
|
||||
- критичные новые ветки поведения можно воспроизвести.
|
||||
|
||||
Критерии PASS:
|
||||
- поведение не завязано только на ручной удачный сценарий.
|
||||
|
||||
---
|
||||
|
||||
## G3. Новые контракты описаны явно
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- state/evidence/eval contracts формализованы;
|
||||
- их поля и назначение понятны;
|
||||
- они не существуют только имплицитно в коде.
|
||||
|
||||
Критерии PASS:
|
||||
- нет неявной архитектуры “между строк”.
|
||||
|
||||
---
|
||||
|
||||
# Блок H. Migration / compatibility
|
||||
|
||||
## H1. Новые сущности имеют явный source of truth
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- понятно, где хранится canonical form;
|
||||
- понятно, что является derived form;
|
||||
- нет размазанного состояния.
|
||||
|
||||
Критерии PASS:
|
||||
- контракты и источники истины определены явно.
|
||||
|
||||
---
|
||||
|
||||
## H2. Изменения не создают тупик для будущих этапов
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- нет архитектурного решения, которое мешает Stage 2–6;
|
||||
- не принято временное решение, выдаваемое за целевое.
|
||||
|
||||
Критерии PASS:
|
||||
- Stage 1 усиливает основание, а не закрывает путь вперёд.
|
||||
|
||||
---
|
||||
|
||||
## H3. Обратная совместимость и миграции понятны
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- если появились новые контракты/хранилища/схемы, описано как они инициализируются;
|
||||
- понятно, нужен ли migration step;
|
||||
- понятно, что будет со старым поведением.
|
||||
|
||||
Критерии PASS:
|
||||
- внедрение можно повторить и сопровождать без хаоса.
|
||||
|
||||
---
|
||||
|
||||
# Блок I. Documentation completeness
|
||||
|
||||
## I1. Есть итоговый отчёт по реализации
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- описано, что сделано;
|
||||
- описано, какие файлы изменены;
|
||||
- описано, что осталось вне scope.
|
||||
|
||||
Критерии PASS:
|
||||
- по результату можно быстро понять состояние системы.
|
||||
|
||||
---
|
||||
|
||||
## I2. Есть acceptance mapping
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- для каждого ключевого изменения понятно, какой критерий Stage 1 оно закрывает;
|
||||
- нет “непонятных улучшений”.
|
||||
|
||||
Критерии PASS:
|
||||
- изменения привязаны к acceptance criteria.
|
||||
|
||||
---
|
||||
|
||||
## I3. Есть список сознательно не реализованного
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Проверка:
|
||||
- явно перечислено, что не делалось сейчас;
|
||||
- причины отложенных вещей зафиксированы;
|
||||
- нет скрытого scope drift.
|
||||
|
||||
Критерии PASS:
|
||||
- границы текущего этапа прозрачны.
|
||||
|
||||
---
|
||||
|
||||
# Блок J. Финальное решение по этапу
|
||||
|
||||
## J1. Stage 1 можно считать принятым
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Критерии PASS:
|
||||
- блоки A–I не содержат критических FAIL;
|
||||
- PARTIAL не влияют на core acceptance;
|
||||
- foundation реально усилен.
|
||||
|
||||
---
|
||||
|
||||
## J2. Stage 1 нельзя считать принятым
|
||||
Статус:
|
||||
Комментарий:
|
||||
|
||||
Ставится `PASS`, если выполнено хотя бы одно из условий:
|
||||
- отсутствует `investigation_state`;
|
||||
- broad/generic handling не улучшен по сути;
|
||||
- evidence осталось неструктурированным;
|
||||
- accountant-facing eval отсутствует;
|
||||
- был скрытый выезд в future stages;
|
||||
- рабочий контур сломан;
|
||||
- изменения чисто косметические.
|
||||
|
||||
---
|
||||
|
||||
# Итоговая сводка по приёмке
|
||||
|
||||
## Общий итог
|
||||
- Результат: `PASS / PARTIAL / FAIL`
|
||||
- Дата проверки:
|
||||
- Проверял:
|
||||
- Версия / ветка / commit:
|
||||
- Связанные документы:
|
||||
|
||||
---
|
||||
|
||||
## Ключевые сильные стороны
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
---
|
||||
|
||||
## Ключевые недочёты
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
---
|
||||
|
||||
## Что обязательно исправить до приёмки
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
---
|
||||
|
||||
## Что допустимо перенести в следующий этап
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
---
|
||||
|
||||
## Явно подтверждено как non-scope текущего этапа
|
||||
1.
|
||||
2.
|
||||
3.
|
||||
|
||||
---
|
||||
|
||||
## Финальное решение
|
||||
- `Принять Stage 1`
|
||||
- `Принять Stage 1 условно`
|
||||
- `Вернуть на доработку`
|
||||
|
||||
Комментарий:
|
||||
|
||||
---
|
||||
|
||||
# Короткая практическая формула
|
||||
|
||||
Stage 1 считается успешным не тогда, когда:
|
||||
|
||||
- код стал “чище”;
|
||||
- ответы стали “приятнее”;
|
||||
- тесты стали зелёными.
|
||||
|
||||
Stage 1 считается успешным тогда, когда одновременно:
|
||||
|
||||
- foundation стал структурно крепче;
|
||||
- state перестал быть неявным;
|
||||
- evidence перестало быть просто текстом;
|
||||
- broad-вопросы стали обрабатываться дисциплинированно;
|
||||
- качество стало измеримым;
|
||||
- путь к следующим этапам остался открыт.
|
||||
+533
@@ -0,0 +1,533 @@
|
||||
ARCHITECTURE_GUARDRAILS.md
|
||||
|
||||
# ARCHITECTURE_GUARDRAILS
|
||||
|
||||
## Назначение документа
|
||||
|
||||
Этот документ фиксирует **жёсткие архитектурные рамки** для работы Codex и разработчика по бухгалтерскому ассистенту.
|
||||
|
||||
Документ нужен, чтобы:
|
||||
|
||||
- не допустить расползания scope;
|
||||
- не дать текущей реализации преждевременно превратиться в Stage 2–6;
|
||||
- не допустить появления скрытых костылей под видом “улучшения архитектуры”;
|
||||
- удержать изменения в рамках текущего этапа;
|
||||
- сохранить совместимость с будущим развитием системы.
|
||||
|
||||
Документ не заменяет:
|
||||
- `CODEX_MASTER_BRIEF.md`
|
||||
- `STAGE_01_TASK_CARD.md`
|
||||
- `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
- этапные ТЗ
|
||||
|
||||
Его задача — фиксировать **что можно**, **что нельзя** и **по каким признакам видно, что реализация пошла не туда**.
|
||||
|
||||
---
|
||||
|
||||
## Статус документа
|
||||
|
||||
- Статус: обязательный архитектурный ограничитель
|
||||
- Язык: русский
|
||||
- Режим использования: обязателен к применению до любых кодовых изменений
|
||||
- При конфликте с текущим scope приоритет имеет `STAGE_01_TASK_CARD.md`
|
||||
- При конфликте по платформенным ограничениям приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
|
||||
---
|
||||
|
||||
## Базовая установка
|
||||
|
||||
Текущая задача — **не построить конечную архитектуру**, а **усилить существующую систему так, чтобы она стала устойчивой основой для следующих этапов**.
|
||||
|
||||
Следовательно:
|
||||
|
||||
- нельзя преждевременно тащить в код будущие слои;
|
||||
- нельзя переписывать рабочий контур ради абстрактной чистоты;
|
||||
- нельзя маскировать structural gaps косметикой;
|
||||
- нельзя заменять архитектуру “умным” поведением промптов.
|
||||
|
||||
---
|
||||
|
||||
## Главный принцип
|
||||
|
||||
**Каждое изменение должно отвечать на вопрос:**
|
||||
|
||||
> Это действительно необходимо для текущего этапа, или это попытка заранее реализовать следующий уровень системы?
|
||||
|
||||
Если ответ неочевиден, изменение считается подозрительным и должно быть вынесено на отдельное согласование.
|
||||
|
||||
---
|
||||
|
||||
## Архитектурная позиция проекта
|
||||
|
||||
Развитие системы должно идти поэтапно.
|
||||
|
||||
### Текущая логика развития
|
||||
1. Усиление foundation
|
||||
2. Сдвиг retrieval units
|
||||
3. Формализация lifecycle
|
||||
4. Формирование graph core
|
||||
5. Построение investigation engine
|
||||
6. Live verification и product modes
|
||||
|
||||
Из этого следует:
|
||||
|
||||
- текущий этап не должен содержать скрытую реализацию graph runtime;
|
||||
- текущий этап не должен содержать полноценный investigation engine;
|
||||
- текущий этап не должен содержать полноценный mode router;
|
||||
- текущий этап не должен содержать live verification core path;
|
||||
- текущий этап не должен содержать premature orchestration architecture.
|
||||
|
||||
---
|
||||
|
||||
## Что считается архитектурно допустимым
|
||||
|
||||
Допустимы только такие изменения, которые одновременно:
|
||||
|
||||
1. закрывают конкретный gap текущего этапа;
|
||||
2. дают прямую runtime-пользу уже сейчас;
|
||||
3. не тянут в код полноразмерные future-stage слои;
|
||||
4. не ломают текущий рабочий контур;
|
||||
5. не создают новый труднообратимый архитектурный долг.
|
||||
|
||||
---
|
||||
|
||||
## Что считается архитектурно недопустимым
|
||||
|
||||
Недопустимы изменения, которые:
|
||||
|
||||
- реализуют будущее раньше, чем для него готов фундамент;
|
||||
- создают тяжёлые абстракции без текущей пользы;
|
||||
- требуют большого переписывания ради “красоты”;
|
||||
- маскируют отсутствие структуры промптами;
|
||||
- подменяют состояние чатом;
|
||||
- подменяют evidence словами;
|
||||
- вводят новые сервисы без необходимости;
|
||||
- создают platform complexity, не нужную текущему шагу.
|
||||
|
||||
---
|
||||
|
||||
## Жёсткие guardrails
|
||||
|
||||
### 1. Не переписывать рабочий контур без прямой причины
|
||||
|
||||
Без крайней необходимости запрещено переписывать:
|
||||
|
||||
- transport layer;
|
||||
- endpoint layer;
|
||||
- base routing;
|
||||
- normalizer pipeline;
|
||||
- текущий путь сборки ответа;
|
||||
- рабочий retrieval flow;
|
||||
- уже действующий assistant loop.
|
||||
|
||||
Разрешены только точечные изменения, если они:
|
||||
- прямо обязательны для Stage 1;
|
||||
- не могут быть внесены более локально.
|
||||
|
||||
---
|
||||
|
||||
### 2. Не строить новую архитектуру вместо усиления текущей
|
||||
|
||||
Нельзя использовать текущий этап как повод для:
|
||||
|
||||
- полного redesign системы;
|
||||
- переезда на другую базовую схему исполнения;
|
||||
- внедрения большого orchestration layer;
|
||||
- скрытого перехода на новую core-модель;
|
||||
- замены существующей структуры на “более правильную” без немедленной пользы.
|
||||
|
||||
---
|
||||
|
||||
### 3. Не внедрять преждевременно Stage 2–6
|
||||
|
||||
До наступления соответствующих этапов запрещено внедрять как core-runtime:
|
||||
|
||||
- полноценный `problem unit architecture`;
|
||||
- полноценный lifecycle engine;
|
||||
- полноразмерный ontology/graph runtime;
|
||||
- full investigation engine;
|
||||
- live verification core;
|
||||
- split product runtime `direct / investigation / audit`;
|
||||
- тяжёлую multi-step orchestration system;
|
||||
- систему ветвления расследований как основной путь выполнения.
|
||||
|
||||
Если требуется часть будущей совместимости, она должна реализовываться:
|
||||
- минимально;
|
||||
- локально;
|
||||
- через совместимые контракты;
|
||||
- без включения всего будущего слоя.
|
||||
|
||||
---
|
||||
|
||||
### 4. Не решать structural gaps только промптами
|
||||
|
||||
Запрещено считать, что следующие проблемы решены, если было сделано только prompt tuning:
|
||||
|
||||
- отсутствие формального state;
|
||||
- слабое evidence-linking;
|
||||
- generic response behavior;
|
||||
- отсутствие boundedness;
|
||||
- отсутствие quality metrics;
|
||||
- неявная uncertainty handling;
|
||||
- отсутствие управляемого narrowing.
|
||||
|
||||
Промпт может помогать, но не может быть единственной формой архитектурного решения.
|
||||
|
||||
---
|
||||
|
||||
### 5. Не подменять state историей чата
|
||||
|
||||
Запрещено считать, что:
|
||||
- chat history,
|
||||
- предыдущий ответ,
|
||||
- контекст последнего сообщения
|
||||
|
||||
эквивалентны формальному state.
|
||||
|
||||
Если системе нужен state, он должен быть:
|
||||
- явным;
|
||||
- минимальным;
|
||||
- ограниченным;
|
||||
- типизированным;
|
||||
- контролируемым.
|
||||
|
||||
---
|
||||
|
||||
### 6. Не подменять evidence текстовой убедительностью
|
||||
|
||||
Запрещено считать, что ответ “обоснован”, если модель просто написала убедительный текст.
|
||||
|
||||
Evidence должно иметь хотя бы минимально явную структуру:
|
||||
- источник;
|
||||
- тип опоры;
|
||||
- связь с утверждением;
|
||||
- механизм/основание;
|
||||
- степень уверенности или ограниченности.
|
||||
|
||||
---
|
||||
|
||||
### 7. Не вводить абстракции “на будущее” без runtime-пользы
|
||||
|
||||
Любая новая абстракция должна быть оправдана текущей пользой.
|
||||
|
||||
Недопустимы:
|
||||
- интерфейсы ради гипотетического расширения;
|
||||
- service layers без прямой функции на текущем этапе;
|
||||
- сложные фабрики/адаптеры/оркестраторы “на потом”;
|
||||
- обобщения, которые пока ничего не упрощают.
|
||||
|
||||
---
|
||||
|
||||
### 8. Не раздувать сервисную архитектуру раньше времени
|
||||
|
||||
Запрещено добавлять отдельные сервисы, если задачу можно решить проще.
|
||||
|
||||
Не нужно сейчас:
|
||||
- выделять отдельные сервисы ради формального микросервисного вида;
|
||||
- дробить систему под будущий scale, которого ещё нет;
|
||||
- вводить сетевое взаимодействие между модулями, где достаточно модульной декомпозиции в кодовой базе;
|
||||
- строить платформенный контур сложнее, чем требует текущий этап.
|
||||
|
||||
---
|
||||
|
||||
### 9. Не вводить storage complexity без ясной причины
|
||||
|
||||
Разрешено вводить новые contracts и storage-слои только если понятно:
|
||||
|
||||
- что является source of truth;
|
||||
- что хранится как runtime state;
|
||||
- что хранится как derived artifacts;
|
||||
- как обеспечивается совместимость;
|
||||
- как это будет использоваться уже сейчас.
|
||||
|
||||
Недопустимо:
|
||||
- размазывать состояние по случайным местам;
|
||||
- хранить критичное состояние в ad hoc формате;
|
||||
- смешивать runtime state, long-term artifacts и временные вспомогательные данные без явной дисциплины.
|
||||
|
||||
---
|
||||
|
||||
### 10. Не считать green tests доказательством качества продукта
|
||||
|
||||
Если изменения прошли технические тесты, это ещё не означает, что этап закрыт.
|
||||
|
||||
Архитектурно недостаточно:
|
||||
- unit tests без проверки полезности ответа;
|
||||
- integration tests без accountant-facing criteria;
|
||||
- успешного пайплайна без оценки качества narrowing/evidence/usefulness.
|
||||
|
||||
---
|
||||
|
||||
## Разрешённые архитектурные паттерны
|
||||
|
||||
Ниже перечислено то, что допустимо и желательно.
|
||||
|
||||
### 1. Минимальный совместимый контракт
|
||||
Если нужен новый слой, сначала вводится:
|
||||
- минимальный тип;
|
||||
- минимальный контракт;
|
||||
- минимальный runtime-путь;
|
||||
- без избыточной генерализации.
|
||||
|
||||
### 2. Локальное усиление точки принятия решения
|
||||
Если есть конкретная слабая зона, допустимо:
|
||||
- локально усилить её;
|
||||
- формализовать решение;
|
||||
- добавить проверку/метрику;
|
||||
- не затрагивать весь контур.
|
||||
|
||||
### 3. Расширение через bounded сущности
|
||||
Новые сущности допустимы, если они:
|
||||
- ограничены по назначению;
|
||||
- не претендуют на роль будущей полноразмерной подсистемы;
|
||||
- не конфликтуют с дальнейшим развитием.
|
||||
|
||||
### 4. Явные интерфейсы вместо неявного поведения
|
||||
Если логика уже существует, но живёт неявно, допустимо:
|
||||
- вывести её в контракт;
|
||||
- типизировать;
|
||||
- сделать наблюдаемой;
|
||||
- покрыть тестами.
|
||||
|
||||
### 5. Наблюдаемость как часть архитектуры
|
||||
Если появляется новая логика, у неё должны быть:
|
||||
- диагностика;
|
||||
- traceability;
|
||||
- метрики;
|
||||
- понятная точка проверки.
|
||||
|
||||
---
|
||||
|
||||
## Decision rules перед любым изменением
|
||||
|
||||
Перед внесением любого изменения нужно проверить следующее.
|
||||
|
||||
### Вопрос 1
|
||||
Это закрывает конкретный gap текущего этапа?
|
||||
|
||||
Если нет — изменение отклоняется.
|
||||
|
||||
### Вопрос 2
|
||||
Это можно сделать локальнее?
|
||||
|
||||
Если да — выбирается более локальный вариант.
|
||||
|
||||
### Вопрос 3
|
||||
Это не тянет Stage 2–6 раньше времени?
|
||||
|
||||
Если тянет — изменение откладывается или упрощается.
|
||||
|
||||
### Вопрос 4
|
||||
Это даёт прямую runtime-пользу уже сейчас?
|
||||
|
||||
Если нет — изменение подозрительно.
|
||||
|
||||
### Вопрос 5
|
||||
Это не создаёт новый трудный долг?
|
||||
|
||||
Если создаёт — нужен другой вариант.
|
||||
|
||||
### Вопрос 6
|
||||
Это не решает проблему только косметикой?
|
||||
|
||||
Если решает только косметикой — изменение недостаточно.
|
||||
|
||||
---
|
||||
|
||||
## Проверка на scope drift
|
||||
|
||||
Признаки того, что реализация вышла за рамки:
|
||||
|
||||
- в код попали сущности, которые фактически образуют graph runtime;
|
||||
- появилась логика сложного branching investigation;
|
||||
- появился mode router для нескольких продуктовых режимов;
|
||||
- появилась зависимость от live verification core;
|
||||
- ради текущего этапа меняется половина репозитория;
|
||||
- вводятся сущности, которые пока никто не использует;
|
||||
- строится общий orchestration framework вместо локального усиления;
|
||||
- Codex объясняет сложность тем, что “так будет лучше на будущее”.
|
||||
|
||||
Если наблюдается один или несколько признаков — нужно остановить изменения и сократить scope.
|
||||
|
||||
---
|
||||
|
||||
## Красные флаги
|
||||
|
||||
Следующие ситуации считаются тревожными:
|
||||
|
||||
1. Предлагается переписать base loop
|
||||
2. Предлагается “сразу сделать правильно всю архитектуру”
|
||||
3. Предлагается отдельный graph layer уже сейчас
|
||||
4. Предлагается большой orchestration framework
|
||||
5. Предлагается product split runtime уже на первом этапе
|
||||
6. State остаётся неявным, но промпт становится длиннее
|
||||
7. Evidence описывается красивее, но не структурируется
|
||||
8. Метрики остаются только техническими
|
||||
9. Добавляются новые сервисы без реальной необходимости
|
||||
10. Временное решение подаётся как target architecture
|
||||
|
||||
---
|
||||
|
||||
## Правило minimal irreversible change
|
||||
|
||||
Любое изменение должно быть по возможности:
|
||||
|
||||
- минимальным;
|
||||
- обратимым;
|
||||
- наблюдаемым;
|
||||
- проверяемым;
|
||||
- совместимым с дальнейшими этапами.
|
||||
|
||||
Нельзя делать решение, которое:
|
||||
- сложно откатить;
|
||||
- сложно объяснить;
|
||||
- сложно протестировать;
|
||||
- сложно встроить в дальнейшую архитектуру;
|
||||
- принято только потому, что “быстрее сейчас”.
|
||||
|
||||
---
|
||||
|
||||
## Правило explicit source of truth
|
||||
|
||||
Для каждой новой сущности должно быть явно определено:
|
||||
|
||||
- где находится источник истины;
|
||||
- кто её обновляет;
|
||||
- кто её читает;
|
||||
- как она версионируется;
|
||||
- что является derived form, а что canonical form.
|
||||
|
||||
Если это не определено, сущность не готова к внедрению.
|
||||
|
||||
---
|
||||
|
||||
## Правило bounded state
|
||||
|
||||
Любой новый state должен быть:
|
||||
|
||||
- ограниченным по объёму;
|
||||
- ограниченным по назначению;
|
||||
- независимым от случайного текстового контекста;
|
||||
- пригодным для диагностики;
|
||||
- пригодным для расширения в будущих этапах.
|
||||
|
||||
Нельзя вводить state, который:
|
||||
- хранит всё подряд;
|
||||
- не имеет чётких полей;
|
||||
- зависит от неявных текстовых интерпретаций;
|
||||
- фактически дублирует chat history;
|
||||
- не имеет правил обновления.
|
||||
|
||||
---
|
||||
|
||||
## Правило honest uncertainty
|
||||
|
||||
Система не должна производить архитектурно ложную определённость.
|
||||
|
||||
Если данных недостаточно, допустимо и желательно:
|
||||
- явно показать ограниченность;
|
||||
- указать, чего не хватает;
|
||||
- предложить следующий полезный шаг;
|
||||
- удержаться от псевдоточного ответа.
|
||||
|
||||
Запрещено:
|
||||
- маскировать отсутствие опоры уверенным тоном;
|
||||
- расширять answer prose вместо усиления основания;
|
||||
- выдавать общую формулировку как точный вывод.
|
||||
|
||||
---
|
||||
|
||||
## Правило compatibility without premature implementation
|
||||
|
||||
Система должна быть совместима с будущими этапами, но не должна их реализовывать заранее.
|
||||
|
||||
Допустимо:
|
||||
- закладывать совместимые поля;
|
||||
- делать совместимые интерфейсы;
|
||||
- избегать тупиковых решений;
|
||||
- оставлять расширяемые точки.
|
||||
|
||||
Недопустимо:
|
||||
- включать полный будущий runtime;
|
||||
- строить будущий слой целиком;
|
||||
- обосновывать сложность только будущими гипотетическими выгодами.
|
||||
|
||||
---
|
||||
|
||||
## Как должен выглядеть хороший change proposal
|
||||
|
||||
Хорошее предложение по изменению должно содержать:
|
||||
|
||||
1. Какой конкретный gap закрывается
|
||||
2. Почему это относится к текущему этапу
|
||||
3. Какой минимальный вариант реализации выбран
|
||||
4. Какие файлы затрагиваются
|
||||
5. Какие сущности добавляются
|
||||
6. Почему это не является скрытой реализацией будущего этапа
|
||||
7. Как это тестируется
|
||||
8. Как это наблюдается
|
||||
9. Что сознательно не делается сейчас
|
||||
|
||||
Если хотя бы половина этих пунктов отсутствует, proposal недостаточно дисциплинирован.
|
||||
|
||||
---
|
||||
|
||||
## Как должен выглядеть плохой change proposal
|
||||
|
||||
Плохим считается предложение, если в нём есть формулировки типа:
|
||||
|
||||
- “сразу сделаем правильно на будущее”
|
||||
- “заодно перепишем”
|
||||
- “проще построить новый слой”
|
||||
- “пусть пока будет так, потом переделаем”
|
||||
- “можно промптом компенсировать”
|
||||
- “сделаем универсальную архитектуру”
|
||||
- “вдруг потом пригодится”
|
||||
- “это подготовка к следующим этапам”
|
||||
|
||||
Без доказанной текущей пользы такие аргументы не принимаются.
|
||||
|
||||
---
|
||||
|
||||
## Эскалация при спорном решении
|
||||
|
||||
Если изменение спорное, применять следующий порядок:
|
||||
|
||||
1. Проверить соответствие текущему scope
|
||||
2. Проверить соответствие platform core ТЗ
|
||||
3. Проверить, не тянет ли изменение Stage 2–6
|
||||
4. Проверить, можно ли сделать локальнее
|
||||
5. Зафиксировать риски
|
||||
6. Только после этого принимать решение
|
||||
|
||||
Если спор остаётся, решение не внедряется автоматически.
|
||||
|
||||
---
|
||||
|
||||
## Короткая практическая формула
|
||||
|
||||
### Что делать
|
||||
- усиливать основание;
|
||||
- формализовать неявное;
|
||||
- добавлять минимально нужные контракты;
|
||||
- повышать наблюдаемость;
|
||||
- сохранять совместимость с будущим.
|
||||
|
||||
### Что не делать
|
||||
- строить будущее раньше времени;
|
||||
- переписывать рабочее;
|
||||
- лечить архитектуру текстом;
|
||||
- плодить абстракции;
|
||||
- усложнять платформу без необходимости.
|
||||
|
||||
---
|
||||
|
||||
## Финальная установка
|
||||
|
||||
Архитектурная дисциплина в этом проекте важнее скорости декоративных изменений.
|
||||
|
||||
Главная цель текущего этапа:
|
||||
|
||||
**не сделать видимость зрелой системы, а реально уменьшить structural debt и подготовить прочную основу для следующих шагов.**
|
||||
|
||||
Любое изменение, которое противоречит этому принципу, должно считаться ошибочным, даже если оно выглядит “умным”, “масштабируемым” или “красивым”.
|
||||
@@ -0,0 +1,414 @@
|
||||
CODEX_MASTER_BRIEF.md
|
||||
|
||||
# CODEX_MASTER_BRIEF
|
||||
|
||||
## Назначение документа
|
||||
|
||||
Этот документ задаёт режим работы Codex по проекту бухгалтерского ассистента.
|
||||
Документ не заменяет технические задания по этапам и не заменяет platform core ТЗ.
|
||||
Его задача — зафиксировать:
|
||||
|
||||
- текущий рабочий scope;
|
||||
- иерархию документов;
|
||||
- архитектурные ограничения;
|
||||
- допустимый порядок работы;
|
||||
- требования к формату результата;
|
||||
- правила, предотвращающие преждевременное усложнение и появление костылей.
|
||||
|
||||
---
|
||||
|
||||
## Статус документа
|
||||
|
||||
- Статус: основной управляющий бриф для Codex
|
||||
- Язык: русский
|
||||
- Режим использования: обязателен к прочтению перед любыми изменениями в коде
|
||||
- При конфликте с рабочим scope текущей итерации приоритет имеет `STAGE_01_TASK_CARD.md`
|
||||
- При конфликте по архитектурным ограничениям приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
|
||||
---
|
||||
|
||||
## Контекст проекта
|
||||
|
||||
Разрабатывается бухгалтерский ассистент, который уже находится в рабочем состоянии на уровне функционального MVP+ и способен:
|
||||
|
||||
- принимать пользовательские вопросы;
|
||||
- обращаться к имеющимся контурам данных;
|
||||
- маршрутизировать запрос;
|
||||
- извлекать данные;
|
||||
- формировать объяснение;
|
||||
- возвращать ответ пользователю.
|
||||
|
||||
При этом текущая система ещё не является полноценным investigation copilot.
|
||||
Основные текущие ограничения:
|
||||
|
||||
- snapshot-only truth contour;
|
||||
- слабая формализация investigation state;
|
||||
- entity-heavy retrieval;
|
||||
- недостаточная структурность evidence;
|
||||
- неполный accountant-facing eval;
|
||||
- ограниченная управляемость broad / generic query handling;
|
||||
- отсутствие полноценного bounded investigation runtime;
|
||||
- отсутствие formal live verification trust model.
|
||||
|
||||
Проект развивается по поэтапной схеме.
|
||||
На текущей итерации реализуется только **Stage 1 / Foundation Hardening**.
|
||||
Этапы 2–6 задают forward-compatibility constraints, но не являются scope текущей реализации.
|
||||
|
||||
---
|
||||
|
||||
## Цель работы Codex на текущей итерации
|
||||
|
||||
Codex должен помочь реализовать **только Stage 1**, не разрушая текущий работающий контур и не подтягивая prematurely решения из следующих этапов.
|
||||
|
||||
Текущая цель:
|
||||
|
||||
- усилить существующий assistant mode;
|
||||
- сделать архитектурно корректную базу для следующих этапов;
|
||||
- убрать наиболее опасные structural gaps;
|
||||
- не превращать текущий этап в скрытую реализацию Stage 2–6.
|
||||
|
||||
---
|
||||
|
||||
## Иерархия документов
|
||||
|
||||
При чтении и интерпретации материалов использовать следующий порядок приоритета.
|
||||
|
||||
### 1. Текущий рабочий scope
|
||||
- `03_execution/STAGE_01_TASK_CARD.md`
|
||||
|
||||
Это главный документ по тому, что делать прямо сейчас.
|
||||
|
||||
### 2. Архитектурные ограничения и platform core
|
||||
- `01_platform/TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
|
||||
Этот документ задаёт целевую платформенную рамку:
|
||||
- storage;
|
||||
- orchestration;
|
||||
- trust/provenance;
|
||||
- observability;
|
||||
- migration discipline;
|
||||
- security;
|
||||
- live bridge policy.
|
||||
|
||||
### 3. Детальное ТЗ первого этапа
|
||||
- `02_stages/stage-01-foundation-hardening.md`
|
||||
|
||||
Этот документ определяет содержимое Stage 1.
|
||||
|
||||
### 4. Текущий статус и общая логика развития
|
||||
- `00_context/Assistant_Mode_GLOBAL_STATUS_2026-03-24.md`
|
||||
- `00_context/Assistant_Mode_GLOBAL_STATUS_Appendix_2026-03-24.md`
|
||||
- `00_context/ROADMAP_endToReal.md`
|
||||
- `00_context/accounting_assistant_architecture_roadmap.xlsx`
|
||||
|
||||
Эти документы нужны для понимания:
|
||||
- что уже сделано;
|
||||
- где реальные потолки системы;
|
||||
- почему Stage 1 выполняется именно сейчас;
|
||||
- как Stage 1 стыкуется с дальнейшими этапами.
|
||||
|
||||
### 5. Этапы 2–6
|
||||
- `02_stages/stage-02-...`
|
||||
- `02_stages/stage-03-...`
|
||||
- `02_stages/stage-04-...`
|
||||
- `02_stages/stage-05-...`
|
||||
- `02_stages/stage-06-...`
|
||||
|
||||
Эти документы используются только как:
|
||||
- ограничители будущей совместимости;
|
||||
- источник требований к тому, чего нельзя ломать сейчас;
|
||||
- ориентир для проектирования расширяемых contracts и сущностей.
|
||||
|
||||
Эти документы **не являются** scope текущей реализации.
|
||||
|
||||
---
|
||||
|
||||
## Scope текущей итерации
|
||||
|
||||
Разрешено делать только то, что относится к Stage 1 и необходимо для его корректной реализации.
|
||||
|
||||
К текущему scope относятся:
|
||||
|
||||
- усиление foundation layer без переписывания всей системы;
|
||||
- минимально необходимая формализация `investigation_state`;
|
||||
- усиление answer policy;
|
||||
- усиление broad-query / generic-query handling;
|
||||
- более структурное представление evidence;
|
||||
- accountant-facing metrics;
|
||||
- baseline benchmark/eval harness;
|
||||
- подготовка базы для следующих этапов без преждевременной реализации этих этапов.
|
||||
|
||||
---
|
||||
|
||||
## Что сейчас не является scope
|
||||
|
||||
На этой итерации нельзя фактически реализовывать как core-runtime следующие слои:
|
||||
|
||||
- полноценный problem unit architecture из Stage 2;
|
||||
- полноценный lifecycle engine из Stage 3;
|
||||
- полноразмерный ontology / graph runtime из Stage 4;
|
||||
- investigation engine в полном виде из Stage 5;
|
||||
- live verification runtime core и full product mode split из Stage 6;
|
||||
- переезд на новую полную сервисную архитектуру;
|
||||
- переписывание ассистента вокруг новых abstraction layers без крайней необходимости;
|
||||
- большие инфраструктурные переделки ради “красоты”.
|
||||
|
||||
---
|
||||
|
||||
## Главный принцип текущей работы
|
||||
|
||||
**Не строить целевую систему раньше времени.**
|
||||
Нужно не “сразу сделать правильно всё”, а “сделать Stage 1 так, чтобы он был структурно корректен, совместим с будущими этапами и не создал новые архитектурные долги”.
|
||||
|
||||
---
|
||||
|
||||
## Жёсткие архитектурные ограничения
|
||||
|
||||
### 1. Нельзя ломать текущий рабочий контур без прямой причины
|
||||
Если существующий transport / endpoint / base routing / normalizer pipeline работает, он должен сохраняться, если только изменение не является обязательным условием Stage 1.
|
||||
|
||||
### 2. Нельзя подменять архитектурные изменения промптами
|
||||
Проблемы state, evidence structure, eval, traceability, narrowing и boundedness не должны решаться только промптами или “умной формулировкой ответа”.
|
||||
|
||||
### 3. Нельзя преждевременно тащить Stage 2–6 в кодовую базу
|
||||
Если какое-либо изменение фактически реализует future-stage runtime, оно должно быть отклонено или отложено, если не доказана его необходимость для Stage 1.
|
||||
|
||||
### 4. Нельзя делать большие рефакторы ради абстрактной чистоты
|
||||
Разрешены только те изменения, которые:
|
||||
- закрывают конкретный gap;
|
||||
- повышают устойчивость текущего слоя;
|
||||
- не разрушают траекторию дальнейшего развития.
|
||||
|
||||
### 5. Все новые сущности должны быть future-compatible
|
||||
Любые новые:
|
||||
- типы,
|
||||
- storage contracts,
|
||||
- runtime state contracts,
|
||||
- evidence models,
|
||||
- metric payloads,
|
||||
- trace structures
|
||||
|
||||
должны проектироваться так, чтобы не конфликтовать со следующими этапами.
|
||||
|
||||
### 6. Нельзя маскировать structural gaps perceived-quality улучшениями
|
||||
Недопустимо заменять структурное решение:
|
||||
- более длинным ответом,
|
||||
- более “умным” summarization,
|
||||
- более агрессивной промптовой маршрутизацией,
|
||||
- косметическим улучшением вывода.
|
||||
|
||||
---
|
||||
|
||||
## Порядок работы Codex
|
||||
|
||||
Работа должна идти строго по шагам.
|
||||
|
||||
### Шаг A. Изучение материалов
|
||||
Сначала изучить:
|
||||
- текущий статус;
|
||||
- platform core ТЗ;
|
||||
- Stage 1;
|
||||
- roadmap;
|
||||
- контекст следующих этапов.
|
||||
|
||||
### Шаг B. Анализ текущего кода
|
||||
До внесения изменений определить:
|
||||
- какие части системы уже существуют;
|
||||
- какие из требований Stage 1 уже частично реализованы;
|
||||
- где находятся реальные точки расширения;
|
||||
- какие элементы являются хрупкими;
|
||||
- какие изменения потребуют новых contracts;
|
||||
- какие части лучше не трогать.
|
||||
|
||||
### Шаг C. Подготовка implementation plan
|
||||
До написания кода выдать план:
|
||||
- что меняется;
|
||||
- зачем меняется;
|
||||
- какие файлы будут затронуты;
|
||||
- какие новые сущности появятся;
|
||||
- какие тесты будут добавлены;
|
||||
- что не будет делаться сейчас.
|
||||
|
||||
### Шаг D. Согласованная поэтапная реализация
|
||||
Только после плана переходить к реализации.
|
||||
|
||||
Изменения должны вноситься малыми порциями, чтобы можно было проверить:
|
||||
- не вышел ли scope за Stage 1;
|
||||
- не сломан ли текущий контур;
|
||||
- не появились ли premature abstractions.
|
||||
|
||||
### Шаг E. Проверка и фиксация результата
|
||||
После каждой завершённой волны изменений предоставить:
|
||||
- summary изменений;
|
||||
- список изменённых файлов;
|
||||
- тестовый результат;
|
||||
- список ограничений;
|
||||
- список нерешённых вопросов;
|
||||
- оценку совместимости с дальнейшими этапами.
|
||||
|
||||
---
|
||||
|
||||
## Первый результат, который Codex должен вернуть до любого кода
|
||||
|
||||
До любых patch / refactor / implementation действий Codex должен вернуть документированный анализ следующего вида:
|
||||
|
||||
### 1. Summary текущего состояния
|
||||
Краткое описание того, как текущая реализация устроена по коду.
|
||||
|
||||
### 2. Gap analysis относительно Stage 1
|
||||
Перечень того, чего не хватает для соответствия Stage 1.
|
||||
|
||||
### 3. Предлагаемый file-level plan
|
||||
Какие файлы нужно менять, создавать или расширять.
|
||||
|
||||
### 4. Предлагаемые contracts / types / schemas
|
||||
Какие сущности и интерфейсы появятся.
|
||||
|
||||
### 5. Test plan
|
||||
Какие тесты будут добавлены или обновлены.
|
||||
|
||||
### 6. Acceptance mapping
|
||||
Какие критерии Stage 1 покрываются какими изменениями.
|
||||
|
||||
### 7. Explicit non-scope
|
||||
Что сознательно не будет делаться сейчас.
|
||||
|
||||
---
|
||||
|
||||
## Требования к формату всех ответов Codex
|
||||
|
||||
Каждый содержательный ответ Codex должен быть структурирован.
|
||||
|
||||
Обязательная структура:
|
||||
|
||||
1. Что было проанализировано
|
||||
2. Что обнаружено
|
||||
3. Что предлагается изменить
|
||||
4. Почему это соответствует Stage 1
|
||||
5. Что не входит в текущий scope
|
||||
6. Какие файлы затрагиваются
|
||||
7. Какие риски есть
|
||||
8. Какие тесты или проверки нужны
|
||||
|
||||
Если предлагается кодовое изменение, дополнительно обязательно указывать:
|
||||
|
||||
- это локальное изменение или системное;
|
||||
- ломает ли оно обратную совместимость;
|
||||
- требует ли миграции;
|
||||
- влияет ли на transport / routing / state / answer composition;
|
||||
- как это соотносится с будущими этапами.
|
||||
|
||||
---
|
||||
|
||||
## Правила реализации
|
||||
|
||||
### 1. Минимальность изменения
|
||||
Предпочтительны минимальные архитектурно корректные изменения вместо больших переписываний.
|
||||
|
||||
### 2. Явные contracts
|
||||
Всё, что касается:
|
||||
- state,
|
||||
- evidence,
|
||||
- traceability,
|
||||
- metrics,
|
||||
- runtime decisions
|
||||
|
||||
должно оформляться через явные контракты, а не “как получится по месту”.
|
||||
|
||||
### 3. Контролируемая расширяемость
|
||||
Расширяемость допустима, но только в той мере, в которой она:
|
||||
- реально нужна Stage 1;
|
||||
- не заставляет внедрять всю будущую архитектуру заранее.
|
||||
|
||||
### 4. Наблюдаемость изменений
|
||||
Если добавляется новая логика, нужно продумать:
|
||||
- как она тестируется;
|
||||
- как она логируется;
|
||||
- как проверяется её корректность;
|
||||
- как она диагностируется в случае сбоя.
|
||||
|
||||
### 5. Миграционная дисциплина
|
||||
Если изменение создаёт новый контракт или структуру хранения, нужно явно указать:
|
||||
- где источник истины;
|
||||
- как происходит инициализация;
|
||||
- как будет обеспечена совместимость;
|
||||
- требуется ли миграция данных.
|
||||
|
||||
---
|
||||
|
||||
## Запрещённые анти-паттерны
|
||||
|
||||
Следующие действия считаются ошибочными:
|
||||
|
||||
- попытка “сразу построить конечную архитектуру”;
|
||||
- внедрение лишних сервисов без необходимости;
|
||||
- скрытая реализация future-stage логики под видом Stage 1;
|
||||
- замена structural fixes косметикой;
|
||||
- создание новых абстракций без runtime-пользы;
|
||||
- переписывание рабочего контура ради абстрактной чистоты;
|
||||
- смешивание temporary workaround и target architecture без явной маркировки;
|
||||
- неявное изменение scope;
|
||||
- неконтролируемая генерация “умных” helper layers;
|
||||
- перенос ответственности за структурный пробел в prompt layer.
|
||||
|
||||
---
|
||||
|
||||
## Признаки того, что решение идёт не туда
|
||||
|
||||
Если в процессе работы появляется одно или несколько из следующих явлений, нужно остановиться и пересобрать plan:
|
||||
|
||||
- предлагается большой platform refactor для реализации Stage 1;
|
||||
- предлагается новая архитектура вместо усиления текущей;
|
||||
- в код начинают подтягиваться сущности из Stages 4–6 как обязательные;
|
||||
- вводятся новые сервисы, не дающие прямой пользы на текущем шаге;
|
||||
- “для удобства” переписывается base loop;
|
||||
- проблема объясняется как решаемая чисто промптом;
|
||||
- предлагается сложный orchestrator без прямой необходимости;
|
||||
- формируется новый data model слой без связи с acceptance criteria Stage 1.
|
||||
|
||||
---
|
||||
|
||||
## Definition of Done для текущей волны
|
||||
|
||||
Текущая волна считается завершённой только если выполнены одновременно все условия:
|
||||
|
||||
1. Реализован scope Stage 1, а не произвольный “улучшенный вариант”.
|
||||
2. Текущий рабочий контур не разрушен.
|
||||
3. Новые state / evidence / metrics contracts описаны явно.
|
||||
4. Есть тесты и/или проверяемые критерии для внесённых изменений.
|
||||
5. Нет скрытого уезда в Stage 2–6.
|
||||
6. Изменения совместимы с platform core ТЗ.
|
||||
7. Зафиксировано, что сознательно осталось за пределами текущего этапа.
|
||||
|
||||
---
|
||||
|
||||
## Практическая цель первой итерации
|
||||
|
||||
Первая итерация должна дать не “идеальную новую систему”, а следующий результат:
|
||||
|
||||
- структурно усиленный assistant mode;
|
||||
- минимальную, но реальную формализацию foundation gaps;
|
||||
- снижение зависимости от неявной логики и ad hoc поведения;
|
||||
- более стабильную базу для перехода к следующим этапам.
|
||||
|
||||
---
|
||||
|
||||
## Финальная установка для Codex
|
||||
|
||||
Работать нужно в режиме **supervised implementation**.
|
||||
|
||||
Это означает:
|
||||
|
||||
- сначала анализ;
|
||||
- потом план;
|
||||
- потом небольшие контролируемые изменения;
|
||||
- после каждого куска — отчёт о том, что сделано и что осталось;
|
||||
- никакой самовольной замены roadmap;
|
||||
- никакого расширения scope;
|
||||
- никакой premature architecture.
|
||||
|
||||
Главный вопрос перед любым изменением:
|
||||
|
||||
**Это действительно необходимо для Stage 1, или это попытка преждевременно реализовать следующий этап?**
|
||||
|
||||
Если ответ неочевиден, изменение откладывается и выносится на отдельное согласование.
|
||||
@@ -0,0 +1,524 @@
|
||||
STAGE_01_TASK_CARD.md
|
||||
|
||||
# STAGE_01_TASK_CARD
|
||||
|
||||
## Назначение документа
|
||||
|
||||
Этот документ фиксирует **рабочий scope первой итерации реализации** для Codex и разработчика.
|
||||
Документ не заменяет Stage 1 ТЗ и не заменяет platform core ТЗ.
|
||||
Его задача — перевести первый этап в **практический implementation scope**, который можно брать в работу без расползания в следующие этапы.
|
||||
|
||||
Документ должен использоваться как основной рабочий ориентир при реализации первой волны изменений.
|
||||
|
||||
---
|
||||
|
||||
## Статус документа
|
||||
|
||||
- Статус: рабочая карта реализации Stage 1
|
||||
- Язык: русский
|
||||
- Режим использования: обязателен к прочтению перед любыми изменениями по Stage 1
|
||||
- При конфликте по архитектурным ограничениям приоритет имеет `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
- При конфликте по общему режиму работы Codex приоритет имеет `CODEX_MASTER_BRIEF.md`
|
||||
|
||||
---
|
||||
|
||||
## Контекст
|
||||
|
||||
Текущий бухгалтерский ассистент уже работает на уровне функционального MVP+:
|
||||
|
||||
- принимает вопросы пользователя;
|
||||
- обращается к доступным данным;
|
||||
- извлекает информацию;
|
||||
- формирует объяснение;
|
||||
- возвращает ответ.
|
||||
|
||||
При этом система ещё не является полноценным investigation copilot.
|
||||
На текущем этапе нужно **не перестроить ассистента целиком**, а **укрепить foundation layer**, чтобы:
|
||||
|
||||
- убрать самые опасные structural gaps;
|
||||
- сделать поведение более управляемым;
|
||||
- снизить зависимость от неявной логики;
|
||||
- подготовить совместимую базу для Stage 2–6;
|
||||
- не тащить prematurely будущую архитектуру в текущую реализацию.
|
||||
|
||||
---
|
||||
|
||||
## Цель Stage 1
|
||||
|
||||
Stage 1 должен дать **структурно усиленный assistant mode**, не ломая текущий рабочий контур.
|
||||
|
||||
Практический результат этапа:
|
||||
|
||||
- минимально формализованный `investigation_state`;
|
||||
- более управляемое поведение на broad / generic questions;
|
||||
- более структурное и объяснимое представление evidence;
|
||||
- accountant-facing метрики качества;
|
||||
- baseline benchmark/eval harness;
|
||||
- улучшение answer policy без ухода в prompt-only компенсацию;
|
||||
- база для следующих этапов без преждевременной реализации problem units / lifecycle / graph / investigation engine / live verification.
|
||||
|
||||
---
|
||||
|
||||
## Scope текущей реализации
|
||||
|
||||
В рамках Stage 1 разрешено реализовывать только то, что необходимо для foundation hardening.
|
||||
|
||||
### В scope входят
|
||||
|
||||
1. **Минимальная формализация investigation state**
|
||||
- базовый state-контур для многошагового взаимодействия;
|
||||
- фиксация контекста текущего вопроса и follow-up логики;
|
||||
- хранение минимально необходимого состояния для продолжающегося разбора;
|
||||
- отделение state от случайной chat-памяти.
|
||||
|
||||
2. **Усиление broad / generic query handling**
|
||||
- обнаружение слишком широких, размытых или недоопределённых запросов;
|
||||
- controlled narrowing;
|
||||
- управляемый переход от broad-вопроса к более точной постановке;
|
||||
- снижение generic explanation без опоры только на “умный текст”.
|
||||
|
||||
3. **Более структурное evidence-представление**
|
||||
- evidence должно быть не просто текстовым пересказом;
|
||||
- нужны явные поля/слоты под происхождение, тип опоры, степень уверенности, механизм/основание;
|
||||
- ответ не должен строиться на неявной сборке “по месту”.
|
||||
|
||||
4. **Усиление answer policy**
|
||||
- ответ должен быть полезным бухгалтеру;
|
||||
- должен быть более дисциплинированный формат объяснения;
|
||||
- должна снижаться доля общих и малооперабельных ответов;
|
||||
- при отсутствии достаточной опоры система должна это явно обозначать.
|
||||
|
||||
5. **Accountant-facing metrics**
|
||||
- нужны метрики не только технического прохождения пайплайна, но и полезности ответа для бухгалтерского сценария;
|
||||
- должна появиться измеримость качества на уровне пользовательского результата.
|
||||
|
||||
6. **Baseline benchmark / eval harness**
|
||||
- минимальный воспроизводимый контур проверки качества;
|
||||
- возможность сравнивать поведение до/после изменений;
|
||||
- возможность фиксировать деградации.
|
||||
|
||||
7. **Минимальные foundation-изменения в коде**
|
||||
- только те изменения, которые необходимы для реализации пунктов выше;
|
||||
- без большого переписывания существующей системы.
|
||||
|
||||
---
|
||||
|
||||
## Что не входит в scope
|
||||
|
||||
Следующие вещи **не должны** реализовываться в рамках Stage 1 как core-runtime или как полноценный новый слой.
|
||||
|
||||
### Не делать сейчас
|
||||
|
||||
- полный `problem unit architecture`;
|
||||
- полноценный lifecycle engine;
|
||||
- полноценный ontology / graph runtime;
|
||||
- full investigation engine;
|
||||
- live verification runtime core;
|
||||
- full product mode split (`direct / investigation / audit`);
|
||||
- новый большой orchestration layer;
|
||||
- радикальную смену transport / endpoint / base routing;
|
||||
- большой platform refactor;
|
||||
- сервисную декомпозицию ради будущего масштаба;
|
||||
- замену structural fixes косметическими prompt-улучшениями.
|
||||
|
||||
---
|
||||
|
||||
## Обязательные результаты этапа
|
||||
|
||||
По завершении Stage 1 в системе должны появиться следующие результаты.
|
||||
|
||||
### 1. Базовый investigation state
|
||||
Должен существовать минимальный, но явный state-контур, который:
|
||||
|
||||
- поддерживает follow-up вопросы;
|
||||
- позволяет не терять контекст разбора;
|
||||
- не сводится к “последнему сообщению в чате”;
|
||||
- не имитирует полноценный investigation engine;
|
||||
- не противоречит будущему расширению в Stage 5.
|
||||
|
||||
### 2. Controlled broad-query narrowing
|
||||
Система должна уметь:
|
||||
|
||||
- распознавать слишком общие вопросы;
|
||||
- не выдавать сразу слабый обобщённый ответ как будто вопрос уже достаточно определён;
|
||||
- либо сужать вопрос,
|
||||
- либо честно сигнализировать о недостатке точности,
|
||||
- либо предлагать следующий полезный шаг в рамках текущего контура.
|
||||
|
||||
### 3. Mechanism-aware evidence baseline
|
||||
В ответной логике должна появиться хотя бы базовая evidence-структура, включающая:
|
||||
|
||||
- источник / происхождение;
|
||||
- тип evidence;
|
||||
- основание ответа;
|
||||
- степень опоры / уверенности;
|
||||
- связь между утверждением и evidence.
|
||||
|
||||
### 4. Accountant-facing answer discipline
|
||||
Ответы должны стать более пригодными для прикладного использования бухгалтером:
|
||||
|
||||
- меньше generic prose;
|
||||
- больше предметной объяснимости;
|
||||
- больше локальной операбельности;
|
||||
- ясное разделение между найденным, предполагаемым и недостающим.
|
||||
|
||||
### 5. Метрики и eval
|
||||
Должен появиться baseline-контур, позволяющий измерять:
|
||||
|
||||
- качество narrowing;
|
||||
- качество evidence-linking;
|
||||
- долю generic answers;
|
||||
- долю structurally useful answers;
|
||||
- стабильность поведения на контрольном наборе вопросов.
|
||||
|
||||
---
|
||||
|
||||
## Рабочие deliverables от Codex
|
||||
|
||||
Codex должен вернуть не только код, но и набор артефактов.
|
||||
|
||||
### Обязательные deliverables
|
||||
|
||||
1. **Gap analysis по Stage 1**
|
||||
- чего не хватает в текущем коде;
|
||||
- что уже есть частично;
|
||||
- где точки внедрения.
|
||||
|
||||
2. **Implementation plan**
|
||||
- какие компоненты меняются;
|
||||
- какие файлы меняются;
|
||||
- какие сущности появляются;
|
||||
- что остаётся нетронутым.
|
||||
|
||||
3. **Новые или обновлённые contracts / types / schemas**
|
||||
- для state;
|
||||
- для evidence;
|
||||
- для answer policy;
|
||||
- для eval/metrics.
|
||||
|
||||
4. **Кодовые изменения**
|
||||
- малыми контролируемыми порциями;
|
||||
- без скрытого выезда в Stage 2–6.
|
||||
|
||||
5. **Test / eval changes**
|
||||
- unit / integration / regression checks;
|
||||
- baseline benchmark updates;
|
||||
- проверка, что Stage 1 реально усиливает foundation.
|
||||
|
||||
6. **Итоговый отчёт по волне**
|
||||
- что сделано;
|
||||
- что не сделано сознательно;
|
||||
- какие риски остались;
|
||||
- что готово для следующего этапа.
|
||||
|
||||
---
|
||||
|
||||
## Предпочтительные направления изменений в коде
|
||||
|
||||
Ниже перечислены типы изменений, которые допустимы и ожидаемы.
|
||||
|
||||
### 1. State layer
|
||||
Можно и нужно:
|
||||
- добавить минимальные state-типы;
|
||||
- добавить state storage contract;
|
||||
- добавить controlled state hydration / update;
|
||||
- ограничить state только тем, что реально нужно Stage 1.
|
||||
|
||||
Нельзя:
|
||||
- строить full investigation machine;
|
||||
- вводить сложный branching runtime;
|
||||
- реализовывать полноценные investigation cases.
|
||||
|
||||
### 2. Retrieval / interpretation boundary
|
||||
Можно и нужно:
|
||||
- усилить слой, где broad/generic вопрос распознаётся до финального ответа;
|
||||
- добавить явную логику narrowing;
|
||||
- отделить “данных недостаточно для узкого ответа” от “модель решила ответить общими словами”.
|
||||
|
||||
Нельзя:
|
||||
- заменять structural logic prompt tuning-only подходом;
|
||||
- внедрять problem unit runtime раньше Stage 2.
|
||||
|
||||
### 3. Evidence layer
|
||||
Можно и нужно:
|
||||
- сделать evidence более формализованным;
|
||||
- добавить типизацию evidence;
|
||||
- связать утверждение с основанием.
|
||||
|
||||
Нельзя:
|
||||
- строить полный ontology graph;
|
||||
- вводить тяжёлую графовую модель без реальной необходимости.
|
||||
|
||||
### 4. Answer composer / policy
|
||||
Можно и нужно:
|
||||
- дисциплинировать формат ответа;
|
||||
- сделать явные режимы ответа внутри Stage 1;
|
||||
- снизить долю размытых формулировок.
|
||||
|
||||
Нельзя:
|
||||
- строить full mode router уровня Stage 6;
|
||||
- подменять quality строгим шаблоном без связи с evidence.
|
||||
|
||||
### 5. Eval / metrics
|
||||
Можно и нужно:
|
||||
- добавить baseline метрики;
|
||||
- добавить контрольные наборы вопросов;
|
||||
- добавить сравнение до/после.
|
||||
|
||||
Нельзя:
|
||||
- ограничиться только техническими green tests;
|
||||
- считать этап завершённым без accountant-facing проверки.
|
||||
|
||||
---
|
||||
|
||||
## Ожидаемые сущности Stage 1
|
||||
|
||||
Ниже — не финальная схема данных, а минимальный набор сущностей, который допустимо и полезно ввести уже сейчас.
|
||||
|
||||
### 1. InvestigationState
|
||||
Минимальный runtime state текущего разбора.
|
||||
|
||||
Примерный состав:
|
||||
- `session_id`
|
||||
- `question_id`
|
||||
- `current_focus`
|
||||
- `narrowing_status`
|
||||
- `evidence_refs`
|
||||
- `open_uncertainties`
|
||||
- `last_answer_mode`
|
||||
- `followup_context`
|
||||
|
||||
Это не должен быть полноценный case-engine.
|
||||
|
||||
### 2. EvidenceItem
|
||||
Базовая единица evidence.
|
||||
|
||||
Примерный состав:
|
||||
- `evidence_id`
|
||||
- `source_type`
|
||||
- `source_ref`
|
||||
- `claim_ref`
|
||||
- `evidence_kind`
|
||||
- `mechanism_note`
|
||||
- `confidence`
|
||||
- `raw_excerpt_or_pointer`
|
||||
|
||||
### 3. AnswerStructure
|
||||
Формализованный каркас ответа.
|
||||
|
||||
Примерный состав:
|
||||
- `answer_summary`
|
||||
- `direct_answer`
|
||||
- `evidence_block`
|
||||
- `uncertainty_block`
|
||||
- `next_step_block`
|
||||
|
||||
### 4. EvalRecord
|
||||
Запись о результате проверки на benchmark / control set.
|
||||
|
||||
Примерный состав:
|
||||
- `case_id`
|
||||
- `question_type`
|
||||
- `broadness_level`
|
||||
- `narrowing_result`
|
||||
- `evidence_quality_score`
|
||||
- `genericness_score`
|
||||
- `accountant_usefulness_score`
|
||||
- `notes`
|
||||
|
||||
---
|
||||
|
||||
## Жёсткие implementation-ограничения
|
||||
|
||||
### 1. Не трогать без необходимости
|
||||
Без прямой нужды не переписывать:
|
||||
- transport layer;
|
||||
- endpoint layer;
|
||||
- base routing;
|
||||
- normalizer pipeline;
|
||||
- рабочий контур выдачи ответа.
|
||||
|
||||
### 2. Не внедрять будущие этапы скрыто
|
||||
Если предлагаемое изменение:
|
||||
- требует graph runtime,
|
||||
- требует lifecycle engine,
|
||||
- требует full investigation runtime,
|
||||
- требует live verification core,
|
||||
|
||||
то оно не относится к Stage 1 и должно быть отложено.
|
||||
|
||||
### 3. Не раздувать abstraction layer
|
||||
Если новая абстракция:
|
||||
- не даёт прямой пользы текущему этапу,
|
||||
- не закрывает конкретный gap,
|
||||
- добавляется “на будущее”,
|
||||
|
||||
она не должна внедряться.
|
||||
|
||||
### 4. Не подменять state чатом
|
||||
State должен быть формализован минимально, но явно.
|
||||
Нельзя считать, что “история переписки и так всё хранит”.
|
||||
|
||||
### 5. Не подменять evidence текстом
|
||||
Evidence должно быть хотя бы базово структурировано.
|
||||
Нельзя считать, что “если модель сослалась словами, этого достаточно”.
|
||||
|
||||
---
|
||||
|
||||
## Порядок работы по Stage 1
|
||||
|
||||
### Шаг 1. Прочитать материалы
|
||||
Обязательно прочитать:
|
||||
- `CODEX_MASTER_BRIEF.md`
|
||||
- `TZ_Platform_Core_Accounting_Assistant_Mode.md`
|
||||
- Stage 1 ТЗ
|
||||
- status documents
|
||||
- roadmap
|
||||
|
||||
### Шаг 2. Сделать code-level mapping
|
||||
Нужно определить:
|
||||
- где находится текущий assistant loop;
|
||||
- где принимается решение по типу вопроса;
|
||||
- где собирается evidence;
|
||||
- где формируется финальный ответ;
|
||||
- где можно безопасно внедрить state;
|
||||
- где можно подключить eval/metrics.
|
||||
|
||||
### Шаг 3. Подготовить plan без кода
|
||||
До начала реализации Codex должен выдать:
|
||||
- gap analysis;
|
||||
- file-level plan;
|
||||
- список новых контрактов;
|
||||
- список новых тестов;
|
||||
- список non-scope.
|
||||
|
||||
### Шаг 4. Реализовывать малыми волнами
|
||||
Рекомендуемая последовательность:
|
||||
|
||||
#### Волна 1
|
||||
- mapping текущего кода;
|
||||
- проектирование новых contracts;
|
||||
- проектирование state baseline.
|
||||
|
||||
#### Волна 2
|
||||
- внедрение minimal `investigation_state`;
|
||||
- базовое сохранение и использование state.
|
||||
|
||||
#### Волна 3
|
||||
- внедрение evidence-структуры;
|
||||
- обновление answer composer.
|
||||
|
||||
#### Волна 4
|
||||
- усиление broad/generic query handling;
|
||||
- controlled narrowing.
|
||||
|
||||
#### Волна 5
|
||||
- добавление accountant-facing metrics и baseline eval harness.
|
||||
|
||||
#### Волна 6
|
||||
- regression pass;
|
||||
- acceptance mapping;
|
||||
- cleanup только по необходимости.
|
||||
|
||||
---
|
||||
|
||||
## Acceptance criteria
|
||||
|
||||
Stage 1 считается закрытым только если выполнены все критерии ниже.
|
||||
|
||||
### A. Investigation state
|
||||
- существует явный минимальный state-контур;
|
||||
- он реально участвует в follow-up логике;
|
||||
- он не конфликтует с будущим расширением;
|
||||
- он не имитирует Stage 5.
|
||||
|
||||
### B. Broad-query behavior
|
||||
- broad/generic вопросы обрабатываются более дисциплинированно;
|
||||
- система не скатывается в пустые общие ответы;
|
||||
- narrowing либо выполняется, либо честно сигнализируется;
|
||||
- поведение стало более предсказуемым.
|
||||
|
||||
### C. Evidence structure
|
||||
- evidence имеет явную структуру;
|
||||
- связь между ответом и evidence стала лучше;
|
||||
- механизм/основание ответа отображается более прозрачно;
|
||||
- “ответ без опоры” не маскируется уверенностью.
|
||||
|
||||
### D. Answer quality
|
||||
- ответ стал более полезным для бухгалтерского сценария;
|
||||
- genericness снизилась;
|
||||
- uncertainty стала видимой и контролируемой;
|
||||
- улучшение не сводится только к косметике.
|
||||
|
||||
### E. Eval / metrics
|
||||
- существует baseline benchmark/eval harness;
|
||||
- есть набор контрольных кейсов;
|
||||
- можно сравнить поведение до/после;
|
||||
- accountant-facing метрики зафиксированы.
|
||||
|
||||
### F. Scope discipline
|
||||
- нет скрытого выезда в Stages 2–6;
|
||||
- нет большого platform refactor;
|
||||
- нет ненужной сервисной декомпозиции;
|
||||
- нет замены structural fixes промптами.
|
||||
|
||||
---
|
||||
|
||||
## Что Codex обязан явно указать в конце работы
|
||||
|
||||
В финальном отчёте по Stage 1 обязательно должны быть разделы:
|
||||
|
||||
1. Что было сделано
|
||||
2. Какие файлы изменены
|
||||
3. Какие новые сущности введены
|
||||
4. Какие тесты добавлены
|
||||
5. Какие acceptance criteria закрыты
|
||||
6. Что сознательно НЕ реализовано
|
||||
7. Какие риски и ограничения остались
|
||||
8. Что подготовлено для Stage 2
|
||||
|
||||
---
|
||||
|
||||
## Красные флаги
|
||||
|
||||
Если в ходе работы появляется одно из следующего, реализацию нужно остановить и пересобрать plan:
|
||||
|
||||
- Codex предлагает полный redesign ассистента;
|
||||
- появляется зависимость от graph layer;
|
||||
- появляется попытка строить investigation engine;
|
||||
- broad-query проблема решается только красивым текстом;
|
||||
- state превращается в неявную chat memory;
|
||||
- evidence остаётся текстовым пересказом без структуры;
|
||||
- метрики ограничиваются только техническими тестами;
|
||||
- ради Stage 1 предлагается большой рефактор transport/routing.
|
||||
|
||||
---
|
||||
|
||||
## Definition of Done
|
||||
|
||||
Stage 1 завершён, если одновременно соблюдены все условия:
|
||||
|
||||
- foundation layer реально усилен;
|
||||
- текущий рабочий контур не разрушен;
|
||||
- введён минимальный `investigation_state`;
|
||||
- broad/generic handling стал более управляемым;
|
||||
- evidence стало более структурным;
|
||||
- появились accountant-facing метрики;
|
||||
- есть baseline eval harness;
|
||||
- изменения совместимы с platform core;
|
||||
- нет premature implementation из следующих этапов.
|
||||
|
||||
---
|
||||
|
||||
## Короткая практическая формула этапа
|
||||
|
||||
**Stage 1 = не новая архитектура, а жёсткое усиление основания.**
|
||||
|
||||
Нужно получить не “почти готовый конечный продукт”, а:
|
||||
|
||||
- более дисциплинированный assistant mode;
|
||||
- более формализованный foundation layer;
|
||||
- меньше неявности;
|
||||
- меньше generic-ответов;
|
||||
- больше контролируемости;
|
||||
- больше готовности к Stage 2 и дальше.
|
||||
Reference in New Issue
Block a user