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