Запахи архитектуры в продуктах с приоритетом ИИ: что исправить

Где начинается проблема

Многие команды думают, что выпустили фичу, а на самом деле выпустили подсказку и надеялись, что модель сама разберётся. В демо это может сработать. Но всё разваливается, когда появляются реальные пользователи с грязными запросами, странными краевыми случаями и неудачным таймингом.

Первый признак прост: продукт делает что‑то важное, но никто не может показать правило, которое это вызвало. Спросите, почему одному пользователю дали предупреждение, возврат или заблокировали ответ — и ответ будет расплывчат. Кто‑то скажет «модель обычно понимает» или «мы подтолкнули её в подсказке». Это не правило. Это предположение.

Проблема заметна, когда два похожих запроса получают разные ответы. Один клиент пишет короткое сообщение и получает одобрение. Другой просит то же самое чуть иначе — и получает отказ. Политика не менялась. Изменилось восприятие модели. Если никто не записал правило принятия решения, никто не скажет, какой ответ был правильным.

Небольшие правки подсказки усугубляют проблему. Пара строк могут сместить тон, приоритеты и даже порядок решений. Ассистент поддержки перестанет задавать уточняющие вопросы и начнёт принимать жёсткие решения. Коммерческий ассистент может стать слишком любезным и обещать то, чего компания не собиралась давать. Команды часто считают правки подсказок просто изменением текста. На практике это изменение логики.

Обычно всё начинается под давлением сроков. Нужно быстро выпустить фичу, поэтому в одну длинную инструкцию упаковывают политику, исключения, тон и поведение на случай ошибки. Это кажется быстрее, чем определить ответственность, интерфейсы и письменные правила. Неделю‑две это может выглядеть нормально.

Потом продукт растёт. Появляются новые подсказки. Накопляются исключения. Вскоре никто не понимает, откуда берётся поведение — из политики, формулировки подсказки, обновления модели или случайной вариации. В этот момент система перестаёт быть гибкой. Она становится хрупкой.

Правила не должны жить в подсказках

Подсказка часто начинается как сокращение пути. Кто‑то пишет «не давать возврат после 30 дней» или «просить одобрение менеджера перед изменением счёта», и продукт кажется рабочим. Через месяц никто не понимает, была ли эта строка рекомендацией, жёстким правилом или устаревшей заметкой.

Это одна из самых распространённых ошибок проектирования в продуктах с приоритетом ИИ. Подсказка несёт на себе правила, которым место в другом месте. Когда так происходит, небольшие изменения формулировки могут поменять поведение продукта. Дружелюбная переделка текста от дизайнера или маркетолога может тихо нарушить политику.

Бизнес‑правила должны иметь своё место. Подсказки должны задавать тон, давать контекст и объяснять, какой ответ подходит. Они не должны решать, кто получает возврат, кто видит данные клиента или когда система может отправить сообщение без проверки.

Простой тест помогает: спросите «должен ли продукт следовать этому каждый раз?» Если ответ «да» — вынесите это правило из подсказки.

В большинстве продуктов жёсткие ограничения принадлежат коду. Правила по странам, лимиты расходов или поддерживаемые языки обычно кладут в конфигурацию. Юридические и процессные требования — в политические документы, которые люди могут проверять без переписывания подсказок. Подсказка может описывать правило простыми словами, но не быть источником истины.

Представьте ассистента поддержки, который говорит клиенту, можно ли вернуть товар. Если окно возврата существует только внутри подсказки, ассистент будет отклоняться при каждом изменении формулировки. Если окно возврата хранится в коде или конфиге, ассистент сможет объяснить политику, не придумывая исключений.

Команды обычно замечают проблему, когда ответы становятся непоследовательными. Одному клиенту сделали исключение, другому отказали. Логи показывают разные версии подсказок, но никто не может сказать, какое правило изменилось. Это не проблема письма. Это проблема системного дизайна.

Когда подсказки перестают быть скрытыми файлами политики, продукт становится проще тестировать, проще проверять и гораздо менее хрупким.

Одно рискованное решение — один ответственный

Продукт очень быстро расшатывается, когда модель может сказать «да», «нет», «вернуть деньги», «отклонить», «эскалировать» или молчать, а никто не отвечает за этот выбор.

