26 KiB

Raw Blame History

Да, давай сделаем следующий прогон уже не “на каноничных вопросиках”, а на более злой, предметной и местами провокационной выборке — ближе к тому, как человек реально разговаривает с бухгалтерским ассистентом. И да, архитектуру отчёта тоже сразу зафиксируем, чтобы на выходе был один читаемый MD-файл, который одновременно:

удобно читать человеку,
удобно парсить машине,
удобно сравнивать между прогонами. Опираюсь на выжимку из разговора с главбухом: ядро ценности — не ввод первички, а контроль, сверка, поиск расхождений, анализ счетов, предзакрытие периода и вопросно-ответный интерфейс поверх нормализованной модели 1С.

Что предлагаю сделать

Новый прогон собрать как Benchmark v2 / Creative Stress Run, где вопросы будут:

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

И на выходе генерировать один отчёт .md следующего типа:

Архитектура итогового отчёта

Имя файла

benchmark_creative_stress_run_accounting_assistant_YYYY-MM-DD.md

Структура файла

1. Паспорт прогона

Короткий верхний блок:

# Creative Stress Benchmark Run — Accounting Assistant

## Паспорт
- run_id: creative_stress_run_2026-03-23
- dataset_version: semantic_v2 + router_fix
- questions_total: 40
- benchmark_profile: creative_hard_human_like
- generated_from: accounting_automation_structured_notes
- mode: validation / stress / pilot-readiness
- executor: <pipeline or person>
- overall_status: pass / pass_with_notes / fail

2. Executive summary

Коротко по-человечески:

что проверяли;
что в целом показал прогон;
где система сильна;
где ещё спотыкается;
готовность к следующему этапу.

3. Сводные метрики

Машиночитаемо и читаемо одновременно:

## Сводные метрики
- route_mismatch_count:
- degraded_answers_count:
- batch_route_count:
- live_mcp_drilldown_count:
- hybrid_store_plus_live_count:
- store_canonical_count:
- store_feature_risk_count:
- avg_latency_ms:
- p95_latency_ms:
- pass_rate:
- strongest_zone:
- weakest_zone:

4. Сводка по классам вопросов

Разбивка:

heavy_analytical
cross_entity
drilldown_explain
period_close_risk
document_reconciliation
rule_based_account_control
anomaly_probe
ambiguous_human_query

5. Детальный блок Q/A

И вот это главный кусок. Для каждого вопроса — отдельный кейс в одном и том же формате.

Формат одного кейса в отчёте

Вот рекомендованный шаблон.

---
question_id: QH-01
question_class: cross_entity
difficulty: hard
domain_tags: [60, 62, сверка, документы, проводки, period_close]
expected_route: hybrid_store_plus_live
actual_route:
route_match:
latency_ms:
decision_flags:
  needs_exact_object_trace:
  needs_causal_chain:
  needs_cross_entity_join:
  needs_full_period_aggregation:
  needs_ranking:
  needs_anomaly_summary:
  needs_runtime_truth:
  freshness_sensitive:
  ambiguous_object_scope:
  store_sufficiency_confident:
  precomputed_aggregate_available:
store_sufficiency:
  canonical_sufficient:
  feature_sufficient:
  risk_sufficient:
  freshness_ok:
  aggregate_level_ok:
  ranking_ready:
  explanation_ready:
  reason_codes: []
answer_quality:
  status: pass / partial / fail
  confidence: high / medium / low
  degraded: false
---

## QH-01. [Короткое название кейса]

**Вопрос:**  
Покажи, по каким покупателям у нас на конец июня висят отгрузки без оплаты, и сразу свяжи это с реализациями, договорами и проводками, чтобы было видно, где именно хвост и чем он подтверждается.

**Что хотел проверить этот вопрос:**  
Проверка связки 62 ↔ 90 ↔ документы реализации ↔ оплаты ↔ договоры ↔ проводки, то есть не плоский факт, а причинная цепочка.

**Почему вопрос сложный:**  
Требует одновременно:
- cross-entity join,
- causal stitching,
- period-end cut,
- объяснимую цепочку источников.

**Как система должна была это понять:**  
Это не simple factual и не чистый trend.  
Это causal cross-entity scenario → ожидается `hybrid_store_plus_live`.

**Куда ожидали маршрут:**  
`hybrid_store_plus_live`

**Куда реально пошёл маршрут:**  
`...`

**Почему это корректно / некорректно:**  
Короткий человеческий комментарий.

