Перейти к содержанию

Reasoning Layer

📢 UPDATE 2 мая 2026, вечер — МИНИМУМ РАЗВЕРНУТ

Изначальный дизайн (ниже) предписывал «не делать до 9 мая». Камал решил: «не хочу промтом лечить, давай технически» — и тот же день развернули минимальные версии слоёв 1-3 без LLM в pipeline:

  • Слой 1 Source Authority Labels — ✅ в проде
  • Слой 2A Reasoning Rules (5 правил + severity warning/critical) — ✅ в проде
  • Слой 2B Positive Citation Check (цитирования в cards) — ✅ в проде как partial cross-reference
  • Слой 3 Static Claim Flagging (regex вместо LLM-decomposition) — ✅ в проде как lite-версия
  • Слой 4 G_reasoning eval set — ⏳ отложен на Sprint A после 9 мая
  • Слой 5 HSE expert feedback loop — ⏳ Q3-Q4, после 50+ активных юзеров

Детали: → [[lyumi/sprints/2026-05-02-reasoning-layer-deployed]]

Ключевые решения от изначального дизайна: - reasoning_rules — Python с dataclasses, не YAML. Проще тестировать, проще IDE‐поддержка. - Слой 3 — static regex, не LLM decomposition. Сохраняет 0 latency / 0 cost. Coverage ниже (~50-60% Harvey), но политика «adaptive routing» из изначального дизайна остаётся в backlog. - Severity stratification (warning/critical) — новое. Для critical rules (ТР ТС 019) short_alert prepend'ится в начало ответа, потому что append в конец слабо помогает если юзер прочитал только первый абзац с wrong reasoning.

Eval (n=5): inconclusive, markers легко оверфитятся. Real measurement идёт через observation week — JSONL логи reasoning_validations_*.jsonl. Не тюнить markers до желаемой картинки = cooking the books.

Оригинальный дизайн (зафиксирован 2 мая, утро)

Дизайн зафиксирован 2 мая 2026. Триггер начала работы — после observation week (после 9 мая), когда v4 SQL стабилизирован.

Зачем

v4 (SQL structured retrieval) закрыл factual hallucination: запросы про номера статей/приказов теперь идут через детерминированный lookup. Hit@5 на A_direct_number = 92.3%, на B_code_article = 89% после Sprint 1.

Но обнаружился другой класс ошибок — reasoning mistakes. Конкретный кейс 2 мая:

Запрос: «Можно ли использовать СИЗ с истёкшим сертификатом ТР ТС 019?»

Ответ Lyumi: - ✅ Факты правильные: ТР ТС 019 — техрегламент, ст. 156 УК — реальная статья - ❌ Логика применения сглажена: бот сказал «нельзя использовать», что юридически некорректно - ❌ Смешаны два понятия: срок действия сертификата производителя ≠ срок службы конкретной единицы СИЗ - ❌ Категоричный вывод на правовой теме, где есть нюанс «введения в оборот»

Это не factual hallucination — это reasoning mistake. v4 SQL её не ловит, потому что проблема не в данных, а в применении.

Что делают индустрия-лидеры

Главный механизм: decomposition + cross-check.

Decompose generated responses into individual factual claims, cross-reference each against authoritative sources, apply legal reasoning patterns, and flag inconsistencies before they reach users.

Hallucination rate в production = 0.2%.

Ключевое разделение: - Factual hallucination = «factual claim that can be demonstrably disproven by reference to a source of truth» — лечится через grounding - Reasoning mistakes — отслеживаются отдельно, через expert feedback loops + fine-tuning на reasoning patterns

OpenEvidence (medical, $12B оценка)

  • Trained exclusively on trusted medical literature (NEJM, JAMA, NCCN partnerships)
  • Source authority labels в ответе (peer-reviewed vs guideline vs case study)
  • Transparent sourcing — юзер видит уровень авторитета

Архитектура для Lyumi

Слой 1: Source authority labels (в hits_to_context) — ✅ DEPLOYED

Добавить metadata-теги в SQL records и retrieval chunks:

Тег Что это Пример
[НОРМА] Текст из кодекса/приказа/ТР Ст. 156 УК РК
[ОПЕРАТИВНО] Конкретная статья + номер для ссылки Приказ 344 МТСЗН п.5.3
[МЕТОДИЧКА] Guidelines, рекомендации (не норма) Методические указания МЧС
[МЕЖДУНАРОДНОЕ] Ориентир, не норма РК OSHA 1910, ACGIH TLV
[КОММЕНТАРИЙ] Общее место, не правовая привязка —

В system prompt: бот обязан сохранять эти ярлыки в финальном ответе.

Latency: +0ms (просто metadata). Сложность: низкая — изменить hits_to_context() + system prompt. Эффект: средний — юзер видит уровни авторитета, бот вынужден отделять норму от вывода.

Слой 2: Reasoning rules как файл (не в промпте) — ✅ DEPLOYED как reasoning_validator.py

