NODEDC_1C/IN/TZ_Assistant_Mode-GLOBAL-REPORT.md

TZ_Assistant_Mode-GLOBAL-REPORT.md

собери в папку "X:\1C\NDC_1C\docs\ARCH\6_global_report" отчетные данные по текущему статусу проекта 

Да, это правильный ход.

Сейчас вам уже мало смотреть на отдельные баги типа `executeHybrid` или на качество одного ответа. Нужна **единая архитектурная картина**, чтобы понять не “где подкрутить”, а **чего в системе в принципе не хватает**, чтобы она могла стать нормальным бухгалтерским ассистентом, а не набором частично работающих слоёв.

Ниже даю тебе именно **ёмкие критерии и структуру запроса на полный архитектурный отчёт**.
То есть это не “как улучшить конкретный кусок”, а **что надо запросить у команды / системы**, чтобы по итогам отчёта можно было принять нормальные решения.

---

# Что должен закрыть полный архитектурный отчёт

Отчёт должен отвечать не на вопрос
**“какие модули есть”**,
а на вопрос
**“почему система в текущем виде не всегда может дать осмысленный бухгалтерский ответ и что именно для этого не хватает”**.

Поэтому отчёт должен покрывать **9 контуров**:

1. **данные**
2. **онтология / модель предметной области**
3. **retrieval / query execution**
4. **LLM-слой и decomposition**
5. **answer synthesis / explanation**
6. **память / state / session continuity**
7. **orchestration / routing / control policy**
8. **качество / observability / eval**
9. **эволюционная архитектура — что можно наращивать дальше**

---

# 1. Контур данных: что реально доступно ассистенту

Здесь нужен не список таблиц, а ответ на вопрос:
**какой фактический объём бухгалтерской реальности видит система и в каком виде**.

Нужно запросить:

### 1.1. Источники данных

* какие именно данные приходят из 1С;
* какие каналы/срезы доступны;
* что получается live-запросом;
* что через снапшот;
* что кэшируется;
* что теряется при преобразовании.

### 1.2. Глубина данных

* видит ли система только документы;
* видит ли проводки;
* видит ли регистры;
* видит ли связи между документами;
* видит ли lifecycle объектов;
* видит ли статусы проведения, закрытия, списания, амортизации, зачета, вычета и т.д.

### 1.3. Полнота данных

* есть ли зоны, где ассистент видит только верхний слой сущностей, но не видит фактическую причинную механику;
* какие поля не доезжают;
* какие сущности представлены плоско;
* какие важные признаки отбрасываются.

### 1.4. Нормализация данных

* как 1С-данные преобразуются во внутреннюю модель;
* где происходит агрегирование;
* где исчезает детализация;
* где теряются связи;
* где всё схлопывается в “контрагент + документы + операции”.

### Главный критерий этого раздела:

**может ли система из текущих данных вообще построить причинное бухгалтерское объяснение, или на вход LLM уже попадает обеднённый полуфабрикат?**

---

# 2. Онтология / предметная модель

Это, возможно, вообще ключевой блок.

Нужен ответ на вопрос:
**в какой предметной модели система мыслит бухгалтерскую реальность — в модели плоских сущностей или в модели связанной бухгалтерской логики?**

Нужно запросить:

### 2.1. Набор базовых сущностей

* документ
* проводка
* движение регистра
* контрагент
* договор
* организация
* счет / субсчет
* объект ОС
* РБП
* номенклатура
* склад
* статья
* период
* регламентная операция
* закрытие
* налоговый объект
* и т.д.

### 2.2. Набор связей между сущностями

* документ → проводка
* документ → регистр
* платёж → расчёт
* ОС → амортизация
* РБП → график списания
* счёт-фактура → НДС
* закрытие периода → затрагиваемые остатки / хвосты
* договор → цепочка первички
* контрагент → серия проблем
* и т.д.

### 2.3. Lifecycle-модель

Это очень важно.

Нужно понять:
есть ли в системе формальная модель стадий жизни объекта?

Например:

* создан
* проведён
* не проведён
* частично связан
* закрыт
* не закрыт
* завис
* закрыт не тем документом
* перенесён
* сторнирован
* повторяется
* конфликтует с соседним контуром

Если этого нет, то ассистент почти неизбежно будет отвечать поверхностно.

### 2.4. Словарь аномалий и конфликтов

