Я такие системы искусственного интеллекта собираю не в теории. Сейчас у меня работает несколько живых систем на ИИ. Одна из них - контент-завод, который каждое утро сам предлагает мне темы, пишет по ним статьи и разносит их по каналам. Дальше - разбор на этом примере: из чего складывается система искусственного интеллекта, какие виды встречаются на практике и где она чаще всего ломается. Такие разборы я делаю регулярно и без причёсанной теории. Часть из них выходит в канале.

Что называют системой искусственного интеллекта

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

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

Отсюда практический вывод. Когда кто-то говорит, что внедрил ИИ, полезно спросить, что именно он имеет в виду. Речь идёт о подписке на чат с моделью или о системе, где модель встроена в конкретный процесс с входом и выходом. Стоимость и надёжность у этих двух вещей разная, и путать их дорого.

Почему одной модели почти всегда мало

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

Три ситуации, где одной модели недостаточно:

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

Из каких блоков складывается система искусственного интеллекта

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

  1. Источник - откуда система берёт входные данные: новости, заказы, темы, сообщения клиентов. Без источника система работает на пустом месте.
  2. Обработка - шаг, где модель что-то делает с данными: пишет текст, оценивает, классифицирует, генерирует изображение.
  3. Память - то, что переживает один запуск и переносится в следующий: база данных, файл, журнал решений. Без памяти система каждый день начинает с нуля.
  4. Действие - то, что система делает во внешнем мире: публикует пост, отправляет письмо, обновляет запись.
  5. Контроль человека - точка, где решение подтверждает владелец процесса, а модель только предлагает. Без этого блока ответственность за результат растворяется в системе, и спросить за неё оказывается не с кого.

Когда систему собирают без пятого блока, она рано или поздно сделает что-то, за что отвечать окажется некому. Дальше в статье - как я держу этот блок именно на контент-заводе.

Три вида систем, которые я держу в работе одновременно

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

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

Конвейер (пайплайн). Берёт поток данных на входе и на каждом шаге передаёт результат дальше, как цех на заводе. У меня это контент-завод - разбор ниже. Такой вид годится там, где вход однородный и повторяющийся: новости, заявки, отклики.

Личный агент с памятью. Ведёт диалог и помнит контекст между сессиями, вместо того чтобы обрабатывать поток. У меня это Джарвис. Закрыты фазы 0-8 и ступень 9.1: он принимает задачи текстом и голосом из Telegram, помнит прошлые сессии и подчиняется гейтам, через которые проходят его действия. Здесь важна непрерывность контекста с одним человеком, а пропускная способность вторична.

Продукт с генерацией внутри. ИИ встроен прямо в то, что продаётся клиенту. У меня это aimagenarium - SaaS-платформа AI-генерации изображений с монетизацией через внутренние кредиты. В таком виде экономику каждого запроса к модели считают наравне с качеством результата.

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

Как выглядит мой контент-завод изнутри

Коротко: контент-завод устроен как цепочка шагов от темы до публикации, и каждый шаг делает отдельный узел системы. Одного большого запроса к модели, который делает всё сразу, в этой цепочке нет.

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

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

Тексты по всей цепочке проходят через МОМОС-3 - отдельный слой, который следит, чтобы разные жанры звучали одним голосом, а не несколькими разными авторами.

В текущем состоянии системы 17 фич из 36 подтверждены рабочим прогоном, не просто написаны. При обычном прогоне 180 быстрых тестов проходят без ошибок. Часть фич сознательно ждёт моей проверки или доступа - это статус ожидания. Прогресс всей системы такими процентами не измеряется.

Метод, который не даёт частям завода мешать друг другу

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

Когда я сводил разные свои проекты по контенту в одну систему, был соблазн переписать всё заново одним монолитом. Решение оказалось другим. Цеха, которые уже прошли проверку на реальной работе - конвейер новостей об ИИ, инструменты каруселей, видеоферма, статейник - подключились к тонкому ядру как есть. Ядро отвечает только за реестр брендов, очередь материалов, одобрение, расписание, журнал и метрики. Всё содержательное живёт внутри цехов.

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

Голос канала: почему его измеряют, а не описывают

Коротко: вместо инструкции модели писать в определённом стиле, в заводе стиль каждого канала снимается с реальных постов и превращается в измеримые признаки. Только потом эти признаки становятся частью запроса к модели.

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

Где чаще всего ломаются системы искусственного интеллекта

Коротко: самая частая поломка - забытая точка контроля человека. Правило, которое живёт только в тексте инструкции агенту, превращается в пожелание вместо защиты.

У меня в работе действует принцип: там, где ошибка стоит денег, клиента или репутации, решение проверяет код по проверяемому признаку. Модель может быть источником сигнала, но окончательное решение принимает не она.

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

Урок шире одного завода. Важное правило проверяется на границе действия - тем, что смотрит на факт, а не на текст. Текст можно переформулировать и обойти неожиданным запросом. Проверку на границе, которая смотрит, кто именно нажал кнопку, обойти нечем.

Как проверить, что система работает, а не только выглядит рабочей

Коротко: то, что процесс запущен, и то, что он принёс результат - разные вещи. Путать их означает узнавать о поломке от клиента раньше, чем от собственной системы.

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

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

Пять ошибок, которые почти все совершают на первой системе

Коротко: большинство проблем на старте повторяются от проекта к проекту. Вот список, по которому можно сверить свою систему до того, как она подведёт в реальной работе.

С чего начать, если системы пока нет

Коротко: начинать стоит не с самой сложной задачи, а с одного узкого процесса. Он должен повторяться регулярно, и результат по нему легко проверить.

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

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

Источники

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