Матрица Эйзенхауэра на модели решений: часть 2

Сложность: средняя

Пока писал первую часть, меня крутило дежавю: типизированные суждения с вероятностями казались до боли знакомыми, а чем - вспоминалось. Дошло уже после публикации: так ведь это матрица Эйзенхауэра, только без папок и с честным пятым квадрантом "не знаю". Проверил на сотне живых писем: 13 секунд, два цента, ноль ошибок.

Откуда связь

Матрица Эйзенхауэра: четыре квадранта для модели решений

В первой части я прогонял модель Jev по четырём задачам: фильтр инъекций, реранкер, триаж новостей и сортировка почты. И всё время ощущение, что я видел этот приём раньше: два независимых вопроса, четыре комбинации ответов, решение по квадрантам. Догадался, уже дописав ту статью, - Эйзенхауэр: срочное-важное делать сейчас, несрочное-важное планировать, срочное-неважное делегировать или отбросить, несрочное-неважное в мусор.

Классическая матрица живёт в ежедневниках и умирает там же по одной причине: заполнять её вручную лень, а отдать сортировку фильтрам по ключевым словам нельзя - они смысла не понимают, один синоним, и письмо пролетает мимо правила. Модель решений понимает: вопрос "срочно ли" и вопрос "важно ли" - это два независимых суждения над одним текстом, и Jev отвечает на оба одним запросом параллельно. Это паттерн fan-out из первой части, применённый к схеме из любого учебника тайм-менеджмента.

Часть 1, если пропустил: Четыре эвала для модели решений.

Почему это омниканально

Главное свойство System One моделей: на вход идёт просто текст. Откуда он взят - почта, личка в Telegram, тикет от бота, заметка в CRM - модели всё равно. Один классификатор с одними критериями встаёт на все входящие каналы сразу, и это делает его не скриптом под конкретный сервис, а слоем поверх всех источников сразу.

`почта       {subject, from_domain, body_snippet}
Telegram    {chat_type, text}
бот/CRM     {ticket_type, message}

           -> один запрос, два Noul:

urgent:    "требует реакции в ближайшие часы?"
important: "влияет на деньги, обязательства,
            здоровье, семью, ключевую инфру?"

Q1 делать      Q2 планировать     Q3 отбросить
Q4 мусор       ?  не знаю -> человеку`

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

Замер: 100 живых писем

Взял свою входящую почту за неделю, 100 писем, в state уходили тема, домен отправителя и 300 знаков текста. Вопросы те же два Noul, порог квадрантов 0.7, серая зона 0.38-0.62.

`писем:            100
время:            13.4 c (батч, 6 воркеров)
ошибок API:       0
токены:           53 402 = $0.0022

Q4 мусор:             61
? на усмотрение:      31
Q2 запланировать:      3
Q3 срочно-неважно:     5
Q1 делать сейчас:      0`

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

Что модель различила

Пара штрафов от ГИБДД легла в Q2 - важно, но не горит. Верификационные коды получили срочность 0.7-0.82 при низкой важности - чистый Q3, ровно их природа: горит, но жизнь не меняет. Рассылка о конце договора страхования остановилась на i=0.57 - модель не продала её в важное, но и не отбросила, отдала человеку. Предупреждение о балансе облачного счёта зависло между зонами, и это правильное поведение: для постороннего это шум, для владельца счёта - Q1, решать хозяину.

Ожидаемо серой оказалась серия CI-уведомлений от моих побочных проектов: срочность застыла на 0.6. Лекарство известно из первой части - критерии пишутся текстом, и строка "падения тестов хобби-проектов не срочны" увела бы их в Q4. Критерии персональны: для фрилансера уведомление о новых заказах - это Q2 и доход, для всех остальных - рассылка.

Грабли

Первый прогон на этой сотне я забраковал сам: баг в пакетном чтении писем отправил в модель 93 пустых состояния, и она уверенно разметила их мусором. Модель отработала честно - мусор на входе, мусор на входе. Урок: проверяй целостность state до API, уверенный вердикт на пустом входе выглядит как любой другой уверенный вердикт.

Второй: 31 процент уходит человеку, и это много. Но зона эскалации - не отходы, а настройка: её размер напрямую зависит от того, сколько контекста ты даёшь и как точно написал критерии. Скудный state - честное "не знаю", жирный state - уверенное решение.

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

Вывод

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

Ссылки

Часть 1: четыре эвала | Документация TypeSafe | Паттерны применения

Подписывайся: @hermesagentru