**Краткий ход решения системы:**  
1. Определила периодный срез.  
2. Определила сущности: покупатель, реализация, оплата, договор, проводка.  
3. Проверила sufficiency canonical store.  
4. Поняла, что нужен causal join.  
5. Пошла в hybrid.

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

**Что реально получили:**  
Короткий summary ответа.

**Вердикт по кейсу:**  
pass / partial / fail

**Замечания:**  
Что докрутить, если что.

Почему такой формат хороший

Он одновременно:

удобен для ручного чтения;
достаточно структурирован для diff между прогонами;
хранит route-логику рядом с человеческим комментарием;
позволяет потом быстро делать выжимку по классам ошибок;
пригоден как для внутреннего техотчёта, так и для демонстрации зрелости системы.

Новый набор вопросов для Creative Stress Run

Ниже даю 40 вопросов, уже заметно более жёстких и ближе к реальному бухгалтерам-режиму. Они построены из тех болей, что были в выжимке: 01/02, 97, 41, 51, 60, 62, 90, 10, сверки, незакрытые хвосты, предзакрытие периода, ошибки дат, отсутствие документов, причинная цепочка.

Блок A. Предзакрытие периода

QH-01

Собери мне предзакрытие июня по-человечески: какие счета сейчас выглядят самыми проблемными, где хвосты, где незакрытые куски и что надо проверить в первую очередь, если период закрывать сегодня.

Класс: heavy_analytical Ожидаемый route: batch_refresh_then_store

QH-02

Покажи не просто проблемные счета за июнь, а объясни, почему именно они попали в риск-зону: чем это вызвано, какими документами и какими типовыми ошибками это может быть связано.

Класс: heavy_analytical Ожидаемый route: batch_refresh_then_store

QH-03

Сделай рейтинг самых опасных хвостов на конец июня, чтобы было видно, какие из них могут реально аукнуться при сдаче отчётности, а какие просто технический шум.

Класс: heavy_analytical Ожидаемый route: batch_refresh_then_store

QH-04

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

Класс: heavy_analytical / anomaly_probe Ожидаемый route: batch_refresh_then_store

QH-05

Если бы ты был главбухом и у тебя было полчаса перед закрытием периода, какие пять зон ты бы открыл первыми и почему?

Класс: heavy_analytical + explain Ожидаемый route: batch_refresh_then_store

Блок B. 60 / 62 / сверки / хвосты

QH-06

Покажи, по каким поставщикам у нас не бьются взаиморасчёты, и разложи это не только по суммам, а по конкретным документам, оплатам и отсутствующим закрывающим.

Класс: cross_entity Ожидаемый route: hybrid_store_plus_live

QH-07

По каким покупателям у нас есть отгрузка, но нет оплаты или нормального закрытия, и как это выглядит в цепочке документ → проводка → взаиморасчёт?

Класс: cross_entity Ожидаемый route: hybrid_store_plus_live

QH-08

Где по 60 и 62 счётам у нас не просто долг висит, а есть ощущение, что отсутствует какой-то первичный документ, из-за чего цепочка развалилась?

Класс: cross_entity / explain Ожидаемый route: hybrid_store_plus_live

QH-09

Покажи мне контрагентов, по которым расхождение выглядит подозрительно: то есть не обычная задержка, а именно такая история, где документы, оплаты и сальдо друг другу не соответствуют.

Класс: cross_entity / anomaly_probe Ожидаемый route: hybrid_store_plus_live

QH-10

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

Класс: cross_entity / period_close_risk Ожидаемый route: hybrid_store_plus_live

Блок C. 41 / товары / приход / реализация

QH-11

Где товар уже ушёл в реализацию, а нормального прихода под него в учёте не видно, и как эта проблема выглядит по датам, документам и поставщикам?

Класс: cross_entity Ожидаемый route: hybrid_store_plus_live

QH-12

Найди мне такие продажи, где себестоимость или приход выглядят подозрительно, как будто накладная запоздала, документ не дошёл или дата заведена криво.

Класс: cross_entity / anomaly_probe Ожидаемый route: hybrid_store_plus_live

QH-13

Покажи отрицательные или аномальные остатки по товарам не просто списком, а с объяснением, какая цепочка событий к этому привела.

Класс: drilldown_explain / cross_entity Ожидаемый route: hybrid_store_plus_live

QH-14

Есть ли такие товарные позиции, где проблема тянется не один раз, а повторяется по схожему паттерну: продажа раньше прихода, странный разрыв по датам, неподложенные документы?

Класс: heavy_analytical / anomaly_probe Ожидаемый route: batch_refresh_then_store

QH-15

Покажи, какие складские или товарные хвосты на конец июня больше всего искажают картину периода.