Если вывод модели влияет на деньги, доверие, безопасность, доступ или поддержку клиентов — назначьте этому решению одного именованного ответственного. Не команду. Не канал в Slack. Одного человека, который сможет ответить на три простых вопроса: что должна делать модель, чего она никогда не должна делать и что происходит, когда она ошибается.

Команды часто скрывают этот пробел правками подсказок. Продукт меняет формулировку, операции меняют пороги, поддержка фиксирует жалобы, инженерия выкатывает правку. Потом плохой ответ доходит до пользователей и у каждого есть своя часть объяснения, но никто не может исправить проблему целиком.

Простое правило: у каждого модельного решения должен быть один владелец, один утверждающий для рискованных правок подсказки и один человек, который разбирается с плохими выводами после релиза. Иногда это один и тот же человек. Часто — нет.

Подумайте о помощнике поддержки, который может предлагать кредит на счёт. Если подсказка меняется от «предложить кредит» до «выдать кредит, когда пользователь звучит расстроенным», это не маленькая правка текста. Модель теперь влияет на расходы и политику. Такое изменение должен утвердить кто‑то перед выходом в прод.

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

Это также сокращает время разборов инцидентов. Вместо споров о том, запуталась ли модель, команда задаёт более полезные вопросы: кто владел этим решением, кто утверждал последнее изменение и кто убирал последствия плохого вывода.

Oleg Sotnikov часто работает с командами, которые хотят ускорить доставку с помощью ИИ без превращения базовых решений в догадки. Решение редко «ещё подсказок». Чаще это — ясная ответственность, письменные правила и реальный человек, привязанный к каждому рискованному решению.

Определите интерфейс

Многие баги AI‑продукта — не баги модели. Они начинаются там, где один шаг передаёт работу следующему без чёткого контракта. Подсказка часто скрывает этот разрыв: выглядит как логика, а действует как неописанный интерфейс.

Возьмите поток поддержки. Модель получает сообщение клиента, несколько заметок из CRM, возможно статус заказа и вставленный абзац политики. Если никто не указал, какие входы обязательны, модель заполняет пропуски догадками.

Чистый интерфейс начинается с полного списка входов. Запишите каждое поле, которое получает модель, откуда оно берётся и насколько свежим должно быть. «Почта клиента» — слишком мало. Часто нужны уровень аккаунта, окно возврата, состояние доставки, предыдущие обещания и версия политики.

Выход требует такого же внимания. Свободный текст вроде «вроде подходит» или «отправить извинение» создаёт работу downstream, потому что каждый интерпретирует это по‑своему. Определите точные выходные поля. Для решения поддержки это могут быть action, message_draft, reason, confidence и review_required.

Состояния ошибок важны так же, как и счастливый путь. Если данные по заказу отсутствуют, что система должна делать? Остановиться и попросить запись, сделать безопасный ответ или отправить дело человеку? Выберите одно. Если оставить выбор в подсказке, поведение будет дрейфовать.

Здесь команды застревают. Они относятся к модели как к умному члену команды, который «разберётся». На таком допущении продукт долго не проработает. Когда ответственность размыта, а интерфейсы неясны, каждая подсказка превращается в мини‑приложение со скрытыми правилами.

Структурированные данные обычно решают больше проблем, чем тонкая настройка подсказок. Передавайте типизированные поля, перечисления и явные коды статусов там, где это возможно. Пусть модель пишет текст или делает ограниченный выбор, но не заставляйте её декодировать грязный абзац из другой системы, если достаточно простого поля.

Oleg часто помогает командам быстрее двигаться с ИИ без роста затрат на операцию. На практике это значит меньше волшебных подсказок и больше скучных, явных интерфейсов. Скучное выигрывает. Другие системы могут его читать, тестировать и безопасно падать.

Просмотрите один реальный рабочий процесс

Большинство проблем проявляется, когда простая задача пересекает слишком много скрытых шагов. Выберите одну реальную пользовательскую задачу и проследите её от первого клика до финального результата.

Возьмите задачу, которая важна каждую неделю, а не редкий краевой случай. Ответ в поддержку, квалификация лида или запрос на ревью кода ИИ работают хорошо — люди быстро замечают ошибки.

Запишите путь по шагам. Отметьте, что отправляет пользователь, каждую подсказку и вызов модели, каждый вызов инструментов и каждую передачу человеку. Затем укажите, что каждый шаг должен возвращать и что происходит, если шаг падает или возвращает расплывчатый ответ.

