Talk · 29.04.2026

Технический маховик: как Oper8 собирается в реальности.

Книгу вы прочитали. Концепт двойного маховика помните: внешний цикл — клиент учит систему, внутренний — система учится на своих решениях, в центре — память решений. Сегодня — техническая карта поверх той же картинки.

Маховик — не метафора, а архитектура. Шесть узлов, одно ядро, и одна вещь, которая определяет, крутится оно или нет — замкнутость петли. Большинство компаний собирают узлы и удивляются, что ничего не происходит. Не происходит, потому что петля разомкнута.

скролл / ↓ ↓

Карта

Шесть узлов и центр.

Та же картинка из книги, на ней — технический слой. Кликни узел → откроется деталь как презентация.

→ кликни узел

Жизненный цикл данных

Как данные крутятся в петле.

Между коробками маховика течёт что-то — это данные. Покажу на одном из наших проектов: AI слушает приём врача и пациента, автозаполняет карту приёма. Врач подтверждает или правит. Главное — три параллельные петли разной скорости.

Из UI БИТ — после приёма

Action capture

врач: принял · поправил готовую фразу · выбрал другой template · оставил дефолт

Центр

Decision Log (append-only)

для каждого поля карты: что предложил AI → что выбрал врач → reopen / жалоба через 7–30 дней

→ split на 3 ветки разной скорости ↓

Tier 1

Минуты

Retrieval / hotword index

Новые примеры из Decision Log сразу попадают в RAG. Следующий retrieval их видит.

Из проекта На каждый приём за ~200 мс собирается hotword-set: специализация врача + анамнез пациента + closed-set готовых фраз шаблона. ASR приоритизирует эту лексику.

Owner: автоматика + PO

Tier 2

Дни — недели

Кандидаты в KB · промпты

Доменный эксперт ревьюит партиями по 30 минут раз в неделю. Обновление промптов, golden cases.

Из проекта Каждое расхождение «agent предложил X, врач выбрал Y» → новое правило. Появился новый кардиологический протокол → agent его не угадывал → доменный эксперт добавил 8 готовых фраз в справочник «Параметры шаблонов» → следующие приёмы agent уже знает.

Owner: эксперт + Eval Specialist

Tier 3

Месяцы

LoRA fine-tune

50–100 ч размеченного корпуса → fine-tune раз в квартал. Accept criteria: eval ↑ ≥3 п.п.

Из проекта 80 ч записей кардиологов 4 клиник → дообученная модель распознавания. Точность распознавания медтерминов: 85% → 93%. Точность заполнения карты: 78% → 92%.

Owner: ML Engineer + разметчик-медик

Где обычно ломается

Четыре способа собрать узлы и не крутить маховик.

Эти четыре failure mode мы видим во всех Mid-market проектах. Узлы есть, маховик стоит.

FAILURE 01

Петля разомкнута

Сигналы собираются, события в логе, eval гоняется. Но обновление KB и промптов — раз в квартал. Связи «что узнали → что делаем» нет.

→ Владелец KB + автоподача кандидатов из лога с feedback.

FAILURE 02

Eval без владельца

Тесты прогоняются, метрики записываются. Но никто не смотрит между ежемесячными ревью. Дрифт обнаруживается через месяц.

→ Алерт в мессенджер при падении eval. Не дашборд — алерт.

FAILURE 03

Autonomy creep

Стартовали на L2 с ограничениями. Через 3 месяца никто не помнит. Фактический уровень автономии «уползает» выше формального.

→ Autonomy Register на одной странице, ревью ежеквартально.

FAILURE 04

Голый LLM без контекста

«AI-агент» на одном промпте: «помоги с задачей X». Generic-ответы. На демо ОК, в production провал — доменная специфика не передана.

→ Даже на пилоте — Слой 1 адаптации. 2 дня инженера и 0₽.