Архитектура корпоративного ИИ: 7 слоёв продакшена — от данных до эксплуатации

Архитектура корпоративного ИИ определяет, станет ли пилот промышленной системой или останется экспериментом.

ИИ сегодня используют все: кто-то пишет письма с помощью LLM, кто-то гоняет промпты, кто-то «прикрутил RAG», собрал ИИ-ассистента по корпоративной документации или на выходных разработал своего ИИ-агента. В переговорках и за кофе легко звучат названия моделей — кажется, что осталось только выбрать провайдера и нажать кнопку «Внедрить».

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

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

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

В статье разберём, как устроена корпоративная ИИ-система: из каких блоков она состоит и почему «просто развернём RAG» почти никогда не работает. Отдельно поговорим о workflow и оркестрации: как они помогают модели понимать, что от неё требуется, где запросить данные или подтверждение, где выполнить действие, а где остановиться, залогировать и эскалировать сотруднику.

Посмотрим по-новому на корпоративный ИИ: как на инженерное решение, где ИИ — лишь один из компонентов промышленной системы.

1. Модель – это не «All you need». Настоящая ценность в корпоративном ИИ — не в моделях, а в архитектуре вокруг них

2–3 года назад первые запросы «сделайте нам что-нибудь на ChatGPT» нас не сильно вдохновляли. Ведь мы давно и уверенно занимаемся сложными проектами анализа данных и машинного обучения, алгоритмами, строим промышленные корпоративные системы, а первые внедрения с использованием LLM были совсем простыми и всего этого не требовали. Часто они сводились к тому, чтобы сделать простой пользовательский интерфейс для промптов или загрузки файлов → вызывать чужую модель (например, Open AI и так далее) → показать ответ этой модели пользователю или где-то его сохранить.

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

Это хорошо работает как демо, но плохо — как корпоративная система.

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

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

Сначала ажиотаж вокруг LLM породил простой миф: вся магия — в гигантской модели, которая умеет всё. Достаточно «подключить нейросеть» и научиться писать промпты — всё заработает само. Практика же быстро отрезвляет: решает не модель, а то, как она встроена в контур данных и в бизнес-процессы. Сама по себе LLM в корпоративном контуре беспомощна.

Сегодняшние корпоративные LLM-проекты можно поделить на два класса — и разница между ними огромная.

• Первый класс — относительно простые сценарии работы с текстом: саммаризация, черновики писем, переформулировка, классификация коротких обращений. Здесь действительно можно аккуратно сформулировать задачу, добавить немного контекста — и готовая модель даст приемлемый результат. Системы вокруг почти нет: интерфейс → вызов модели → ответ. Это полезные решения, но по своей природе это простая обёртка вокруг LLM (они так везде и называются — LLM Wrappers).
• Второй класс — проекты, где системе нужно использовать знания и данные компании: регламенты, справочники и НСИ, карточки продуктов, историю обращений, статусы во внутренних системах, внутренние правила и ограничения. И вот здесь происходит неприятный сюрприз: 70–80% усилий уходит не на выбор и настройку модели, а на работу с данными и контуром управления — очистку и структурирование документов, проектирование базы знаний и НСИ, интеграции с источниками, разграничение доступа, аудит и эксплуатацию. Это не «магия нейросети», а привычная инженерия вокруг данных — всё как и раньше, но с LLM как новым компонентом в центре.

В этой статье — именно про второй. Про то, как устроена корпоративная ИИ-система в реальности, и почему наивная попытка «засунуть» все инструкции и данные в промпт — тупиковый путь, даже если в контекстное окно уже помещается миллион токенов (примеры можно посмотреть у нас в блоге).

Дальше в статье я разложу эту конструкцию по слоям: покажу, как выглядит базовая архитектура корпоративной ИИ-системы, где чаще всего всё ломается (спойлер: в данных, доступах и производительности), почему «одна LLM поверх всего» — плохая идея, и зачем нужны workflow — но уже без хайпа.

2. Архитектура корпоративного ИИ в промышленной эксплуатации: из чего состоит система

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

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

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

