Initial import NDC_1C
This commit is contained in:
@@ -0,0 +1,619 @@
|
||||
Да, давай сделаем следующий прогон уже **не “на каноничных вопросиках”**, а на более злой, предметной и местами провокационной выборке — ближе к тому, как человек реально разговаривает с бухгалтерским ассистентом. И да, архитектуру отчёта тоже сразу зафиксируем, чтобы на выходе был **один читаемый MD-файл**, который одновременно:
|
||||
|
||||
* удобно читать человеку,
|
||||
* удобно парсить машине,
|
||||
* удобно сравнивать между прогонами.
|
||||
Опираюсь на выжимку из разговора с главбухом: ядро ценности — не ввод первички, а контроль, сверка, поиск расхождений, анализ счетов, предзакрытие периода и вопросно-ответный интерфейс поверх нормализованной модели 1С.
|
||||
|
||||
---
|
||||
|
||||
# Что предлагаю сделать
|
||||
|
||||
Новый прогон собрать как **Benchmark v2 / Creative Stress Run**, где вопросы будут:
|
||||
|
||||
* более длинные;
|
||||
* более “человеческие”;
|
||||
* с доменной неоднозначностью;
|
||||
* с причинно-следственными цепочками;
|
||||
* с несколькими сущностями сразу;
|
||||
* с формулировками не “из теста”, а ближе к живому главбуху.
|
||||
|
||||
И на выходе генерировать **один отчёт `.md`** следующего типа:
|
||||
|
||||
---
|
||||
|
||||
# Архитектура итогового отчёта
|
||||
|
||||
## Имя файла
|
||||
|
||||
`benchmark_creative_stress_run_accounting_assistant_YYYY-MM-DD.md`
|
||||
|
||||
---
|
||||
|
||||
## Структура файла
|
||||
|
||||
### 1. Паспорт прогона
|
||||
|
||||
Короткий верхний блок:
|
||||
|
||||
```md
|
||||
# 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. Сводные метрики
|
||||
|
||||
Машиночитаемо и читаемо одновременно:
|
||||
|
||||
```md
|
||||
## Сводные метрики
|
||||
- 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
|
||||
|
||||
И вот это главный кусок. Для каждого вопроса — отдельный кейс в одном и том же формате.
|
||||
|
||||
---
|
||||
|
||||
# Формат одного кейса в отчёте
|
||||
|
||||
Вот рекомендованный шаблон.
|
||||
|
||||
```md
|
||||
---
|
||||
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.
|
||||
|
||||
---
|
||||
|
||||
# Очень важная рекомендация
|
||||
|
||||
Я бы в этот новый прогон добавил **ещё одно поле**, которого раньше, скорее всего, не хватало:
|
||||
|
||||
```md
|
||||
**Проверяемая бухгалтерская гипотеза:**
|
||||
Какую именно предметную гипотезу должен был подтвердить или опровергнуть ассистент.
|
||||
```
|
||||
|
||||
Пример:
|
||||
|
||||
* “по 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**, уже целиком, чтобы вы просто вставили туда результаты прогона.
|
||||
Reference in New Issue
Block a user