Нужно понять:
есть ли формальный словарь предметных дефектов, или всё пока описывается общими лейблами типа:

* broken lifecycle
* missing link
* posting mismatch

Нужно увидеть, есть ли **бухгалтерски интерпретируемые типы дефектов**:

* оплата есть, обязательство не закрылось;
* карточка ОС не согласована с начислениями;
* РБП живёт дольше ожидаемого срока;
* документ отражён, но не продолжен по цепочке;
* движение денег есть, документный контур не подтверждён;
* закрытие месяца зависит от хвоста;
* и т.д.

### Главный критерий раздела:

**есть ли у вас предметная модель, на которой вообще можно строить reasoning, или пока есть только data-access + тонкий semantic layer сверху?**

---

# 3. Retrieval / query execution

Это уже не про “видим данные”, а про “можем ли мы по вопросу вытащить нужный контекст”.

Нужно запросить:

### 3.1. Полный retrieval pipeline

* что делает normalizer;
* что делает decomposition;
* как строится semantic retrieval profile;
* какие executors существуют;
* как выбирается executor;
* какие фильтры реально исполняются;
* где fallback на широкий scan;
* где есть hard constraints, а где soft hints.

### 3.2. Глубина narrowing

По каждому типу запроса:

* насколько реально сужается массив;
* какие признаки обязательны;
* какие просто повышают score;
* как система защищается от “почти весь датасет”.

### 3.3. Единица retrieval-ответа

Очень важный вопрос.

Нужно выяснить:
retrieval возвращает в качестве top:

* контрагентов?
* документы?
* проводки?
* цепочки?
* problem clusters?
* risk groups?

Пока у вас по симптомам видно, что слишком часто top unit — это `контрагент`, а не `проблема`.

### 3.4. Evidence design

Какие доказательства retrieval возвращает наверх:

* ids и counts
* признаки
* связи
* missing links
* lifecycle gaps
* конфликтующие документы
* period impact
* cross-domain inconsistency

### Главный критерий раздела:

**способен ли retrieval вернуть не просто релевантные сущности, а релевантные причинные узлы, из которых можно собрать человеческое объяснение?**

---

# 4. LLM-слой и decomposition

Здесь нужен не “какая модель стоит”, а ответ на вопрос:
**что именно LLM делает в архитектуре и чего она сейчас не умеет делать из-за ограничений входа/контракта?**

Нужно запросить:

### 4.1. Функция LLM в системе

Разделить:

* интерпретация запроса;
* decomposition;
* routing;
* constraint extraction;
* result synthesis;
* explanation generation;
* follow-up policy;
* clarification policy.

### 4.2. Формат входа в LLM

Критично.

Нужно увидеть:

* что именно модель получает на вход;
* какие данные о вопросе;
* какие данные о контексте сессии;
* какие retrieval results;
* насколько они детальны;
* есть ли нормальная структура evidence;
* есть ли бизнес-интерпретация на входе или только raw items.

### 4.3. Потери на decomposition

Нужно понять:

* как измеряется полнота покрытия;
* где теряются части многосоставного вопроса;
* как различаются requirements и fragments;
* как работает clarification;
* как помечается uncovered intent.

### 4.4. Ограничения LLM

Нужно явно получить список:

* что модель не может infer-ить из текущего входа;
* какие объяснения она вынуждена делать шаблонно;
* в каких случаях она видит слишком мало данных;
* где она подменяет reasoning общими фразами.

### Главный критерий раздела:

**проблема в том, что модель “недостаточно умная”, или в том, что ей подают архитектурно бедный и плохо структурированный контекст?**

---

# 5. Answer synthesis / explanation layer

Это отдельный контур, и по вашим симптомам он сейчас один из самых слабых.

Нужно запросить:

### 5.1. Полный answer assembly pipeline

* как из retrieval result строится ответ;
* какие поля composer реально использует;
* что игнорирует;
* как выбирается top unit;
* как выбирается структура ответа.

### 5.2. Типы объяснений

Нужно понять, умеет ли система различать:

* direct factual answer;
* anomaly explanation;
* causal chain explanation;
* risk ranking explanation;
* period impact explanation;
* cross-entity inconsistency explanation.

### 5.3. Что именно делает ответ generic

Попросить прямо выделить:

* какие части explanation template переиспользуются почти без изменений;
* где нет case-specific wording;
* где не хватает данных для конкретизации;
* где composer всё ещё пишет “по совокупности факторов”.

