ИИ-агенты и RAG: как компании внедряют LLM в бизнес-процессы

ИИ перестал быть экспериментом и стал обычным инструментом корпоративной разработки — таким же, как когда-то контейнеризация или CI/CD. Компании ставят языковые модели в поддержку, документооборот, продажи, внутренние базы знаний. Вопрос уже не в том, внедрять или нет, а в том, куда именно встроить, чтобы получить пользу, а не галочку.

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

Материал подготовлен по вебинару Рустама Борханова — старшего инженера-программиста отдела интеграции в Финаме и автора курса «LLM-разработчик» в Хекслете. Запись вебинара.

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

Как AI стал новым слоем разработки

С LLM сейчас происходит примерно то же, что ранее происходило с контейнеризацией, CI/CD и Kubernetes: сначала технология воспринимается как отдельное направление, а затем постепенно становится частью стандартного технологического стека. Компании уже применяют AI в разработке, поддержке, работе с документами, аналитике и автоматизации процессов. При этом значительная часть прикладных решений строится вокруг двух компонентов — RAG и агентов. RAG помогает модели получать нужную информацию, а агенты позволяют выполнять действия во внешних системах.

Что такое ИИ-агент простыми словами

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

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

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

Чем агент отличается от чат-бота и от RAG

Из чего состоит агент

Четыре обязательных части:

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

Как это выглядит на практике

Представьте: пользователь пишет в поддержку, что хочет оформить возврат товара.

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

И вот в этот момент ИИ перестает быть чат-ботом и становится интерфейсом к корпоративным системам. Пользователь пишет человеческим языком, а на выходе меняются записи в базах.

Что такое RAG и зачем он нужен

RAG — Retrieval-Augmented Generation — объединяет языковую модель с внешними источниками информации. Это база данных будущего. Система получает запрос пользователя, ищет релевантные фрагменты в базе знаний и передает найденный контекст модели для подготовки ответа. Проще говоря, модель перестает отвечать «из головы» и начинает отвечать по вашим документам.

Что можно положить в RAG

RAG можно использовать практически с любой корпоративной информацией:

• внутренними базами знаний;
• договорами и нормативными документами;
• документацией поставщиков и клиентов;
• кодом — только загружайте фрагменты, а не весь код целиком;
• данными из CRM и других корпоративных систем.

В качестве хранилища не всегда требуется отдельная специализированная векторная база, для многих проектов может быть достаточно PostgreSQL с расширением pgvector.

Как работает поиск по смыслу

Цепочка выглядит так:

1. Документы заранее разбиваются на небольшие фрагменты — чанки.
2. Для каждого чанка считается эмбеддинг — числовой вектор.
3. Векторы складываются в базу.
4. Приходит запрос пользователя — для него тоже считается эмбеддинг.
5. Система ищет ближайшие векторы, например по косинусной близости.
6. Найденные чанки подставляются в промпт как контекст.
7. Модель формулирует ответ.

Чанки: какого размера?

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

Единого идеального размера чанка не существует в природе: он зависит от модели, структуры текста и конкретной задачи. В своих проектах эксперт ориентируется на 200–300 слов, иногда используя перекрытие между соседними фрагментами. А в вашем проекте может быть другое количество — бывают чанки, ограниченные 500 символами.

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

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

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

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

Поэтому на практике поиск по смыслу комбинируют с обычным текстовым. Гибридный подход закрывает и случаи, где важен точный термин, артикул или номер документа, и случаи, где важен смысл.

Агенты дают LLM возможность действовать

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

Такая структура имеет особенность. При проектировании LLM-инструментов важно делать их максимально конкретными. Чем более размытые возможности получает модель, тем выше риск неправильного выбора инструмента или некорректного вызова. Поэтому хороший агент должен иметь понятное назначение и минимально необходимый набор параметров.

Для небольшого проекта достаточно обычного function calling. Но по мере роста количества инструментов управление системой усложняется: пять агентов контролировать легко, десятки — уже заметно сложнее, а сотни требуют оркестрации, а это уже отдельное искусство. Для этого уже есть специальные фреймворки, упрощающие жизнь, но с ними тоже нужно уметь правильно обращаться. Существуют Hermes, Яндекс AI Studio, Google AI Studio и другие инструменты, которые позволяют создавать агентов, выстраивать связи и процессы между ними.

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

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

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

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

Иногда RAG и агенты используют как единый комплекс. Занимаются аналитикой и прототипированием с помощью LLM, пишут код при помощи Claude, Codex, GLM, Kimi, MiniMax и других решений, внедряют модели непосредственно в IDE. Именно RAG в связке с агентами — сейчас одно из самых востребованных решений.

MCP: зачем нужен еще один протокол?

Одним из ключевых инструментов современной агентной инфраструктуры становится MCP — Model Context Protocol. Рассматривать его стоит как уровень стандартизации поверх работы с инструментами: сама модель по-прежнему вызывает функции, но MCP задает единый способ организации и подключения таких возможностей.

Чем это отличается от обычного function calling

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

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

Главное преимущество здесь инженерное: стандартизированные компоненты проще поддерживать, переиспользовать и передавать между разработчиками.

Внедрение ИИ в бизнес

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

Для этого нужно понять:

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

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