Отдельный модуль с доменными правилами применения (Python dataclasses вместо YAML — легче тестировать):

ReasoningRule(
    rule_id="tr_ts_019_certificate_vs_lifetime",
    domain="СИЗ",
    trigger_patterns=[…],
    violation_patterns=[…],
    correction=«Полный разбор»,
    suppress_if_present=[…],
    severity="critical",
    short_alert=«🛑 ВАЖНО»,  # prepend в начало ответа
)

Latency: -1-2с (дешёвая regex-проверка вместо повторного LLM-вызова). Сложность: средняя — собирать правила (это сама работа). Эффект: высокий — ловит типовые reasoning mistakes детерминированно.

Key insight: сейчас правила «не путай X и Y» сидят в промпте как инструкции LLM. Они стоят токенов на каждом запросе, и LLM их регулярно нарушает. Перенести в rules-файл = архитектурное решение того же класса, что v4 SQL для номеров статей.

Слой 3: Claim decomposition + cross-check (Harvey-style) — ⚠️ в проде как static regex (lite), full LLM версия отложена

Не для всех запросов — только для сложных reasoning-вопросов.

Запрос (классификация):
  - simple lookup ("ст. 156 ТК") → пропускаем decomposition, ответ напрямую
  - reasoning question ("можно ли использовать СИЗ с истёкшим сертификатом") → 
      → ответ от LLM
      → Haiku разбирает на 5-7 atomic claims
      → каждый claim проверяется:
          * против SQL (factual)
          * против reasoning_rules (reasoning)
      → если хоть один не проходит → flag → переписать с указанием на проблему

Adaptive routing критичен. Без него: - Простые запросы замедлятся в 2-3 раза без необходимости - 80% юзерского трафика пострадает ради 20% сложных кейсов

С adaptive routing: - 80% запросов идут с обычной скоростью - 20% сложных тратят +3-5с на claim check - Юзер не замечает разницы для простых, получает корректные выводы для сложных

Latency для сложных: +3-5с p50. Сложность: высокая — 5-7 дней работы (классификатор, decomposer, checker, rewriter). Эффект: высокий — закрывает класс reasoning mistakes.

Слой 4: Reasoning mistakes как отдельная категория в eval — ⏳ ОТЛОЖЕН

Сейчас 6 категорий запросов: A_direct_number, B_code_article, C_topic, D_mixed, E_edge, F_date_ministry. Все они — factual.

Добавить G_reasoning — запросы вроде: -  «Можно ли использовать СИЗ с истёкшим сертификатом?» -  «Обязан ли проводить медосмотр для офисного работника?» -  «Что делать если ИТР не подписал акт?» -  «Применяется ли ТР ТС 019 к спецодежде, изготовленной в 2018 году?»

Это другой класс, и текущий LLM-judge его проверяет плохо (как и было показано 2 мая на 5 «incorrect», где judge сам галлюцинировал).

Latency: 0 (offline eval). Сложность: средняя — собрать 30-50 reasoning-вопросов, разметить экспертом (Bshopanov или сам Камал), prompt judge'у. Эффект: критический — без этого ты не знаешь, насколько часто бот ошибается на reasoning.

Слой 5: HSE expert feedback loop (долгосрочно, Q3-Q4) — ⏳ ОТЛОЖЕН

Bshopanov-кейс — это уже зерно. Нужно формализовать:

  • HSE-эксперт (внешний) ревьюит 10-20 случайных ответов в неделю
  • Помечает reasoning mistakes отдельным флагом (не "плохо" а "reasoning issue type X")
  • Эти примеры идут в:
  • reasoning_rules (extend)
  • eval set (G_reasoning)
  • в перспективе — fine-tune dataset для LLM (если решим custom model)

Latency: 0 (offline). Сложность: организационная — найти регулярного эксперта, договориться о ревью. Эффект: высокий — единственный способ ловить новые классы reasoning mistakes, которые мы сами не предусмотрели.

Связи

  • [[lyumi/sprints/2026-05-02-reasoning-layer-deployed]] — sprint write-up (deployed minimum)
  • [[lyumi/v4_structured_retrieval]] — factual grounding (parallel pillar)
  • [[lyumi/sprints/2026-05-01-sql-acgih-ax41]] — последний sprint
  • [[lyumi/strategy_2026]] — общая стратегия
  • [[lyumi/modules/investigation]] — апгрейд кнопки incident в /report (отдельная задача)
  • [[lyumi/modules/document_intelligence]] — отдельный модуль распознавания

Ссылки на референсы

  • Harvey AI architecture: https://medium.com/@takafumi.endo/how-harvey-built-trust-in-legal-ai-a-case-study-for-builders-786cc23c3b6d
  • Harvey BigLaw Bench (factual vs reasoning разделение): https://www.mmntm.net/articles/harvey-deep-dive
  • OpenEvidence source authority: https://www.healthcare.digital/single-post/clinical-intelligence-a-strategic-analysis-of-openevidence-and-the-multi-agent-medical-ai-ecosystem