От промпта к продукту: как превратить LLM в реальные приложения
Методология практика для создания LLM-приложений: оценки, ограничители, бюджеты задержки и стоимости, участие человека и понимание того, что не стоит автоматизировать.
Автор Vitor Lima
Промпт, который работает в песочнице, — это демо, а не продукт. Именно в разрыве между этими двумя вещами тихо умирает большинство ИИ-проектов. Создание LLM-приложений, которые выдерживают реальных пользователей, куда меньше зависит от хитрых промптов, чем можно подумать по демонстрациям, и куда больше — от обычной инженерной дисциплины. Мы выпустили таких приложений достаточно — Youp, MadaiOps, а теперь и Linea, — чтобы иметь мнение о том, что на самом деле закрывает этот разрыв. И ничего из этого не выглядит гламурно.
Ловушка в том, что первая версия ощущается завершённой. Вы вставляете хитрый промпт, модель возвращает что-то впечатляющее, и возникает соблазн обернуть это в интерфейс и назвать запуском. А потом приходят реальные пользователи с вводными данными, которых вы и представить не могли, модель уверенно выдаёт что-то неправильное, и вы обнаруживаете, что у вас нет способа понять, стало ли от вашего исправления лучше или хуже. Эта статья — о тех подпорках, которые превращают то самое впечатляющее демо в нечто, что можно запустить в продакшене и спокойно спать по ночам.
Начинайте с оценок, а не с промптов
Самое ценное, что можно построить на раннем этапе, — это набор для оценки. Не бенчмарк, не лидерборд, а папка с реальными вводными данными в паре с тем, как выглядит хороший результат. Двадцать примеров лучше, чем ноль, а пятьдесят тщательно отобранных — лучше тысячи собранных наугад.
Причина проста. Как только у вас есть оценки, инженерия промптов перестаёт быть вопросом ощущений. Вы меняете строку, прогоняете набор, наблюдаете, как двигается число. Без них каждая правка — это суеверие. Мы видели, как команды тратили неделю на улучшение промпта, только чтобы получить регрессию на случаях, которые они решили ещё месяцы назад, потому что ничто не измеряло случаи, на которые они не смотрели.
Несколько убеждений, которых мы твёрдо придерживаемся:
- Оценивайте по результатам, а не по формулировкам. Для всего структурированного — извлечения, классификации, маршрутизации — проверяйте разобранный результат, а не сходство строк. Для свободного текста подойдёт LLM-в-роли-судьи с жёсткой рубрикой, но сначала проверьте судью на горстке человеческих меток, иначе вы просто измеряете вкус одной модели.
- Ведите файл регрессий. Каждый сбой в продакшене становится постоянным тест-кейсом. Именно так ваш набор оценок остаётся честным — он растёт ровно в тех направлениях, куда его толкает реальность.
- Версионируйте оценки вместе с промптами. Промпт без своего набора оценок — это непротестированное изменение кода.
Если вы построите что-то одно из этой статьи, постройте это. Всё, что идёт дальше по цепочке, зависит от возможности ответить на вопрос: стало ли от этого лучше?
Ограничители дешевле, чем извинения
Модели ошибаются так, как обычное ПО не ошибается. Они выдумают несуществующий API, согласятся с ложной предпосылкой пользователя или выдадут правдоподобно выглядящий JSON с галлюцинированным полем. Ограничители — это тот слой, который ловит это до того, как оно доберётся до пользователя или, что хуже, до шага исполнения.
Мыслите в трёх позициях.
- Входные ограничители отклоняют или очищают до запуска модели: проверка на внедрение промптов, скрытие персональных данных, фильтрация не по теме.
- Выходные ограничители проверяют то, что вернулось: валидацию схемы, проверку обоснованности цитат, фильтры политик.
- Ограничители действий стоят между моделью и всем, что имеет побочные эффекты.
Именно в третьем и живёт настоящий риск. В Linea, наших агентах для автоматизации рабочих процессов, модель может предлагать действия — вызвать API, переместить запись, отправить сообщение. Предложение и исполнение — намеренно разные шаги. Каждое значимое действие проходит через типизированный контракт и проверку политики, прежде чем что-либо запустится, а разрушительные или необратимые действия требуют явного подтверждения. Агент, предлагающий неправильное, — это проблема UX, которую можно итеративно улучшать. Агент, делающий неправильное, — это инцидент. Держите эти два режима сбоя по разные стороны жёсткой границы.
Категоричная версия: валидируйте структурированный вывод по схеме и повторяйте попытку при сбое, а не доверяйте модели быть последовательной. И никогда не позволяйте сырому выводу модели быть тем, что запускает необратимое действие. Всегда ставьте между ними детерминированную проверку.
Планируйте задержку и стоимость как функции
Задержка и стоимость — не то, что вы измеряете в конце. Это ограничения, под которые вы проектируете с самого начала, потому что они меняют архитектуру, а не только счёт.
Задайте явные бюджеты на каждое обращённое к пользователю действие: целевую задержку p95 и потолок стоимости на вызов. Как только это записано, проектные решения становятся проще. Несколько паттернов, к которым мы обращаемся снова и снова:
- Подбирайте размер модели под каждый шаг. В большинстве конвейеров есть один-два шага, которым по-настоящему нужна фронтирная модель, и несколько таких, с которыми прекрасно справится модель поменьше и побыстрее. Направить простую классификацию на дешёвую модель, а дорогую приберечь для трудного шага рассуждения — это оптимизация с наивысшей отдачей из доступных, и обычно она заодно улучшает задержку.
- Стримьте первый токен. Для всего разговорного воспринимаемая задержка определяется временем до первого токена. Стримящийся ответ, который занимает четыре секунды, ощущается лучше, чем блокирующий, который занимает две.
- Кэшируйте агрессивно. Кэширование промптов на стабильном системном контексте, обычное кэширование результатов на повторяющихся вводных. Значимая доля продакшен-трафика — это почти дубликаты.
Компромисс, который стоит держать в голове: более крупные модели снижают ваши инженерные усилия, но навсегда повышают предельную стоимость и задержку. Более дешёвые модели перекладывают работу на вас — больше заботы о промптах, больше ограничителей, больше оценок, — но эта работа является разовой тратой против постоянной экономии. Для всего, что имеет объём, вкладывайтесь в инженерию.
Держите человека в цикле — намеренно
«Человек в цикле» произносят так часто, что фраза перестала что-либо значить. Сделанное хорошо, это не запасной вариант на случай сбоя ИИ — это спроектированное разделение труда. Вопрос не в том, включать ли человека, а в том, где суждение человека стоит больше, чем задержка, которую оно добавляет.
Паттерн, который служил нам лучше всего, — это эскалация с порогом уверенности. Система автоматически обрабатывает уверенное большинство и направляет неуверенное меньшинство человеку, приложив рассуждения модели, чтобы человек принимал решение за секунды, а не за минуты. В MadaiOps операции с заказами в пределах нормальных параметров проходят насквозь; всё аномальное всплывает перед оператором с контекстом, а не исполняется молча. Проверяющий не нянчится с машиной. Он тратит своё внимание только там, где оно дефицитно и ценно.
Ещё одно правило: фиксируйте исправления человека и возвращайте их в набор оценок и в промпты. Система с человеком в цикле, которая не учится у своих людей, просто платит дважды за одну и ту же работу.
Знайте, что не стоит автоматизировать
Самое трудное суждение в этой дисциплине — сдержанность. Не всякую задачу стоит отдавать модели, и зрелость — это умение понять, какие оставить в покое.
Наш грубый тест: автоматизируйте там, где цена ошибки низка или ошибку легко обнаружить и обратить. Черновики, резюме, извлечение, классификация, маршрутизация — хорошие кандидаты. Неправильный черновик правят; неправильное резюме ловят при чтении. Будьте гораздо осторожнее там, где ошибки дороги, трудно обнаруживаются или необратимы: всё, что двигает деньги, отправляет неотзываемое сообщение или принимает юридическое либо медицинское решение. Там место модели — во вспомогательной роли: показывать варианты, готовить черновики на проверку, а не сидеть за рулём.
Черта, которой мы держимся: если вы не можете описать, как вы поймаете модель на ошибке, вы не готовы автоматизировать этот шаг. Способность обнаружить сбой — вот настоящее условие, более важное, чем точность. Шаг с точностью 95%, который можно полностью проверить, безопаснее выпускать, чем шаг с точностью 99%, который проверить нельзя.
Форма работы
Превращение промпта в продукт — это в основном негламурная часть: оценки, чтобы можно было измерять; ограничители, чтобы сбои оставались локализованными; бюджеты, чтобы оставалось быстро и доступно; люди, размещённые там, где суждение важно; и дисциплина оставить кое-что неавтоматизированным. Модель — это, может быть, двадцать процентов системы. Остальные восемьдесят — это инженерия, которая делает её редкую гениальность безопасной для того, чтобы на неё полагаться.
Хорошая новость в том, что это привычная работа. Она вознаграждает те же инстинкты, что делают хорошим любое ПО: измеряй, прежде чем менять; ограничивай радиус поражения; уважай время своих пользователей. Модель — новая. Ремесло — нет.