Следующий обязательный слой — безопасность. В продакшне необходимо учитывать безопасность персональных и корпоративных данных, защиту от промпт-инъекций, попыткок изменить поведение системы и украсть API-токены. Поэтому безопасность LLM-продукта нельзя добавлять после разработки — она должна проектироваться вместе с архитектурой системы.

Как AI работает в реальном бизнесе

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

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

Это пример того, что максимальный эффект не всегда дает полная автоматизация. Иногда гораздо эффективнее предоставить специалисту AI-инструмент, который помогает ускорить рутину.

Кто такой LLM-разработчик и что он должен уметь

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

Спрос довольно большой, но компании пока не очень понимают, что конкретно им нужно. Рынок пока не пришел даже к единому определению профессии. В вакансиях встречаются названия AI-разработчик, AI-инженер, LLM-разработчик, AI-архитектор и даже AI-интегратор.

При этом можно выделить несколько направлений.

• Специалисты, которые непосредственно работают с моделями и исследованиями.
• AI/ML-инженеры, занимающиеся файнтюнингом и доработкой моделей.
• AI-интеграторы и LLM-разработчики, задача которых — изучать бизнес-процессы и понимать, куда можно встроить существующие модели, RAG и агентов.

Три направления LLM-разработки

Третье направление — самое массовое по спросу и самое доступное для входа.

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

Зарплаты на такие вакансии стартуют от 250 тысяч рублей и могут уходить от этой планки далеко вверх.

При этом конкретный язык программирования играет второстепенную роль. Компании обычно предпочитают использовать уже существующий стек: Python, C#, JavaScript или другие технологии.

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

Порядок изучения профессии LLM-разработчик

Что нужно знать LLM-разработчику, чтобы устроиться на работу:

1. Основы работы с LLM. Токены, контекстное окно, температура, системный промпт. Без этого всё остальное — магия.
2. Промпты и управление контекстом. Самый быстрый рост качества на единицу усилий.
3. API и function calling. Как вызывать модель из кода и как дать ей инструменты.
4. RAG. Эмбеддинги, чанкинг, векторный поиск, гибридный поиск.
5. Агенты. Планирование, память, оркестрация.
6. Продакшен. Логирование, оценка качества, безопасность, стоимость.

Три проекта в портфолио

Знания нужно чем-то подтвердить. Для этой цели служит портфолио. В нем могут быть:

1. RAG по своим документам. Возьмите набор PDF или страниц вики, разбейте на чанки, посчитайте эмбеддинги, положите в PostgreSQL с pgvector, сделайте поиск и ответ с указанием источника. Этот проект показывает, что вы понимаете весь путь данных.
2. Агент с двумя-тремя инструментами. Например, помощник, который принимает задачу текстом, ищет информацию и заводит запись во внешнем сервисе. Здесь важно показать не сложность, а аккуратность: понятные инструменты, обработка ошибок, логи.
3. То же самое, но с измеримым результатом. Возьмите реальную рутину — свою или коллег — и покажите цифру: было столько-то минут, стало столько-то. Именно этот проект отличает кандидата, который умеет говорить с бизнесом, от того, кто просто освоил библиотеку.

Частые вопросы

Что такое ИИ-агент простыми словами?

Языковая модель, которой дали инструменты и право ими пользоваться. Она сама решает, какое действие выполнить, и выполняет его во внешних системах.

Чем ИИ-агент отличается от чат-бота?

Чат-бот заканчивает работу текстом, агент — действием: создаёт задачу, меняет запись в CRM, отправляет письмо.

Что такое RAG и зачем он нужен?

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

Какой размер чанка выбрать?

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

Нужна ли отдельная векторная база?

Не всегда. Для многих проектов достаточно PostgreSQL с расширением pgvector. Начинайте с этого и переезжайте, когда упрётесь в ограничения.

Что такое MCP-сервер и зачем он нужен?

Стандарт подключения инструментов к моделям. Для небольшого проекта избыточен — хватит обычного function calling. Ценность появляется, когда инструментов много и они распределены между командами.

Можно ли обойтись без большой модели?

В большинстве продакшн-сценариев — да. Определить намерение, классифицировать запрос, извлечь данные, выбрать следующий шаг умеют и небольшие локальные модели. Большие удобны на прототипировании.

Сколько зарабатывает LLM-разработчик?

По оценке спикера, вилки стартуют от 250 тысяч рублей и уходят выше. Единого названия профессии на рынке пока нет: встречаются AI-разработчик, AI-инженер, LLM-разработчик, AI-архитектор, AI-интегратор.

Какой язык программирования нужен?

Тот, на котором вы уже пишете. Компании используют существующий стек — Python, C#, JavaScript. Учить новый язык специально не нужно.

С чего начать изучение LLM-разработки?

С основ работы с моделями: токены, контекстное окно, системный промпт. Дальше — промпты, API и function calling, RAG, агенты, продакшен.

Что в итоге

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

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

И главный практический вывод: не пытайтесь заменить специалиста. Ускорьте его — эффект будет выше.

Если хотите собрать эти навыки в системе, а не по разрозненным статьям, посмотрите курс «LLM-разработчик» — четыре месяца практики, автор Рустам Борханов. Старт 27 августа, место можно забронировать заранее.

Если тема пока новая и нужен фундамент — начните с бесплатного курса «ИИ и нейросети для начинающих». А если интересует не разработка, а автоматизация процессов готовыми инструментами — посмотрите «AI-автоматизацию».