Слой 1. Источники данных и интеграции в архитектуре корпоративного ИИ

Модель сама по себе не знает ничего о компании. Всё, что делает систему полезной (не вообще, а именно для конкретной организации), приходит из интеграций с разными источниками данных: документов (регламенты, договоры, письма, инструкции), данных из корпоративных систем (CRM/ERP, справочники, заявки, статусы) и внешних источников (маркетплейсы, агрегаторы, нормативная документация, регуляторные требования).

На практике этот слой почти всегда включает в себя и первичную обработку данных: ETL/ELT для структурированных и неструктурированных источников, нормализацию, дедупликацию, разметку метаданными.

Основной вопрос здесь не технический («как подключиться»), а организационный: кто владелец данных, как часто они обновляются и кто отвечает за качество и достоверность. Если ответственность не определена, система начинает принимать решения на неактуальных данных — и если так произойдёт, то уже не важно, насколько хороша модель: она будет уверенно воспроизводить ошибки входных данных.

См. также:

• ETL/ELT и извлечение данных
• Консолидация данных
• Подготовка данных для анализа
• Подготовка AI-ready данных

Например, в кейсе работы с отзывами для косметической компании в качестве источников данных использовали карточки товаров на маркетплейсах, информацию из уроков, которые были записаны на видео, регламенты и инструкции в word и pdf, а также excel-таблицы с описанием состава и формул, структурированные данные из внутренних систем, а также много другой разнородной информации в разных форматах. А в кейсе по выделению сущностей из лабораторных исследований это были совсем другие документы, словари, приказы и клинические рекомендации Минздрава и т.д.

Слой 2. Контур знаний в архитектуре корпоративного ИИ

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

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

Многие компании «схлопывают» до ETL и хранилищ (включая векторные), но мы всегда выделяем его отдельно, потому что он отвечает не за факт хранения, а за управляемость: кто и за что отвечает, что считается актуальным, что допускается к использованию в ответах и при каких условиях.

Инвестиции в базу знаний, НСИ и процессы их актуализации — это способ «снять давление» с моделей: уменьшить требования к их размеру, упростить архитектуру решения и получить более управляемое, объяснимое поведение ИИ-системы

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

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

Слой 3. Retrieval и подготовка контекста (RAG, поиск, ранжирование) в архитектуре корпоративного ИИ

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

Главное — это подготовка контекста, то есть проектирование того, какой именно контекст видит модель в момент вызова.

• какие данные ей подать (фрагменты базы знаний, НСИ, прошлые сообщения, параметры пользователя);
• как эти данные найти, отфильтровать, почистить и преобразовать;
• как собрать их в один промпт: в каком порядке, с какими подсказками и ограничениями;

Даже при наличии источников и контура знаний система всё равно не «знает», что именно включить в контекст запроса к LLM.

В архитектуре корпоративного ИИ Retrieval/RAG — это не «векторное хранилище», а целый конвейер подготовки контекста под конкретную задачу и права доступа. Этот слой решает основную задачу RAG: выбрать правильные фрагменты данных и собрать их в контекст так, чтобы ответ был точным, не нарушал требования безопасности, и его можно было проверить.

1. Подготовка и индексация: документы разбиваются на осмысленные фрагменты (чанкинг) и индексируются.
2. Поиск: семантический или гибридный поиск находит кандидатов по смыслу (а не только по ключевым словам).
3. Ранжирование и фильтрация: результатов обычно больше, чем «помещается» в контекстное окно модели, поэтому выдача ранжируется и сжимается. Затем отсекается всё, что запрещено правами доступа и политиками.
4. Сборка контекста: фрагменты структурируются под задачу (факты, цитаты, поля, ограничения) и дополняются метаданными — чтобы ответ можно было проверить и понять, на основании чего он сформирован.

В реальных бизнес-задачах Retrieval почти всегда работает не только с текстом: подключаются структурированные данные (справочники, статусы), а при необходимости — мультимодальные источники (изображения, чертежи, видео) через VLM-компоненты. Дополнительно учитывается контекст сессии диалога для обогащения промпта.

