Trust First — архитектурная философия Lyumi

Зафиксировано: 2 мая 2026, поздний вечер. Контекст: после марафонского дня (8 sprint'ов, BiOT 90%, reasoning layer deployed) ночной разговор привёл к moral pivot — не «как сделать продукт привлекательным для продажи», а «как сделать продукт за который не стыдно».

Этот документ — не roadmap, не execution plan. Это философский фундамент Lyumi, к которому можно возвращаться через 6 месяцев / год / при принятии любых архитектурных решений. Roadmap живёт в lyumi/sprints/2026-05-02-sprint-truth-roadmap. Здесь — почему.

Главный принцип

Lyumi не должна быть «как все, только умнее». Lyumi должна быть инструментом, которому можно доверять в compliance-домене.

Доверие здесь — не «общее ощущение», а техническое свойство:

Lyumi не выдумывает ссылки на НПА (architectural guarantee, не promise)
Lyumi умеет сказать «не знаю» когда retrieval не нашёл достаточно подтверждённых источников
Lyumi различает что есть норма, что есть вывод, что есть мнение
Lyumi показывает свои источники (verbatim quote + ссылка), а не пересказывает с риском искажения

Всё остальное — accuracy, скорость, стоимость, NPA citation rate — производные от этого принципа.

Корневой инсайт — bottleneck не в моделях

Доказательства из тестов 2 мая:

Opus subset test: 6 из 7 wrong-id Sonnet и Opus сошлись на ОДНОМ И ТОМ ЖЕ неправильном ответе. Convergent failure → проблема не в reasoning, а в retrieval.
Voyage rerank Run 4: идентичная accuracy с Cohere (76.8%, 63 correct, 18/19 wrong-ids совпадают). Замена реранкера эффект ≈ 0pp.
Reflection лог: «Фантомный приказ МТСЗН №109 от 31.03.2022», «Ложная ссылка на СП РК 1.03-106-2012». Phantom rate существует несмотря на 184 НПА в базе.

Вывод: замена модели — band-aid. Замена реранкера — не помогает. Расширение базы — не помогает. Промптом (level 0-1 enforcement) лечится плохо.

Нужен architectural enforcement на уровне 2-4 (mechanical filter / JSON schema / tool-use forced citation / server-side verification).

Прямая цитата от Камала: «промпты не работают, нужно на уровне спинного мозга».

6 типов hallucination — карта проблем

Один из главных результатов разговора 2 мая — разделение hallucination на дискретные классы. Это не один баг, это семь.

#	Тип	Что это значит	Compliance impact
1	Phantom NPA citation	Бот приводит несуществующий приказ или статью	Fatal — бесполезен в любом юридическом контексте
2	Paraphrase distorts meaning	Корректный источник, но пересказ искажает смысл	High — особенно опасно в сложных формулировках
3	Wrong reasoning around correct citation	Правильная статья, но вывод из неё неверный	High — кейс СИЗ/ТР ТС 019 (2 мая утром)
4	Mixed correct + incorrect claims	Ответ частично прав, частично выдуман	Medium-high — юзер не знает где правда
5	Отсутствие «не знаю» refusal	Бот уверенно отвечает когда не должен	Critical — главный fingerprint untrustworthy AI
6	Retrieval of wrong document	Достали не тот чанк, бот ответил по нему	High — главный bottleneck Lyumi (доказано)
extra	Numerical reasoning errors	Высоты, концентрации, сроки, статьи путаются	Domain-specific — HSE особенно чувствителен

Каждый тип лечится разными механизмами. Citations API закрывает только #1 (на 99%+). Остальные требуют отдельных решений.

Принципы решений

1. Architectural enforcement > prompt instructions

Когда Lyumi регулярно делает ошибку, запрос не «как переписать промпт», а «какой mechanical filter / JSON schema / tool / API guarantee» гарантирует невозможность этой ошибки.

Это та же логика, что v4 SQL для номеров статей: вместо «не путай ТК и УК» в промпте — структурированная база с code_type metadata.

2. Refusal — first-class capability

«Не знаю» — это не failure mode, это функция продукта. Бот, который умеет отказаться, доверительнее бота, который всегда отвечает. Refusal должен быть встроен архитектурно (через should_refuse() на уровне retrieval score), не как промпт-инструкция.

3. Verifiability > convenience

Юзер должен видеть verbatim quote из НПА, не доверять пересказу. Это медленнее, длиннее, менее «гладко» — но проверяемо. В compliance-домене проверяемость > pleasant UX.

4. Coverage gaps признаются открыто

Вместо «делаем вид что покрываем всё» — явное разграничение что Lyumi знает (через retrieval) и не знает (refuse). Юзер должен понимать границы инструмента.

5. No paraphrased reasoning без оригинала

Каждый factual claim в ответе должен иметь supporting citation. Без citation → mark_as_unsupported или strip. Юзер видит «✅ Поддержанные» vs «⚠️ Неподдержанные» части ответа.

Что НЕ является trust

❌ «90% accuracy на BiOT» — это competence на MCQ, не trust в проде
❌ «80% NPA citation» — лучше 0% у Gemini, но всё равно 20% потенциально неправильных
❌ «Reflection layer ловит ошибки» — pre-deployment safety net, а не trust по умолчанию
❌ «У нас 184 НПА в базе» — coverage, не correctness
❌ «Бот вежливо извиняется когда ошибся» — это UX, не архитектура

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

Personal stance Камала

Это часть документа, потому что архитектурная философия отражает позицию основателя.

«Я не готов за неё платить». Камал сам не в target audience — он эксперт с 20+ лет HSE-опыта, ChatGPT good enough для его собственных задач. Lyumi — для junior'ов и middle-специалистов в HSE-нише КЗ нефтегаза, которым нужна юридически корректная привязка к НПА.

«Реклама неправды, не готов стоять за продуктом». Это написано после BiOT 90%. То есть триумфальный результат не отменил sense что в проде phantom rate всё равно слишком высок. Sprint Truth = restore integrity.

«Не хочу за неё деньги, хочу чтобы реально работало». Это moral pivot от B2B SaaS / pilot frame. Lyumi пока не оптимизируется под продажу — оптимизируется под correctness. Бизнес-стратегия lyumi/strategy_2026 требует ревизии под этот сдвиг (TODO).

Следствия для всех будущих решений

Когда возникает архитектурный выбор — спрашивать не «какой вариант быстрее / точнее на eval», а:

Какой вариант делает определённый класс ошибок невозможным?
Какой вариант позволяет боту явно сказать «не знаю»?
Какой вариант показывает юзеру источник, а не пересказ?
Какой вариант делает проверку независимой от LLM-prior?

Если ответы «никакой» — решение не архитектурное, оно patch-уровня. Принимать осознанно, документировать как temporary.

Что НЕ делаем (вытекает из философии)

❌ Не роутим больше на Opus как «спасение качества» — модель не bottleneck
❌ Не меняем reranker как silver bullet — реранкер effect ≈ 0pp
❌ Не добавляем больше НПА чтобы «закрыть пробелы» — coverage не trust
❌ Не пивим в B2B SaaS / showcase до восстановления integrity
❌ Не делаем fine-tune custom model как replacement архитектуры — overkill, не лечит retrieval
❌ Не идём в GraphRAG как «модный» паттерн — research track, Q3+

Связанные документы

[[lyumi/sprints/2026-05-02-sprint-truth-roadmap]] — execution plan этой философии (9 тасков, timeline, ROI оценки)
[[lyumi/v4_structured_retrieval]] — первая архитектурная победа (factual grounding через SQL)
[[lyumi/reasoning_layer_design]] — второй слой (reasoning correctness через rules файл)
[[lyumi/sprints/2026-05-02-biot-eval]] — accuracy benchmark, не trust benchmark
[[lyumi/strategy_2026]] — устарела частично, требует ревизии под trust-first frame

Возврат к этому документу

Если через месяц Lyumi показывает 95% accuracy, но у юзера в Telegram появилась хотя бы одна phantom citation — этот документ выиграл. Если 80% accuracy и 0 phantom — этот документ выиграл больше.

Цель — не самая умная Lyumi. Цель — самая trustworthy Lyumi для compliance-домена.

Всё остальное вторично.