Класс: heavy_analytical Ожидаемый route: batch_refresh_then_store

Блок D. 97 / расходы будущих периодов

QH-16

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

Класс: rule_based_account_control Ожидаемый route: store_feature_risk

QH-17

Покажи мне расходы будущих периодов, где ошибка, скорее всего, сидит в дате начала, окончания или вообще в неверно указанном годе.

Класс: rule_based_account_control / anomaly_probe Ожидаемый route: store_feature_risk

QH-18

Есть ли такие записи на 97 счёте, которые вроде заведены, но по ним нет нормального ежемесячного списания, и с какими исходными документами это связано?

Класс: cross_entity / explain Ожидаемый route: hybrid_store_plus_live

QH-19

Покажи банковские гарантии, лицензии и похожие истории, которые сидят на 97, но выглядят так, будто срок действия и срок списания друг другу противоречат.

Класс: rule_based_account_control / cross_entity Ожидаемый route: hybrid_store_plus_live

QH-20

Сделай мне обзор по 97 счёту: что там сейчас выглядит как реальный риск периода, а что просто требует внимания, но не горит.

Класс: heavy_analytical Ожидаемый route: batch_refresh_then_store

Блок E. 01 / 02 / ОС / амортизация

QH-21

Какие основные средства выглядят заведёнными так, будто амортизационная группа или срок амортизации выбраны сомнительно?

Класс: rule_based_account_control Ожидаемый route: store_feature_risk

QH-22

Покажи карточки ОС, где параметры похожи на ручную ошибку: группа одна, срок другой, логика начисления не бьётся.

Класс: rule_based_account_control / anomaly_probe Ожидаемый route: store_feature_risk

QH-23

Есть ли у нас объекты, по которым амортизация должна была идти, но не идёт, и чем это подтверждается в карточке и движениях?

Класс: cross_entity / explain Ожидаемый route: hybrid_store_plus_live

QH-24

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

Класс: heavy_analytical / explain Ожидаемый route: batch_refresh_then_store

QH-25

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

Класс: heavy_analytical / anomaly_probe Ожидаемый route: batch_refresh_then_store

Блок F. 51 / банк / выписки / отражение в учёте

QH-26

Покажи движения по банку, где есть ощущение, что выписка, документ и проводка не собрались в нормальную цепочку.

Класс: cross_entity Ожидаемый route: hybrid_store_plus_live

QH-27

Есть ли у нас банковские движения, которые визуально выглядят нормально, но по логике счёта 51 оставляют некорректный хвост или ломают инвариант счёта?

Класс: rule_based_account_control / anomaly_probe Ожидаемый route: store_feature_risk

QH-28

Найди операции по банку, где, скорее всего, проблема не в сумме, а в том, что что-то не было проведено или не туда легло.

Класс: drilldown_explain / cross_entity Ожидаемый route: hybrid_store_plus_live

QH-29

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

Класс: heavy_analytical Ожидаемый route: batch_refresh_then_store

QH-30

Покажи, где движение по банку есть, а нормального отражения в учёте не видно, либо наоборот — в учёте что-то есть, а банковской логики под этим не хватает.

Класс: cross_entity Ожидаемый route: hybrid_store_plus_live

Блок G. 90 / 62 / реализация и неоплата

QH-31

Какие реализации на конец июня зависли без оплаты и уже выглядят не как нормальная отсрочка, а как потенциально проблемный хвост?

Класс: heavy_analytical / cross_entity Ожидаемый route: batch_refresh_then_store

QH-32

Покажи связку реализация → оплата → договор → проводки по самым крупным незакрытым отгрузкам.

Класс: cross_entity Ожидаемый route: hybrid_store_plus_live

QH-33

Где по реализации хвост образовался не из-за отсутствия денег как таковых, а из-за разрыва документов, дат или отражения?

Класс: cross_entity / explain Ожидаемый route: hybrid_store_plus_live

QH-34

Сделай рейтинг самых неприятных незакрытых реализаций: чтобы было видно и сумму, и возраст хвоста, и признаки, что это именно проблема учёта, а не обычная операционка.

Класс: heavy_analytical Ожидаемый route: batch_refresh_then_store

QH-35

Покажи мне такие кейсы по 90/62, где всё выглядит почти нормально, но если копнуть глубже, видно, что период закрывается на кривой связке.

Класс: anomaly_probe / cross_entity Ожидаемый route: hybrid_store_plus_live

Блок H. 10 / материалы / списание

QH-36

Что сейчас лежит на 10 счёте так, будто это уже давно просится в списание или хотя бы в ручную проверку?