Если контекст не найден совсем, или найден, но с низкой уверенностью, то включаются процессы уточнения/переформулирования промпта, расширение условий поиска, переключение на другой маршрут (например, эскалация к пользователю или вызов какого-либо специализированного инструмента).

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

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

Подробнее по теме RAG:

• Эмбеддинги и семантический поиск
• Graph RAG (RAG + граф знаний)
• Мультимодальная RAG и VLM
• Практический гайд: RAG на Llama 2 и FAISS
• Внедрение LLM в компании с использованием RAG

Слой 4. Оркестрация и workflow в архитектуре корпоративного ИИ

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

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

Например, в динамическом ценообразовании система не просто «предлагает цену», а выполняет операцию: собирает факты (остатки, ограничения, цены конкурентов), проверяет регламенты и лимиты, рассчитывает вариант, формирует обоснование и запускает дальнейшие шаги — от постановки задачи на согласование до обновления цены.

В таких сценариях система обычно:

• уточняет входные данные и недостающие параметры;
• извлекает факты из корпоративных систем и документов, а при необходимости — из разрешённых внешних источников;
• применяет правила и ограничения, выполняет расчёты и моделирование;
• формирует результат в нужном формате (карточка, таблица, отчёт, сравнение, прогноз, черновик ответа);
• инициирует действия (создать задачу, запросить КП, пересчитать цены, обновить данные на сайте и т.д.) — в пределах полномочий и политик.

Почему сложные процессы не укладываются просто в вызовы LLM

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

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

Зачем нужен явный слой workflow: оркестратор как каркас корпоративной ИИ-системы

На практике нужен явный слой с рабочими процессами (workflow) — оркестратор. Обычно оркестратор берёт на себя пять групп задач:

4.1) Управление шагами процесса

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

4.2) Вызовы моделей и инструментов в нужных точках

Оркестратор понимает, когда обращаться к базе знаний и данным, когда применять правила, алгоритмы и расчёты, а когда вызывать модели ML/LLM или сервисы. Модели используются там, где они действительно нужны, а не как универсальный механизм «на всё».

4.3) Участие сотрудников в процессе (HITL — Human-in-the-Loop)

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

Отдельный механизм этого слоя — двухшаговое подтверждение для рискованных операций:

• согласование ответственным (владельцем процесса/полномочий);
• правило двух проверяющих («две пары глаз») для критичных операций;
• ручная проверка и корректировка результата перед выполнением действия в системе.

4.4) Контроль действий и безопасность

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

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

Чтобы ИИ-агент не мог «делать что угодно», оркестратор выступает единой точкой управления: он проводит каждую операцию через регламент и правила процесса. На практике это означает:

• минимально необходимые права: раздельные роли/токены на чтение, запись и критичные операции;
• аварийная остановка: возможность отключить отдельные маршруты (и/или инструменты) без остановки всей системы.

4.5) Надёжность и воспроизводимость

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

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

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

Оркестратор — это каркас корпоративной ИИ-системы, в который «включены» модели, правила и интерфейсы. Пример самой простой цепочки выглядит так: «проверить права → найти данные → подготовить контекст → сформировать черновик → проверить → записать в систему → уведомить ответственного»

В кейсе с отзывами в этом слое реализовано следующее:

• Сбор и организация потока отзывов из разных маркетплейсов.
• Каждый отзыв проходит по жизненному циклу (новый → в работе → на согласовании → закрыт).
• Для каждого отзыва выбирает маршрут и режим обработки — ИИ / шаблон / вручную, задаёт приоритет и при необходимости включает эскалации.
• Исполнение шагов. По выбранному маршруту выполняются действия: черновик ответа → модерация → публикация (или передача в ответственное подразделение).
• Обработка исключений. Рискованные отзывы не уходят в автоматизацию: они переводятся на отдельный маршрут (эскалация), а не автоматическую публикацию сгенерированных ответов.

Важная часть этого кейса — Human-in-the-Loop. Определённые обращения проходят через сотрудника по цепочке:

1. модель выдаёт результат (классификация, выделенные сущности, черновик ответа);
2. оркестратор оценивает риск по порогам и правилам; при необходимости создаёт задачу в очереди на проверку;
3. сотрудник работает в специализированном пользовательском интерфейсе, где видит само обращение, предложение ИИ и может подтвердить, исправить, отклонить или эскалировать;
4. результат и правки логируются, а также могут попадать в датасет для последующего обучения.

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

«Идея «мы поставим одну большую модель on-prem и решим всё» выглядит хорошо только на слайдах. Нужна не модель сама по себе, а архитектура, в которой она встроена в контур знаний и управляется через оркестратор процессов»

Слой 5. Политики, безопасность и комплаенс

Если в архитектуре нет политик, система рано или поздно нарушит правила доступа: покажет лишнее, выполнит действие без полномочий или выведет данные во внешний контур. Такие ситуации не устраняются «улучшением промптов» — и заканчиваются инцидентом безопасности, аудитом и остановкой внедрения.

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

Чтобы этого не происходило, в слое безопасности обычно есть несколько обязательных компонентов:

• Аутентификация и авторизация — кто обращается к системе и какие у него права.
• Разграничение доступа — кто что может видеть, запрашивать и изменять (в т.ч. на уровне документа/фрагмента текста/записи).
• Фильтрация источников и контекста — какие данные разрешено использовать в ответе, а какие должны быть исключены или замаскированы.
• Аудит и трассировка — исходный запрос, выбранный маршрут, поданный контекст, источники/метаданные, результат и причины блокировок.
• Работа с чувствительными данными — DLP, маскирование, правила обработки персональных и коммерчески чувствительных сведений.
• Политики периметра — когда допустимы внешние API, а когда требуется on-prem; какие данные можно выводить за пределы компании и в каком виде.
• Политики поведения и контроль действий — что модель может говорить и делать, какие источники допустимы, какие действия требуют подтверждения (особенно при вызове инструментов), а какие должны блокироваться.

Вывод простой: безопасность в корпоративном ИИ должна быть встроенной, а не добавленной «поверх» системы.

Слой 6. Эксплуатация: качество, управление потоками, стоимость

Если коротко: в демо нам важно «чтобы модель правильно отвечала». В промышленной эксплуатации важнее другое — чтобы модель отвечала предсказуемо, объяснимо и за разумные деньги. И чтобы после любой правки (данных, правил, промптов, модели) мы понимали: стало лучше или хуже — и почему.

6.1) Качество

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

Можно оценивать качество в трёх плоскостях:

1. Способность завершать рабочие сценарии end-to-end.
   Важно проверять выполняет ли система процессы целиком: например, «обработать возврат», «создать заявку», «подготовить ответ клиенту по внутренним правилам».
   Метрики: доля успешно завершённых сценариев; доля сценариев, где потребовалось вмешательство сотрудников; типовые точки сбоев по шагам.
2. Опора на источники компании (а не на «общие» рассуждения).
   Ответ должен опираться на базу знаний и контекст организации: юридическая система — на реальные договоры и политики, клиентский сервис — на актуальные регламенты и условия обслуживания.
   Метрики: доля ответов с корректными ссылками на источники; доля утверждений без опоры на источники; доля случаев, когда система должна сказать «не знаю» и запросить уточнение или выполнить эскалацию на ответственного сотрудника.
3. Устойчивость к изменениям и контроль ухудшения.
   Любая правка в системе — это изменение поведения. Важно измерять влияние обновлений и не допускать ситуации, когда «незаметная мелочь» ухудшила качество.
   Метрики: сравнение качества «до/после» по одним и тем же контрольным сценариям и наборам; автоматические «стоп-сигналы» при деградации.

Далее — практические типовые показатели, которые стоит фиксировать как на контрольных наборах (до релиза), так и по выборке из реальных запусков (в промышленной эксплуатации):