### 5.4. Единица ответа

Очень критичный вопрос:
система отвечает через:

* объект?
* сущность?
* контрагента?
* цепочку?
* конфликт?
* механизм нарушения?

Нужно понять, **какая базовая единица ответа** сейчас используется и подходит ли она вообще для бухгалтерского ассистента.

### Главный критерий раздела:

**может ли текущий explanation layer собирать конкретный бухгалтерский вывод по кейсу, или он пока только красиво пересказывает retrieval labels?**

---

# 6. Память / state / session continuity

Если вы хотите действительно полезного ассистента, без этого дальше будет потолок.

Нужно запросить:

### 6.1. Что система помнит внутри сессии

* предыдущие вопросы;
* активный предмет разговора;
* выбранный период;
* выбранный счёт;
* текущую цепочку анализа;
* уже найденные проблемы;
* уже проверенные гипотезы.

### 6.2. Есть ли рабочая conversational state model

Например:

* current focus
* current accounting domain
* open hypotheses
* active entities
* unresolved questions
* current period
* comparison baseline

### 6.3. Может ли ассистент строить многоходовой анализ

Например:

* сначала нашли хвосты,
* потом сузили до причин,
* потом проверили влияние на закрытие периода,
* потом посмотрели соседний контур.

Если state model слабая, ассистент каждый раз будет начинать почти с нуля.

### Главный критерий раздела:

**это уже исследовательский ассистент с рабочим state, или пока stateless Q&A с небольшим контекстом последних сообщений?**

---

# 7. Orchestration / routing / control policy

Здесь надо понять, как система принимает решения о том, **что делать дальше**, а не только как отвечает.

Нужно запросить:

### 7.1. Политика выбора режима

Когда система:

* отвечает сразу;
* делает partial;
* просит уточнение;
* запускает дополнительный retrieval;
* анализирует соседние ветки;
* прекращает поиск.

### 7.2. Может ли система делать iterative reasoning

Например:

* гипотеза 1 → не подтвердилась;
* проверяем гипотезу 2;
* сравниваем два соседних контура;
* усиливаем evidence;
* перестраиваем ranking.

### 7.3. Может ли система сама инициировать дополнительный шаг

Не в смысле галлюцинировать, а в смысле:
“по текущим данным видно только банк, но без проверки расчётного контура вывод будет слабым — запускаем соседнюю проверку”.

### 7.4. Есть ли control policy поверх LLM

Или всё сейчас слишком жёстко route-driven.

### Главный критерий раздела:

**это линейный пайплайн или уже управляемый исследовательский контур?**

---

# 8. Качество / observability / eval

Нужно запросить не только логи, а систему оценки.

### 8.1. Как вы меряете качество

Отдельно:

* intent understanding;
* coverage completeness;
* retrieval precision;
* retrieval differentiation;
* grounding;
* explanation usefulness;
* accountant usefulness;
* false out_of_scope;
* false confidence;
* generic explanation rate.

### 8.2. Как вы меряете полезность именно для бухгалтера

Очень важно.

Нужны eval-критерии уровня:

* понятно ли, почему объект попал в ответ;
* понятно ли, что именно сломано;
* понятно ли, что делать дальше;
* не нужно ли открывать debug, чтобы понять суть.

### 8.3. Набор канонических сценариев

Нужно запросить список контрольных кейсов:

* 51 / банк / не в платеже проблема;
* 60 / хвосты / повторяемый контрагент;
* 97 / lifecycle anomaly;
* ОС / карточка vs начисления;
* НДС / соседний контур;
* период / влияние на закрытие;
* многосоставной запрос;
* транслит;
* follow-up внутри одной темы.

### Главный критерий раздела:

**вы меряете архитектуру по реально полезным сценариям или только по техническим индикаторам успешного pipeline?**

---

# 9. Эволюционная архитектура

Здесь нужен взгляд вперёд.

Нужно запросить:

### 9.1. Какие сущности или слои сейчас отсутствуют

Например:

* полноценная ontology graph layer;
* lifecycle engine;
* problem cluster layer;
* accountant-facing explanation schema;
* working memory / investigation state;
* hypothesis engine;
* cross-branch exploration policy;
* domain-specific anomaly catalog;
* semantic diff between similar queries.

### 9.2. Где текущая архитектура имеет потолок

Прямо попросить указать:

* что невозможно получить без изменения data model;
* что невозможно получить без изменения ontology;
* что невозможно получить без смены retrieval unit;
* что невозможно получить без нового state layer;
* что невозможно получить без multi-step orchestration.

### 9.3. Что является локальной доработкой, а что архитектурным шагом

Чтобы не лечить системную проблему очередной латкой.

### Главный критерий раздела:

**какие следующие изменения действительно приближают к конечной цели, а какие просто временно уменьшают боль?**

---

# В каком виде просить отчёт

Я бы просил не “свободный архитектурный рассказ”, а вот так:

## Формат ответа по каждому разделу:

1. **Как устроено сейчас**
2. **Что реально работает**
3. **Какие ограничения есть**
4. **Что из-за этого не может сделать ассистент**
5. **Какие симптомы это уже порождает в диалогах**
6. **Что нужно изменить локально**
7. **Что нужно изменить архитектурно**
8. **Приоритет: P0 / P1 / P2**

Это очень важно. Иначе тебе пришлют презентацию, а не диагностический отчёт.

---

# Самые важные вопросы, без которых отчёт будет бессмысленным

Если хочешь совсем сжато, то вот 12 ключевых вопросов, которые должны быть закрыты обязательно:

1. **Какие именно данные реально доезжают до ассистента из 1С, и где они теряют детализацию?**
2. **Есть ли у системы полноценная предметная модель бухгалтерских сущностей, связей и lifecycle?**
3. **Какая единица retrieval-результата считается основной: контрагент, документ, цепочка, проблема, кластер?**
4. **Какие constraints реально исполняет retrieval и где он расползается в слишком широкий scan?**
5. **Что именно LLM получает на вход перед финальным ответом?**
6. **Что теряется на decomposition и как измеряется полнота покрытия вопроса?**
7. **Почему explanation остаётся generic даже когда retrieval стал лучше?**
8. **Может ли система строить объяснение механизма проблемы, а не только перечислять признаки?**
9. **Есть ли рабочая state/memory model для многоходового бухгалтерского анализа?**
10. **Может ли система сама проверять соседние ветки, если это нужно для сильного вывода?**
11. **Как измеряется не техническая успешность, а реальная полезность ответа для бухгалтера?**
12. **Какие архитектурные сущности сейчас отсутствуют и без них потолок не пробить?**

---

# Что я подозреваю заранее, ещё до отчёта

С высокой вероятностью отчёт покажет одну или несколько таких проблем:

* данные до LLM доезжают уже **слишком обеднёнными**;
* retrieval возвращает **не ту единицу анализа**;
* ontology/lifecycle слой пока **слишком тонкий**;
* composer живёт на **generic explanation templates**;
* state/investigation memory почти нет;
* система всё ещё слишком **route-driven**, а не investigation-driven;
* нет отдельного слоя **problem clusters / causal nodes**;
* нет механизма **сравнения соседних веток учёта** как штатной операции.

Если это подтвердится, тогда уже можно будет не просто “улучшать ассистента”, а проектировать следующий архитектурный шаг нормально.

---

# Готовый текст запроса на отчёт

Ниже текст, который можно почти без правок отправить команде.

**Нужен полный архитектурный отчёт по текущей реализации бухгалтерского ассистента не в формате описания модулей, а в формате диагностической картины системы.
Отчёт должен показать, как устроены и где ограничены: data layer, ontology / lifecycle model, retrieval / execution, LLM decomposition, answer synthesis, state / memory, orchestration policy, observability / eval.
По каждому разделу нужно показать: как устроено сейчас, что реально работает, какие ограничения есть, что из-за этого ассистент не может сделать, какие симптомы уже видны в диалогах, какие нужны локальные изменения, какие нужны архитектурные изменения, и приоритет изменений P0/P1/P2.
Отдельно нужно ответить на ключевые вопросы: какие данные реально доезжают до LLM; где теряется детализация; есть ли полноценная модель сущностей, связей и lifecycle; какая единица retrieval используется как основная; что теряется на decomposition; почему explanation остаётся generic; есть ли state для многоходового анализа; может ли система исследовать соседние ветки учёта; какие архитектурные сущности отсутствуют и без них невозможно выйти на качественного ассистента.**

---

Если хочешь, я следующим сообщением сделаю из этого уже **сверхкороткий checklist на 1 экран**, чтобы ты просто кинул его как задачу на отчёт.