Initial import NDC_1C
This commit is contained in:
@@ -0,0 +1,589 @@
|
||||
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 экран**, чтобы ты просто кинул его как задачу на отчёт.
|
||||
Reference in New Issue
Block a user