• Качество ответа: точность и полнота (хотя бы на контрольных примерах), доля ответов «не знаю», доля ответов, которые сотруднику пришлось править, типовые ошибки и их частота.
• Качество извлечения информации: сколько релевантных фрагментов удалось найти, насколько часто поиск покрывает нужные случаи, сколько материалов было исключено из-за прав доступа, насколько стабильны результаты поиска, нет ли ухудшений по времени ответа.
• Пользовательский опыт: удовлетворённость пользователей, время до получения результата, как часто пользователи задают уточняющие или повторные вопросы (если переспрашивают — значит, в контекст попали не те данные).

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

6.2) Потоки и трассировка — чтобы можно было объяснять сбои

Что нужно логировать по каждому запуску:

• какой маршрут выбрали и почему;
• какой контекст подали модели (ссылки, цитаты, метаданные, что отфильтровали);
• какие инструменты вызвали и что они вернули;
• как сработали политики (что запретили, что замаскировали, где потребовали подтверждение);
• время по шагам и итоговый результат.

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

По логам должно быть можно воспроизвести запуск: фиксируем идентификатор запроса и версии моделей/промпта/индекса

6.3) Стоимость — чтобы система бездумно не «потратила» средства сверх бюджета на токены после масштабирования

Если в системе используется коммерческая LLM, неприятный сюрприз часто выглядит так: в пилоте всё кажется недорогим, а затем подключаются 500–2000 пользователей — и расходы начинают расти нелинейно. Причём растёт не только количество токенов, но и стоимость «обвязки» вокруг модели: поиск, ранжирование, вызовы инструментов и внешних сервисов. В workflow это особенно заметно, потому что один запрос пользователя может превращаться в цепочку действий и вызовов разных моделей и сервисов.

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

Практически почти всегда помогают:

• маршрутизация по «ценовым уровням»: сначала более дешёвые шаги и модели, а эскалация на дорогие — по понятным условиям (низкая уверенность, сложный кейс, высокая цена ошибки);
• ограничение «разрастания» сценариев ИИ-агентов: контроль длины контекста и числа вызовов инструментов, отказ от лишних шагов, ранний выход, когда результат уже достаточен;
• регулярная проверка стоимости на тех же контрольных сценариях, что используются для качества: после каждой правки важно видеть не только «стало лучше или хуже», но и «стало дороже или дешевле».
• кэши и повторное использование результатов там, где это допустимо (семантический кэш ответов, кэш выдачи поиска, кэш результатов инструментов);

6.4) Регрессии и версии

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

Практический минимум:

• регресс-тесты ключевых цепочек (те самые end-to-end сценарии, по которым система принимается в промышленную эксплуатацию);
• версионирование данных, индексов, правил, промптов и моделей, чтобы всегда было понятно, «что именно изменилось»;
• сравнение качества и стоимости «до/после» на одном и том же наборе кейсов;
• стоп-сигналы — заранее заданные пороги, при достижении которых релиз не проходит проверку и требуется откат к предыдущей версии, если метрики ухудшились (например, упала доля успешно завершённых сценариев, выросла доля ответов без опоры на источники, нарушились политики доступа или выросла стоимость);
• возможность быстро «откатиться» на предыдущую стабильную конфигурацию, если сработал стоп-сигнал.

Слой 7. Пользовательские интерфейсы и управление

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

7.1) Каналы: где пользователь работает с системой

Важно, чтобы ИИ был там, где уже сейчас выполняются процессы:

• специально разработанные пользовательские интерфейсы для каждой роли. Пример такой реализации можно посмотреть в нашем кейсе
• мессенджер — самый быстрый и недорогой способ встроить ИИ в работу без отдельного интерфейса: сотрудник задаёт вопрос прямо в мессенджере, ИИ-агент выполняет запрос к данным и возвращает результат в нужном формате (текст, таблица, диаграмма, PDF). Пример кейса в Telegram: Как научить AI-агента отвечать на вопросы
• Формы/виджеты внутри корпоративных систем (например, Service Desk, CRM, ERP, портал закупщика, общекорпоративные порталы и т.д.),
• API для интеграций и встраивания в существующие интерфейсы,
• Голосовые интерфейсы — только если это оправдано сценарием (например, колл-центр или работа «в поле», на выездах).