Эта карта вскрывает слабые места быстрее, чем очередная правка подсказки. Если команда не может объяснить один шаг в одно предложение, правило, вероятно, живёт в чьей‑то голове или внутри подсказки, которую никто не хочет читать дважды.

На каждом шаге задавайте один вопрос: где живёт правило? Может, оно должно быть в коде, в настройке продукта, в письменной политике или решать должен человек. Если единственный ответ — «подсказка говорит, что делать», вы, скорее всего, нашли проблему.

Затем опишите ожидаемый выход простыми словами. Не пишите «качественное резюме» или «умная маршрутизация». Опишите, как выглядит хороший результат: «трёхпредложное резюме, приоритет от 1 до 3 и одно конкретное следующее действие». Это заставит команду определить интерфейс вместо надежды, что модель угадает.

Небольшой пример помогает увидеть это. Клиент присылает отчёт об ошибке. Модель читает сообщение, проверяет логи, предлагает степень серьёзности и открывает тикет. Проследите каждую передачу. Кто решает степень серьёзности? Какие поля логов должны вернуть инструмент? Если уверенность низкая, система спрашивает человека, задаёт уточняющий вопрос пользователю или останавливается и помечает кейс для ревью?

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

Простой пример с коммерческой квотой

Компания добавляет AI‑ассистента продаж, который составляет кастомные коммерческие предложения. Менеджер пишет «50 мест, годовой план, скидка для некоммерческих организаций, плата за внедрение отменяется, если подпишутся на этой неделе», и модель за секунды готовит отточенное предложение. Люди быстро доверяют, потому что это экономит время.

Проблема лежит там, где многие команды почти не рассматривают продуктовую логику. Политика скидок не хранится в таблице правил, в сервисе цен или в потоке согласования. Она живёт внутри системной подсказки. Там написано, какие скидки давать, когда можно отменять сборы и какие сделки требуют одобрения финансов.

Это работает до тех пор, пока финансы не меняют политику. Некоммерческие организации по‑прежнему получают скидку, но не более 10%. Отмена платы за внедрение теперь требует одобрения менеджера. Финансы обновляют таблицу и говорят команде продаж. Никто не обновляет подсказку.

Продажа продолжает пользоваться ассистентом, а ассистент продолжает составлять котировки по старым правилам. Вскоре он рассылает цены, которые никто не должен был утверждать.

Это не ошибка написания подсказки. Это ошибка архитектуры продукта. У правила нет явного владельца в системе, и модель не имеет интерфейса для проверки актуальной политики. Она умеет только следовать устаревшему тексту.

Проблема вылезет позже. Клиент принимает котировку. Финансы замечают цену и поднимают вопрос. Команда получает два плохих варианта: исполнить неправильную цену или отозвать предложение и выглядеть несуразно.

Решение простое. Финансы должны владеть таблицей правил по скидкам и отмене сборов. Ассистент должен читать утверждённые правила из этой таблицы перед составлением предложения. Если котировка нарушает лимит — система останавливается и просит одобрения. Модель не должна придумывать цены только на основе текста в подсказке.

Это превращает скрытые инструкции в видимое поведение продукта и делает обновление политики скучным — а именно это и нужно.

Распространённые ловушки

Команды часто считают подсказку спецификацией продукта. Если реальное правило живёт в абзаце подсказки, его нельзя проверить, протестировать или безопасно изменить.

Бот поддержки делает это простым для незамечания. Кто‑то добавляет строку «одобрять возвраты для лояльных клиентов» или «быть гибким в краевых случаях», и бот начинает принимать решения. В демо это выглядит умно, но на практике это не ясная политика — это политика в форме предположений.

Далее ответственность размывается. Один человек продолжает дорабатывать подсказки до тех пор, пока ответы не станут «лучше», и никто эти изменения не ревьюит. Это может работать некоторое время. Затем небольшая правка меняет обработку риска, цены или эскалацию, и никто не может объяснить, почему поведение сдвинулось.

Команды также смешивают пользовательские инструкции с внутренними правилами в одном сообщении. Тогда модель вынуждена каждый раз заново решать, что важнее. Вежливый пользователь может сдвинуть ответ в сторону, а настойчивый — вытащить скрытые правила наружу.

