Основная сложность в разработке ИИ-систем не в том, чтобы получить работающую демонстрацию. Прототип RAG-помощника собирается за день, и в 80% случаев он выглядит убедительно. Сложность в том, что от прототипа до системы, которая держит реальную нагрузку, не выдумывает фактов и не разоряет на токенах, лежит основной объём инженерной работы: подготовка корпуса, стратегия чанкинга, гибридный поиск, реранкинг, набор для оценки качества, обработка отказов, наблюдаемость, контроль расходов.
Я веду проекты на всех этих этапах — от постановки задачи и выбора архитектуры до развёртывания в продакшене и сопровождения. Работаю удалённо с клиентами по всей России.
Ниже — что именно и как я делаю. Если вы пока на стадии «непонятно, нужен ли нам ИИ и где», начинать логичнее с аудита процессов.
Архитектуры, с которыми работаю
Выбор архитектуры определяется характером задачи. Ниже — основные классы решений и то, что реально приходится решать в каждом.
RAG-системы (ответы по корпусу документов)
Подходит, когда система должна отвечать строго по вашим материалам — регламентам, документации, базе знаний, накопленной переписке — с возможностью проверить источник ответа.
Что входит в разработку RAG-системы помимо самой связки «поиск + модель»:
Подготовка корпуса. Извлечение текста из исходных форматов с сохранением структуры: PDF с многоколоночной вёрсткой, сканы через OCR, таблицы, документы с иерархией разделов. Это обычно самая недооценённая часть — качество извлечения задаёт потолок качества всей системы.
Стратегия чанкинга. Разбиение по фиксированному размеру работает плохо на структурированных документах. На практике использую разбиение по семантическим границам и по иерархии заголовков, с перекрытием и с сохранением родительского контекста в метаданных чанка. Для документов с таблицами и списками — отдельная обработка, чтобы не разрывать смысловые единицы.
Гибридный поиск. Только векторный поиск проваливается на точных совпадениях — артикулах, номерах документов, специфических терминах. Только BM25 проваливается на переформулировках. Рабочий вариант — комбинация плотного и лексического поиска с объединением результатов, обычно через reciprocal rank fusion.
Реранкинг. Отдельная модель переоценивает выдачу первичного поиска. Один из самых заметных по эффекту шагов: позволяет доставать топ-30 кандидатов быстрым поиском и отдавать в контекст только 3–5 действительно релевантных, что улучшает и качество ответа, и расход токенов.
Фильтрация по метаданным. Разграничение доступа на уровне поиска — сотрудник получает ответы только по документам, к которым имеет доступ. Актуальность: исключение устаревших редакций документов из выдачи.
Обработка отказа. Что система делает, когда релевантных документов не найдено. Порог по скору, явный ответ «в базе нет информации», передача человеку. Без этого модель начнёт отвечать по общим знаниям — это главный источник претензий к RAG.
Цитирование. Привязка утверждений в ответе к конкретным фрагментам источника, чтобы ответ можно было проверить.
Обновление индекса. Инкрементальная переиндексация при изменении документов, а не полная пересборка. Отслеживание версий.
Для сложных корпусов дополнительно применимы: контекстуальное обогащение чанков перед индексацией, переформулировка запроса, разложение сложного вопроса на подзапросы, графовые подходы для документов с сильной связностью между сущностями.
ИИ-агенты
Агент отличается от диалогового бота тем, что выполняет действия: обращается к системам, читает и изменяет данные, запускает процессы. Разработка ИИ-агентов — принципиально другой класс задач по требованиям к надёжности, потому что ошибка меняет данные, а не только текст.
Что прорабатывается:
Определение инструментов. Описание функций, доступных агенту, со строгими схемами параметров. Качество описаний напрямую определяет корректность вызовов — это фактически часть промпта, а не техническая формальность.
Цикл рассуждения. Схемы вида ReAct или планирование с последующим исполнением, в зависимости от задачи. Ограничение числа итераций, обнаружение зацикливания, обработка ситуации, когда агент не может достичь цели.
Разграничение прав и подтверждения. Явное деление действий на выполняемые автономно и требующие подтверждения человеком. Для необратимых операций — обязательное подтверждение, для чтения — автономно. Изоляция исполнения инструментов, чтобы агент не мог выйти за границы разрешённого.
Идемпотентность и откат. Что происходит при сбое на середине цепочки действий. Повторный вызов не должен создавать дубликаты записей.
Память. Краткосрочная в рамках сессии, долгосрочная между сессиями с явным управлением тем, что сохраняется. Сжатие истории при длинных диалогах вместо простой обрезки.
Подключение через MCP. Где применимо — использую Model Context Protocol как стандартизованный способ подключения инструментов и источников данных, что упрощает замену модели и переиспользование интеграций между проектами.
Мультиагентные схемы. Когда задача разбивается на роли — планировщик, исполнители, проверяющий. Применяю осторожно: мультиагентная система заметно дороже в токенах и сложнее в отладке, и часто одна хорошо спроектированная цепочка работает надёжнее.
Извлечение структурированных данных
Задачи вида «из письма, счёта, спецификации или анкеты получить набор полей». Отдельный класс, где важна не креативность модели, а гарантия формата.
Использую жёсткие JSON-схемы и режим структурированного вывода, где модель физически не может вернуть невалидный ответ. Дополнительно — валидация значений на уровне схемы, обработка отсутствующих полей, флаг уверенности для полей, требующих проверки человеком.
Для документов со сложной вёрсткой — предварительный разбор структуры страницы (layout parsing) до передачи в модель, иначе таблицы превращаются в кашу. Для сканов — OCR с последующей проверкой.
Классификация и маршрутизация
Классификация обращений, заявок, отзывов, документов по темам и приоритетам. Часто не требует большой модели: маленькая модель или даже классический классификатор на эмбеддингах решает задачу дешевле и быстрее, с более предсказуемым качеством.
Здесь я обычно отговариваю от LLM в тех случаях, где хватает более простого инструмента: обработка миллиона обращений большой моделью — это счёт, который никто не планировал.
Пайплайны обработки документов
Многошаговые сценарии: получить документ → распознать → извлечь поля → сверить с базой → при расхождении уведомить → при совпадении внести в систему. Собираются как процесс с явными состояниями, обработкой ошибок на каждом шаге, очередями и возможностью повторить обработку.
Для оркестрации использую платформы автоматизации (n8n и аналоги) там, где это оправдано, и собственный код там, где требуется контроль над логикой и производительностью.
Дообучение моделей
Отдельно — потому что просят чаще, чем нужно.
Дообучение (LoRA / QLoRA) оправдано в узком наборе случаев: нужен устойчивый специфический формат вывода, требуется существенное удешевление за счёт замены большой модели на маленькую дообученную, или задача узкая и хорошо покрыта данными.
В большинстве случаев то, что заказчик хочет получить дообучением, достигается через RAG, качественный промпт и few-shot примеры — быстрее, дешевле и без необходимости переобучать при каждом изменении данных. Дообучение не добавляет модели знаний о ваших документах; для этого нужен поиск по ним.
Если дообучение действительно нужно, это включает сбор и разметку датасета, выбор базовой модели и метода, обучение, сравнение с базовой линией на отложенной выборке, развёртывание.
Развёртывание и инфраструктура
Облако или своя инфраструктура
Решение принимается по требованиям к данным, объёму нагрузки и бюджету, а не по предпочтениям.
Облачные API (ChatGPT, Claude, Deepseek и пр.) — быстрый старт, лучшее качество на сложных задачах, оплата по факту. Ограничения: передача данных вовне, зависимость от доступности и тарифов поставщика, лимиты по скорости.
Российские сервисы (YandexGPT, GigaChat) — размещение данных в РФ, оплата в рублях, отсутствие проблем с доступом. Компромисс по качеству на сложных задачах, но для большинства прикладных сценариев достаточно.
Собственное развёртывание — данные не покидают контур, стоимость предсказуема и не зависит от объёма обращений, нет лимитов. Требует вложений в оборудование и администрирование, качество открытых моделей на сложных рассуждениях ниже.
Гибридная схема — часто оптимальна: чувствительные данные обрабатываются локальной моделью, сложные редкие запросы уходят в облако после маскирования персональных данных.
Локальное развёртывание LLM
Что делаю практически:
- подбор модели под задачу и доступное оборудование;
- квантизация (GGUF, AWQ, GPTQ) с оценкой потери качества на вашем наборе задач — переход на 4-битную квантизацию часто даёт трёхкратную экономию памяти при приемлемой деградации, но проверять это нужно на конкретной задаче, а не по бенчмаркам;
- расчёт требований к VRAM исходя из размера модели, разрядности, длины контекста и числа одновременных запросов — кэш внимания при длинном контексте потребляет больше, чем ожидают;
- выбор сервера инференса: vLLM для нагруженных сценариев с батчингом и эффективным управлением памятью, Ollama или llama.cpp для небольших нагрузок и быстрого старта;
- контейнеризация, автозапуск, мониторинг, ограничение ресурсов;
- нагрузочное тестирование до вывода в продакшен: сколько одновременных пользователей выдерживает конфигурация и какая при этом задержка ответа.
Отдельно предупреждаю о том, что часто становится сюрпризом: сервер под инференс — это капитальные затраты плюс электричество и администрирование. Для небольшого объёма обращений облако дешевле в разы, и своё железо окупается только при существенной нагрузке или при жёстких требованиях к данным.
Векторные хранилища
Выбор зависит от объёма и от того, что уже есть в инфраструктуре:
- pgvector — когда PostgreSQL уже используется. Одна база вместо двух, транзакционность, привычное администрирование. Достаточно для большинства корпоративных корпусов.
- Qdrant — когда нужна производительность на больших объёмах, богатая фильтрация по метаданным, квантизация векторов для экономии памяти.
- Прочие решения — по обоснованию, а не по моде.
Прорабатывается: выбор модели эмбеддингов с учётом качества на русском языке, размерность и её влияние на память, стратегия обновления индекса, резервное копирование.
Интеграции
Подключение к рабочим системам — обычно основная часть трудозатрат проекта.
CRM (штатные API, вебхуки), почта, телефония, мессенджеры, таблицы, внутренние сервисы. Для систем без API — разбор доступных вариантов обмена вплоть до файлового.
Прорабатывается: аутентификация и хранение секретов, ограничение скорости запросов, повторы при сбоях с экспоненциальной задержкой, очереди для асинхронной обработки, журналирование всех обращений.
Шлюз моделей и отказоустойчивость
В продакшене решение не должно останавливаться из-за недоступности одного поставщика. Настраиваю единую точку доступа к моделям с маршрутизацией, резервными провайдерами при отказе, ограничением расходов и учётом потребления по сценариям.
Это же даёт возможность менять модель без переписывания логики приложения — существенно при текущей скорости смены поколений моделей.
Оценка качества и наблюдаемость
Пункт, который отличает разработку ИИ от сборки демонстрации. Без него невозможно ответить на вопрос «стало ли лучше после правки промпта».
Набор для оценки. Формирую эталонный набор из реальных запросов с проверенными ответами — обычно 50–200 примеров, включая сложные и краевые случаи. Он собирается до начала оптимизации и служит базовой линией.
Метрики для RAG. Раздельная оценка поиска и генерации:
- по поиску — попадание релевантных документов в выдачу, их позиция после реранкинга;
- по генерации — обоснованность ответа найденным контекстом (нет ли утверждений вне источников), релевантность ответа вопросу, полнота.
Раздельная оценка принципиальна: если система отвечает плохо, нужно знать, не нашлись документы или модель их проигнорировала. Это разные проблемы с разными решениями.
Автоматическая оценка моделью. Оценка ответов отдельной моделью по заданным критериям — для регулярной прогонки. Калибруется по ручной разметке части выборки, иначе даёт систематическое смещение.
Регрессионное тестирование. Любое изменение промпта, модели или параметров прогоняется по эталонному набору до выката. Иначе улучшение одного сценария ломает три других — это происходит регулярно и незаметно.
Трассировка и мониторинг. Сквозное логирование: запрос → найденные документы → промпт → ответ модели → вызовы инструментов → результат. Без этого разбор жалобы «система ответила ерунду» превращается в гадание.
Отслеживаются: задержка по этапам, расход токенов по сценариям, доля отказов, доля обращений, переданных человеку, частота ошибок инструментов.
Обратная связь от пользователей. Простая оценка ответа в интерфейсе плюс накопление негативных случаев в отдельный набор, который потом пополняет эталонный.
Безопасность и соответствие требованиям
Инъекции в промпт. Актуально везде, где в контекст попадает содержимое из внешних источников — писем, документов, веб-страниц. Инструкция, вставленная в обрабатываемый документ, может изменить поведение системы. Меры: разделение инструкций и данных, фильтрация подозрительных конструкций, ограничение действий агента независимо от того, что он «решил», подтверждение необратимых операций человеком.
Персональные данные. Маскирование до отправки во внешние сервисы, где это возможно. Настройка того, что попадает в логи. Сроки хранения истории обращений.
Требования 152-ФЗ. При обработке персональных данных — размещение в РФ, проверка условий обработки у выбранного поставщика, оформление документов. Это проверяется до выбора архитектуры, потому что напрямую определяет, доступны ли зарубежные сервисы.
Разграничение доступа. На уровне поиска, а не на уровне ответа. Документ, к которому у сотрудника нет доступа, не должен попадать в контекст вообще — фильтрация ответа постфактум ненадёжна.
Ограничение действий. Для агентов — явный список разрешённого, изоляция исполнения, лимиты на объём операций, журнал всех действий с возможностью разбора.
Стоимость эксплуатации и её оптимизация
Проект, который отлично работает в тесте, может оказаться нерентабельным при реальном объёме. Расчёт стоимости обращения делаю до разработки, а не после.
Что влияет и чем управляю:
- Кэширование контекста. Для сценариев с большой неизменной частью промпта даёт существенную экономию.
- Маршрутизация по сложности. Простые обращения обрабатываются маленькой дешёвой моделью, сложные — большой. Классификатор на входе окупается быстро.
- Реранкинг вместо большого контекста. Отдавать в модель 3 релевантных фрагмента дешевле и точнее, чем 20 условно подходящих.
- Кэширование ответов на повторяющиеся вопросы.
- Пакетная обработка для фоновых задач без требования к скорости отклика.
- Ограничение длины вывода там, где длинный ответ не нужен.
- Контроль расходов с оповещением при превышении порога — защита от сценария, когда ошибка в цикле за ночь выкручивает месячный бюджет.
Как устроен проект
1. Discovery. Разбор процесса, данных, ограничений и критериев успеха. На выходе: описание сценария, требования к данным, ограничения по обработке данных, эталонный набор для проверки качества, оценка трудоёмкости и стоимости эксплуатации. Может завершиться выводом, что задача не требует ИИ, — это нормальный и полезный результат.
2. Proof of Concept. Проверка ключевой технической гипотезы на ваших данных. Не полноценное решение, а ответ на вопрос «достижимо ли требуемое качество в принципе». Здесь чаще всего выясняется реальное состояние данных.
3. MVP. Рабочая версия для ограниченного круга пользователей. Основной сценарий, базовые интеграции, логирование. Цель — получить обратную связь на реальном использовании.
4. Продакшен. Доведение до эксплуатации: полные интеграции, разграничение прав, обработка отказов, мониторинг, нагрузочное тестирование, документация, обучение пользователей.
5. Сопровождение. Регулярный разбор выборки ответов, пополнение эталонного набора, донастройка, обновление базы знаний, контроль расходов, миграция на новые модели при появлении лучшего соотношения цена/качество.
Каждый этап завершается артефактом и точкой принятия решения: продолжать, менять подход или останавливаться. Проект не обязан идти до конца, если PoC показал, что качество недостижимо при разумных вложениях.
Стек
Модели: облачные API, YandexGPT, GigaChat, открытые модели в локальном развёртывании.
Инференс: vLLM, Ollama, llama.cpp.
Хранилища: PostgreSQL + pgvector, Qdrant.
Оркестрация: собственный код на Python, n8n для интеграционных сценариев.
Наблюдаемость: трассировка вызовов, метрики качества, дашборды расходов.
Инфраструктура: Docker, Linux-серверы, CI/CD, резервное копирование.
Интеграции: REST/GraphQL API, вебхуки, очереди, MCP.
Стек подбирается под проект. Готовность объяснить, почему выбран конкретный компонент, — часть работы; решения «потому что популярно» я не принимаю.
Сферы применения
Направления, где внедрение ИИ в бизнес-процессы даёт наиболее устойчивый эффект:
Поддержка и клиентский сервис — ответы по базе знаний, классификация обращений, черновики ответов операторам, ответы вне рабочего времени.
Документооборот — извлечение данных из счетов, договоров, спецификаций и актов, сверка с шаблонами, поиск расхождений, маршрутизация.
Продажи — квалификация входящих заявок, подготовка коммерческих предложений, разбор переписки, обогащение карточек в CRM.
Внутренние процессы — помощник по регламентам, поиск по накопленной документации, адаптация новых сотрудников, автоматическая отчётность из разрозненных источников.
Производство и логистика — обработка спецификаций и заказов, сопоставление номенклатуры, разбор технической документации.
Маркетинг — анализ запросов и конкурентов, обработка отзывов и обратной связи, подготовка контента с последующей проверкой.
Разработка — ревью кода, документирование, миграция legacy-кода, генерация тестов.
Общий признак пригодной задачи: операция повторяется, работает с текстом или структурированными данными, результат проверяем, данные доступны в электронном виде.
Проблемы внедрения ИИ и как я их обхожу
Список причин, по которым проекты не доходят до продакшена. Все встречались на практике.
Данные оказываются хуже ожиданий. Регламенты противоречат друг другу, документы в разных редакциях, часть информации только в головах сотрудников. Обнаруживается на этапе PoC, поэтому PoC идёт до бюджета на разработку, а не после.
Нет критерия успеха. Проект без зафиксированного «что считается правильным ответом» невозможно ни отладить, ни принять. Эталонный набор формируется на этапе discovery.
Прототип выглядит хорошо, продакшен разваливается. Демонстрация на десяти подобранных вопросах ничего не говорит о поведении на тысяче реальных. Отсюда нагрузочное тестирование и оценка на эталонном наборе, а не на впечатлении.
Стоимость эксплуатации превышает выгоду. Считается до разработки. Если счёт за токены сопоставим с зарплатой сотрудника, которого решение разгружает, проект не имеет смысла — и лучше узнать это заранее.
Галлюцинации. Решается архитектурой: ответ строго по найденным источникам, явный отказ при отсутствии данных, цитирование, порог по релевантности. «Попросить модель не выдумывать» в промпте — не решение.
Решением не пользуются. Технически исправная система, которую сотрудники обходят стороной, не окупается. Отсюда участие будущих пользователей на этапе MVP и обучение при запуске.
Внедрили и забыли. Качество деградирует: меняются данные, процессы, поставщики моделей. Без регулярного разбора выборки ответов система тихо портится.
Начали с самого сложного процесса. Первый проект должен быть проверяемым и небольшим. Ключевой процесс компании — плохой кандидат для первого внедрения.
Как измеряется результат внедрения
Метрики фиксируются до запуска, иначе после внедрения обсуждение сводится к субъективным оценкам.
Операционные: время выполнения операции до и после, число обработанных единиц за период, доля обращений, закрытых без участия человека, доля, переданных человеку.
Качественные: доля корректных ответов на эталонном наборе, доля ответов, обоснованных источниками, частота отказов, оценки пользователей.
Экономические: стоимость обработки одного обращения с учётом расходов на модель и инфраструктуру, сравнение с текущей стоимостью в человеко-часах, срок окупаемости разработки.
Технические: задержка ответа, доступность, частота ошибок интеграций.
Замер «до» делается на этапе discovery. Без него сравнивать будет не с чем — это самая частая причина, по которой успешное внедрение невозможно защитить перед руководством.
Форматы работы
- Техническая консультация — разобрать архитектуру, оценить осуществимость, проверить чужое предложение или уже принятое решение.
- Discovery — постановка задачи, оценка данных, критерии успеха, оценка стоимости разработки и эксплуатации.
- Proof of Concept — проверка достижимости качества на ваших данных.
- Разработка — от MVP до продакшена.
- Развёртывание на вашей инфраструктуре — установка, настройка, нагрузочное тестирование, документация.
- Аудит существующего решения — почему внедрённое не работает и что с этим делать.
- Сопровождение — контроль качества, оптимизация расходов, миграция моделей, развитие.
Разбор задачи и предварительная оценка — бесплатно.
От чего зависит стоимость
- Класс решения. Один сценарий классификации, RAG-система и агент с несколькими интеграциями — принципиально разная трудоёмкость.
- Состояние данных. Основной фактор разброса. Подготовленный структурированный корпус против архива разнородных документов — разница в разы.
- Число и закрытость интеграций. Система с документированным API подключается за часы, самописная без документации — за недели.
- Требования к качеству. Порог 80% и порог 97% отличаются не на 17% работы, а кратно: последние проценты требуют наибольших вложений.
- Инфраструктура. Облако против собственного развёртывания, с закупкой и настройкой оборудования.
- Требования безопасности. Разграничение прав, аудит, соответствие 152-ФЗ.
Помимо разработки считаются текущие расходы: токены или содержание сервера, сопровождение. Оценка обоих даётся до начала работы.