Идея в том, чтобы удобно для пользователя встроить ИИ в привычный контур работы.

7.2) Управляющие интерфейсы: как мы «встраиваем ИИ в регламенты»

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

• Подтвердить/отклонить и уровни согласования;
• Статусы и маршрут процесса (что сейчас происходит и что будет дальше);
• Объяснимость: источники/цитаты/«почему так», чтобы можно было доверять и проверять;
• Настройка правил и шаблонов без привлечения ИТ-разработчиков (чтобы владельцы процесса сами меняли логику);
• Эскалация к сотруднику / Сотрудник в контуре (HITL): когда система не уверена или риск высокий, она должна уметь передать кейс ответственному сотруднику.

7.3) Промпты и память — тоже часть управления

• Библиотека промптов — библиотека шаблонов с версиями, владельцами и регресс-тестами;
• Память — управляемая память диалога (что сохраняем, где храним, кто имеет доступ, когда очищаем).

7.4) Связать технические метрики с эффектом на бизнес

Технические метрики (задержка с ответом, токены, ошибки) хороши, но бизнесу нужны свои:

• качество: доля ответов без правок, доля эскалаций;
• эффективность: время цикла процесса, скорость обработки очереди;
• риски: попытки доступа к запрещённым источникам, срабатывания политик;
• стоимость: цена операции/кейса.

3. Архитектура корпоративного ИИ на примере прикладного кейса

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

У нас получилась система, похожая на Service Desk, только для ответов на отзывы: весь поток отзывов из Ozon, WB и других площадок собирается в единую очередь («Лента отзывов»), оператор открывает карточку — и в большинстве случаев уже видит черновик ответа, который система подготовила по правилам, стилям и базе знаний. Сложные и рискованные случаи уходят на маршрут обработки вручную, а критичные обращения попадают в приоритетную очередь и обрабатываются по SLA.

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

Как эта система устроена:

1. Источники. Поток отзывов из маркетплейсов → единая очередь для операторов; плюс данные о товарах/ассортименте и контент, на который должны опираться ответы.
2. Контур знаний. Управляемая база знаний и справочники: карточки товаров, инструкции, FAQ, словари формулировок, политики, информация о составе/ограничениях; обновления в продуктах и правилах вносятся через знания, без дообучения модели.
3. Retrieval (подготовка контекста). Для каждого отзыва подтягиваются релевантные факты о товаре + применимые правила маршрутизации/ограничения; рискованные темы помечаются и выводятся из режима автоматической генерации ответа.
4. LLM. Генерирует черновик на основе текста отзыва и данных из базы знаний, строго в настроенном стиле. Стили создаются в модуле «AI Стили»: промпт с требованиями к тону, юридической точности, реакциям на негатив и упоминания медицинских тем; выбирается модель и параметры (температура и т. п.). Всё настраивается в специально для этого разработанном пользовательском интерфейсе.
5. Оркестрация (workflow). Очередь + карточка + статусы + массовые операции; правила маршрутизации (какой маршрут и стиль применить), шаблоны для типовых сценариев и ветки процесса для подготовки ответов вручную сотрудником для сложных случаев; отправка в профильные подразделения (R&D/качество/сервис) и приоритизация критичных обращений по SLA.
6. Безопасность и комплаенс. Встроены ограничения: стоп-слова и чувствительные темы, недопустимые формулировки с точки зрения бренда и юридических рисков; такие отзывы переводятся в маршрут на обработку оператором. Эти правила и термины задаются в справочниках.
7. Эксплуатация. Аналитика и дашборды по доле ответов, времени реакции, темам/тональности, загрузке и эффективности; плюс бизнес-метрики результата (скорость ответа, SLA для критичных, управляемость через правила/стили/знания).

4. Заключение

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

Есть идея для автоматизации? Запишитесь к нам на демонстрацию, и мы покажем, как встроить ИИ в бизнес-процессы.