590 lines
26 KiB
Markdown
590 lines
26 KiB
Markdown
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 экран**, чтобы ты просто кинул его как задачу на отчёт.
|