Класс: rule_based_account_control Ожидаемый route: store_feature_risk

QH-37

Покажи материалы, по которым можно заподозрить нелогичный остаток: они висят, но движения и хозяйственная логика вокруг них выглядят странно.

Класс: rule_based_account_control / anomaly_probe Ожидаемый route: store_feature_risk

QH-38

Свяжи по нескольким подозрительным материалам остаток, документы, движения и возможный сценарий, почему они зависли.

Класс: cross_entity / explain Ожидаемый route: hybrid_store_plus_live

Блок I. Специально неоднозначные человеческие вопросы

QH-39

Где у нас вообще “пахнет ручной ошибкой”, а не нормальной хозяйственной жизнью? Не по одному счёту, а в целом по июню.

Класс: heavy_analytical / anomaly_probe / ambiguous_human_query Ожидаемый route: batch_refresh_then_store

QH-40

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

Класс: heavy_analytical / period_close_risk / ambiguous_human_query Ожидаемый route: batch_refresh_then_store

Как я предлагаю оформить ответы в прогоне

Не просто “вопрос — route — pass/fail”, а именно гибридный стиль:

Для человека

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

Для машины

question_id
question_class
expected_route
actual_route
route_match
decision_flags
store_sufficiency
latency_ms
answer_quality.status
degraded
reason_codes

Это как раз даст вам отчёт, который можно:

читать глазами,
diff’ать между версиями,
позже использовать как validation corpus.

Очень важная рекомендация

Я бы в этот новый прогон добавил ещё одно поле, которого раньше, скорее всего, не хватало:

**Проверяемая бухгалтерская гипотеза:**  
Какую именно предметную гипотезу должен был подтвердить или опровергнуть ассистент.

Пример:

“по 97 счёту ошибка сидит в дате начала/окончания”;
“по 41 счёту продажа опередила приход”;
“по 60/62 счёту хвост образован отсутствием документа, а не просто неоплатой”.

Это сильно улучшит читаемость именно для предметников.

Мой практический совет по следующему прогону

Сделайте следующий прогон не на всех 40 сразу, а в два прохода:

Проход 1 — 15 вопросов

QH-01, 03, 06, 07, 11, 16, 18, 21, 23, 26, 29, 31, 33, 39, 40

Это даст:

heavy,
cross-entity,
anomaly,
rule-based,
ambiguous human questions.

Проход 2 — все 40 После того как увидите, где он ещё хромает на творческих и длинных формулировках.

Короткий вывод

Да, следующий benchmark надо делать уже не “академическим”, а человекообразным и предметно-злым. И лучший формат отчёта для этого — один MD-файл с карточками кейсов, где рядом живут:

вопрос,
предметный смысл,
ожидаемый маршрут,
фактический маршрут,
краткий ход рассуждения системы,
и итоговый вердикт по качеству ответа. Вся эта логика напрямую вытекает из разговора с главбухом: ваша ценность — это контрольный и аналитический слой по реальным бухгалтерским болям, а не игрушечные вопросы “найди документ номер N”.

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

26 KiB Raw Blame History Unescape Escape

Что предлагаю сделать

Архитектура итогового отчёта

Имя файла

Структура файла

1. Паспорт прогона

2. Executive summary

3. Сводные метрики

4. Сводка по классам вопросов

5. Детальный блок Q/A

Формат одного кейса в отчёте

Почему такой формат хороший

Новый набор вопросов для Creative Stress Run

Блок A. Предзакрытие периода

QH-01

QH-02

QH-03

QH-04

QH-05

Блок B. 60 / 62 / сверки / хвосты

QH-06

QH-07

QH-08

QH-09

QH-10

Блок C. 41 / товары / приход / реализация

QH-11

QH-12

QH-13

QH-14

QH-15

Блок D. 97 / расходы будущих периодов

QH-16

QH-17

QH-18

QH-19

QH-20

Блок E. 01 / 02 / ОС / амортизация

QH-21

QH-22

QH-23

QH-24

QH-25

Блок F. 51 / банк / выписки / отражение в учёте

QH-26

QH-27

QH-28

QH-29

QH-30

Блок G. 90 / 62 / реализация и неоплата

QH-31

QH-32

QH-33

QH-34

QH-35

Блок H. 10 / материалы / списание

QH-36

QH-37

QH-38

Блок I. Специально неоднозначные человеческие вопросы

QH-39

QH-40

Как я предлагаю оформить ответы в прогоне

Для человека

Для машины

Очень важная рекомендация

Мой практический совет по следующему прогону

Короткий вывод

26 KiB

Raw Blame History