Когда компании поручают «прикрутить ИИ», обсуждают модель. Какую взять, чем она лучше соседней, что там с контекстным окном.
Модель при этом самая маленькая часть работы. Это один узел внутри обычной системы, у которого есть неудобное свойство: он вероятностный. На один и тот же вход он дважды отвечает по-разному, иногда отвечает валидным JSON с выдуманным номером договора, а иногда не отвечает сорок секунд и потом отдаёт пятисотку.
Фичей его делает то, что стоит вокруг. Это и есть работа.
Что стоит вокруг модели
Разберём по частям, потому что каждая из них отдельно решает, доедет фича до прода или нет.
Контракт ответа. Что именно система ждёт от модели, описанное схемой, а не надеждой. И решение о том, что делать с ответом, который схему прошёл, а смысла не имеет.
Граница модели. Какую часть задачи вообще нельзя отдавать вероятностному узлу. Арифметику, идентификаторы, права доступа, деньги. Каждый кусок, вынесенный обратно в код, это минус стоимость, минус задержка и минус источник галлюцинаций.
Поведение при отказе. Провайдер молчит, отвечает ошибкой, поменял версию модели без предупреждения. Ретрай, который спасает, отличается от ретрая, который утраивает счёт, ровно одним условием в коде.
Бюджет. Не цена тысячи токенов, а стоимость одного обращения вашего пользователя и поведение системы двадцатого числа, когда месячный лимит кончился. Разбор счёта по статьям отдельно.
Проверка качества. Обычные тесты не работают там, где два одинаковых запуска дают разный ответ. Нужен набор размеченных случаев и порог, ниже которого версия не выкатывается, плюс метрика, записанная до начала работы, а не подобранная потом под удобный результат.
Логи. Такие, чтобы через месяц объяснить клиенту, почему система приняла именно это решение, и найти, что поменялось между версиями.
Посмотрите на этот список ещё раз. Очереди, ретраи, контракты, бюджеты, наблюдаемость: это не «AI». Это обычная бэкенд-инженерия, которой я занимаюсь пятнадцать лет. Новизна только в характере узла, который она теперь обслуживает.
Почему у команд это ломается
Меня зовут в проекты, где пилот показали, а он не поехал. Причины повторяются от компании к компании настолько, что их можно перечислять до знакомства с кодом.
Демо собирали на трёх примерах, и на трёх примерах модель была права. Границу не проводили, поэтому модель считает суммы и придумывает артикулы. Стоимость обращения никто не считал до запуска. Проверять качество нечем, поэтому спор «стало лучше или хуже» решается голосом самого уверенного участника. Логов нет, поэтому инцидент нельзя разобрать, а только пересказать.
Ни один из пунктов не про интеллект команды. Это отсутствие общего корпуса знаний: каждый проходит один и тот же отрезок в одиночку и наступает на те же грабли в том же порядке.
Что к этому добавляется у нас
Часть ограничений локальная, и в англоязычных материалах её нет.
152-ФЗ определяет, какие данные можно отправить в модель и куда именно, и это меняет не текст политики, а архитектуру: где стоит обезличивание, что уходит наружу, что остаётся внутри контура.
Выбор модели у нас решается не бенчмарками, а доступностью, способом оплаты и ценой на вашем объёме. Российские провайдеры это отдельная реальность со своими лимитами и своим поведением при отказе.
Зарубежный гайд об этом не напишет: для его автора такой проблемы не существует.
Читать есть что, но вразброс
Говорить «по-русски читать нечего» нечестно, материалов хватает. Проблема в другом: каждый источник закрывает свой участок пути.
- Документация провайдеров описывает параметры запроса. Про поведение вашей системы, когда ответ пришёл валидный и бессмысленный, там нет ни слова.
- Разборы на Хабре берут один этап: то агентов, то observability, то оценку качества. Между этапами разрывы, и авторы разные, с разными допущениями.
- Материалы вендоров написаны про свою модель. Это полезно и неизбежно однобоко.
- Курсы «чат-бот за выходные» заканчиваются ровно там, где начинается работа.
Чего нет, так это одного корпуса, который ведёт фичу по всему жизненному циклу и учитывает наши ограничения. Собрать его из перечисленного можно, но каждый инженер сшивает его заново, тратя недели на маршрут, который уже кто-то прошёл.
Где это собрано
AI Builders это открытый учебник о LLM в backend и разобранные системы под ним. Бесплатно, без регистрации и без письма на почту за PDF.
Единица здесь не участник, а разобранная система. На витрину она попадает на пяти условиях: публичный разбор, названный рабочий процесс, контур с моделью в одном узле, числа, которые автор видел сам, и список того, чего в системе нет. Без любого пункта запись не публикуется.
Сейчас на витрине три моих системы, и все три прототипы, а не прод. Так и написано на них самих.
Aginx собирает вертикальный ролик из брифа примерно за пять минут и примерно за 250 ₽; нет очереди, потолка стоимости прогона, централизованных логов и подтверждения перед платной генерацией. LeadForge держит очередь лидов, где модель предлагает формулировку, вес считает код, а решение принимает человек; отправка ручная, состояние закрытая бета. Тренажёр переговоров гоняет 78 сцен со скрытой картой персонажа и шестью шкалами оценки, зашитыми в код, а не в файл сцены.
Впечатляющий масштаб не нужен. Telegram-бот на 120 запросов в день с посчитанной стоимостью обращения и честным «evals пока нет» подходит полностью. Не подходит система, про которую нельзя показать ни чисел, ни пропусков. Если у вас такая есть, покажите её.
Учебник «AI/LLM-интеграции: от вызова модели до работающей фичи» дописан: десять частей, все 58 глав открыты и правятся по замечаниям читателей. Он ведёт ровно по тому маршруту, который описан выше: от вопроса «нужна ли здесь модель» через контракты и границы к проверке качества и эксплуатации.
Через все части проходит шкала зрелости. Она называет состояние системы, а не стаж человека, и проверить свою фичу можно за минуту:
- Идея. Умеет ли система вызвать модель и получить текст?
- Протокол. Завёрнут ли вызов в сервис, который переживает ошибку и отдаёт ответ потребителю?
- Тест. Где в этой фиче модель не нужна, а вы её всё равно ставите?
- Прод. Может ли команда показать контекст, контракт, evals, fallback, бюджет, правила безопасности и логи одной версии?
Первый вопрос, на который ответ «нет», и есть точка входа в учебник. Подробнее про маршруты: карта по уровням.
Как выглядит решение, а не декларация
Один пример из Aginx, чтобы было видно, о чём вообще речь.
Модель возвращает сценарий ролика. Дальше код перезаписывает всё, чему доверять нельзя: формат берётся из брифа, голос из конфига, общую длительность пересчитывает сумма сцен. Арифметике модели веры нет.
И отдельное решение про порядок шагов: озвучка идёт первой. Если TTS упал, платная видеогенерация не стартует. Дешёвая операция проверяет дорогую, а не наоборот.
Это две строчки в контроллере пайплайна, и именно они отделяют «работает» от «на счёте минус тысяча рублей за ролики, которых никто не увидит». В таких строчках лежит вся тема.
Чего в этом нет
Устройства трансформера. Для этого есть учебники получше, и я их не заменю.
Обещания, что после прочтения ваш пилот доедет до прода. Это зависит от процесса, данных и готовности компании менять то, что сейчас держится на одном человеке, который додумывает контекст руками.
Если ваша фича застряла
Я встраиваю ИИ в существующие бэкенды за деньги. Начинается это с диагностики: пять рабочих дней, 90 000 ₽, на выходе разбор вашего контура, названные границы модели, посчитанная стоимость обращения и список того, чего в системе нет.
Диагностика может закончиться выводом «здесь модель не нужна». Это результат, а не провал: он стоит 90 000 ₽ и экономит бюджет внедрения, которое вам не требуется.
Что я приношу в проект, видно заранее и без разговора со мной: тот же учебник, те же разборы, те же списки пропусков в собственных системах. Самая честная витрина, которую я могу построить, это контур с числами и с тем, чего в нём не хватает.
Если же вы не заказчик, а инженер, который сам тащит такую фичу: читайте главы, показывайте систему и приходите в канал @ai_builders_ru. Возражение по существу ценнее лайка: оно попадает в текст, который прочитают следующие.