Ещё одна ловушка появляется, когда модель отправляет свободный текст в downstream‑системы. Ответ вроде «скорее всего одобрить» или «отправить завтра, если будет на складе» звучит нормально человеку. Биллинговая система, CRM или автоматизация требуют более строгого формата. Если интерфейс не определён, расплывчатый текст превращается в реальные действия.

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

Демо скрывает всё это. Проблема начинается, когда подсказки несут правила, никто не владеет решениями, а downstream‑системы принимают текст там, где нужно было поле со значением.

Проверки перед релизом

Если единственное реальное правило живёт в длинной подсказке, продукт хрупок. Перед релизом должно быть просто ответить на несколько вопросов за минуты, а не устраивать полдня охоты по Slack.

Может ли новый коллега найти лимиты по биллингу, правила утверждения и шаги фолбэка без построчного прочтения подсказки? Можно ли назвать одного человека, ответственного за каждое рискованное действие — отправку денег, удаление данных, смену цен или контакт с клиентом? Может ли другой сервис довериться формату выхода с фиксированными полями, допустимыми значениями и понятными состояниями ошибок? Может ли поддержка прочитать логи и объяснить, почему модель ответила, отказалась, повторила попытку или эскалировала? Если модель уходит в сторону, останавливается ли рабочий процесс, просит ли проверку или переходит на узкий безопасный путь?

Размещайте жёсткие правила там, где их можно найти и протестировать: в коде, конфиге, таблицах решений или в админ‑настройках. Если новому инженеру нужно два часа, чтобы обнаружить, что большие возвраты требуют одобрения — правило спрятано не в том месте.

Ответственность важна не меньше. Модель не должна владеть решением. Владеть им должен человек. Если за рискованный шаг никто не отвечает, будут обвинять подсказку, когда что‑то пойдёт не так, и ошибка повторится.

Интерфейсы требуют той же дисциплины. Свободный текст хорошо выглядит в демо, но быстро ломается в проде. Если другой системе нужен статус, причина и следующее действие — опишите эту форму и валидируйте её до движения вперёд.

Логи решают, сможет ли поддержка помочь или будет гадать. В логах нужен request ID, версия модели, версия подсказки, вызовы инструментов, результаты валидации и окончательное действие. Без этой цепочки поддержка может только догадываться, а клиенты будут слышать эти догадки в каждом ответе.

Небольшой пример делает это очевидным. Допустим, AI‑агент формирует кредиты клиентам. Если сумма необычная, поток должен приостановиться и попросить проверку. Он не должен придумывать причину, выдавать кредит и оставлять поддержку разгребать последствия.

Если хоть одна из этих проверок провалена — релиз ещё не готов.

С чего начать исправления

Большинство команд сначала чистят подсказки, а не систему вокруг них. Это неправильно. Исправляйте то, что остаётся верным, даже когда модель меняется.

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

Дальше — назначьте одного человека ответственным за каждый шаг, управляемый моделью. Когда модель отправляет письмо, одобряет скидку, меняет запись или маршрутизирует тикет — кто‑то должен отвечать за этот исход. Общая ответственность чаще всего означает, что никто не замечает плохой краевой случай, пока клиент не пожалуется.

Затем определите небольшие интерфейсы до того, как добавлять новых агентов. Каждый шаг нуждается в чётком входе, ожидаемом выходе и простом правиле на случай ошибки. Команды попадают в неприятности, когда один агент передаёт расплывчатый текст другому и все надеются, что смысл не потеряется.

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

Поток возврата в поддержку хорошо демонстрирует паттерн. Если подсказка говорит «будь щедрым, но осторожным с злоупотреблениями», правило отсутствует, владелец отсутствует и интерфейс расплывчат. Замените это на лимит возврата, сигналы злоупотребления, порог уверенности и шаг ручной проверки для исключений.

Именно здесь возникает большинство проблем в AI‑первых продуктах. Подсказка может выглядеть умной, но система выполняет работу по политике, ответственности и интерфейсу не в том месте.

Некоторые команды решают это за день. Другим нужен внешний ревью, потому что рабочий процесс за годы стал запутанным. Если нужна вторая пара глаз — Oleg Sotnikov на oleg.is помогает стартапам и небольшим компаниям по архитектуре AI‑продуктов, инфраструктуре и практическому внедрению ИИ. Полезный первый шаг обычно простой: промапьте один рабочий процесс, уберите скрытые правила из подсказок и назначьте каждому рискованному решению ответственного.