Привет, Хабр!

Я старший инженер-программист в Финаме и автор курса «LLM-разработчик» в Хекслете. Разговор пойдёт о практике LLM-разработки и о бытовых деталях: кому нужен RAG, обязательно ли связываться с большими моделями, каково на рынке LLM-разработки и как попасть в профессию — что уметь, как искать, сколько просить. Если лень читать — я всё это рассказал в видео. А этот материал — для тех, кто больше любит буквы, чем кино. 

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

Как — не знаем. Для чего — не знаем. Бизнес не очень понимает, что конкретно ему нужно — но нужно, потому что «это же революция, Джонни!». На самом деле, это и правда революция, но, как с любой революцией, нужно понимать как, для чего и куда её использовать.

К вам может прийти CEO и сказать: «Мы хотим везде использовать искусственный интеллект: внедряем его в разработку, в CI/CD, в оценку, в код-ревью, в постановку задач, в работу с ассистентами». И во всех этих историях действительно можно применить ИИ, вплоть до того, чтобы гендиректор мог себе заказать кофе при помощи чат-ботика.

LLM-интегратор на пустом рынке

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

Если вам интересен ML, если вам интересна ИИ-разработка, то, на мой взгляд, надо начинать с LLM-интеграции. 

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

LLM как новый слой реальности

LLM становится чем-то вроде нового слоя реальности. Когда-то мы писали сервер, писали фронт и запускали всё это на каком-нибудь Ubuntu. Всё это запускалось после хорошей настройки и проверки со стороны QA.

Потом появились всякие истории с PM2, Docker, Kubernetes. Это всё стало новой реальностью. С LLM будет примерно то же самое. Они уже специализируются под любые задачи. Агенты внедряются в нашу жизнь, чтобы создавать задачи из чата, назначать созвоны коллегам, систематизировать информацию после созвона. 

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

RAG: база данных, которая понимает смысл

Большая часть работы LLM-интегратора строится на нескольких основных технологиях, вроде RAG (Retrieval-Augmented Generation или генерация с дополненной выборкой) и агентов.

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

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

Таким образом RAG — это технология, которая обеспечивает поиск по релевантной информации, соответствующей намерению пользователя. 

Намерение (intent) — то, что пользователь хочет получить, а не те слова, которыми он это описал.

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

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

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

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

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

Но когда мы добавили агента в Word — скорость работы выросла неимоверно. Агент позволял юристам работать самостоятельно и взаимодействовать с кусками текста через чат.

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

Важна не только технология, но и восприятие пользователей — юристы не доверились полностью автономной системе, вот помощник-ассистент пришёлся весьма кстати.

Агенты и MCP: ручки для языковой модели

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

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

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

Нужно дать модели инструменты для активных действий. И вот мы пришли к разговору об агентах.

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

И в этой истории есть два важных понятия: Tool Calling и MCP.

Tool Calling — это вызов программных инструментов, он работает примерно так: 

  • разработчик заранее объясняет нейросети, какие «инструменты» ей доступны (функция поиска в базе данных, отправка письма, командная строка...). Всё это описывается и передаётся в промпте;

  • когда при запросе модель понимает, что её собственных знаний недостаточно — она выбирает нужный инструмент и сообщает, что нужно сделать с помощью этого инструмента;

  • приложение-агент получает команду, запускает запрошенный инструмент и выполняет нужное действие (например, делает запрос к БД), получает результат и передаёт его модели.

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

Перейдем к агентам и оркестрации. Оркестрация — это чудо. Когда у вас пять агентов — никаких вопросов. Когда у вас 25 агентов — становится тяжеловато. Когда у вас сотня агентов — это уже боль. 

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

Очень помогает распределить имеющиеся инструменты и делегировать работу с ними по разным отделам. Это практичнее, чем монолит и очень упрощает жизнь. А если нужно сделать прототип — я бы советовал использовать AI-студию, неважно чью — Google, Яндекс или какую-то ещё. Пользуйтесь готовыми инструментами, пожалейте свои нервы.

Большие модели, малые модели и деньги

Большие провайдеры, большие модели, куча памяти — уже набили оскомину: OpenAI, Anthropic, Google, Minimax, Llama, Qwen, DeepSeek, GLM, Kimi и прочее подобное. Большие, знаменитые, хотят денег.

Но ведь есть еще и малые модели, и они, как правило, открыты. И эти модели зачастую можно использовать даже на ноутбуке. Открытые модели GLM, Qwen, Gemma, Llama, open-source GPT можно развернуть локально и не беспокоиться о правах и лицензиях: большая часть из них свободны. Часто это небольшие модели, не больше 100 млрд параметров. 

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

Но в 90% случаев можно использовать маленькие модели — и они успешно решат множество задач. Маленьких моделей вполне хватит, например, для задач, где не нужно генерировать полный ответ при помощи LLM, а можно вернуть заготовленный текст. В такой ситуации малые модели сэкономят вам не просто много денег, а очень много денег. 

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

Продакшен: утечки, метрики, безопасность

Посмотрим для примера на рабочий прототип — RAG-ассистент для сайта университета. В проекте есть краулер по sitemap, индексация страниц в Qdrant, мультиязычная эмбеддинг-модель, FastAPI, LLM через API, веб-интерфейс и логирование вопросов. Что нужно, чтобы выкатить проект в прод?

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

Мне приходилось проверять много запросов, и это даёт очень много полезной информации. Можно сделать аналитику запросов при помощи LLM, можно понять, какая боль есть у пользователей — и в итоге можно понять, что с этим делать. 

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

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

Для Production Ready нужно предусмотреть, чтобы система не передавала персональную информацию и во внешнюю LLM. Локальная LLM решит проблему утечки данных. От промпт-инъекций и кражи токенов защищают отдельные меры: фильтры, лимиты, авторизация.

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

От 70 тысяч до космоса

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

У опытных разработчиков зарплата идет от 250 000 и вверх до самого космоса, потому что нередко этим занимаются, например, ML-разработчики с очень высокими окладами.

Попытки найти специалистов на 70 000 рублей — довольно забавные, на мой взгляд. 

По данным Хабр Карьеры и HeadHunter, на момент публикации стартовые зарплаты для Junior LLM-интеграторов начинаются от 110 000 рублей.

Что нужно уметь

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

По части языков программирования — большинство компаний хотят работать с теми языками, к которым привыкли. Для популярных языков уже есть и библиотеки для работы с OpenAI-подобными API, и небольшие фреймворки для работы с MCP. Я бы советовал Java, C#, Go, просто потому, что они популярны в энтерпрайзе.

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

Пригодятся знания в CI/CD и в оценке серверов. Возможно, придётся заниматься раскаткой локальных LLM, отслеживать их нагрузку, распределять инфраструктуру по серверам, то есть заниматься MLOps. 

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

В индустрии даже появилась новая специальность — с красивой аббревиатурой, всё как положено:  FDE (Forward Deployed Engineer — инженер передового развёртывания). Это специалист на стыке разработки ПО, искусственного интеллекта и общения с бизнесом, который внедряет продукты компании (часто — ИИ-решения) непосредственно на стороне клиента.

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

Охота на вакансии

Где искать вакансии для LLM-разработчика, на каких сайтах? HeadHunter, по общему мнению, немножечко мертв. Вакансии там просто висят для того, чтобы висеть, особенно у крупных компаний. Но можно туда зайти, посмотреть, какая компания ищет специалистов, зайти на сайт этой компании — и связаться напрямую, минуя HH. Говорят, это работает лучше. 

Компании ищут специалистов с конкретными навыками: работа с RAG, работа с конкретными LLM, с агентами и с определённым языком программирования.

Компании, которые нашли себе руководителя отдела по LLM-разработке и ИИ-интеграции, начинают искать, собственно, разработчиков по этой специальности. Но персонала-то еще нет! И тут начинается самое интересное: HR спрашивают «А у вас есть трёхлетний опыт в интеграции искусственного интеллекта?». Но откуда три, если его всего два года интегрируют во всем мире?

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

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

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

Программа курса и учебные проекты

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

Базовые требования для обучения не особо строги: студент не должен быть ML-инженером или сеньором. Однако мы не будем учить азам — какие бывают протоколы, что такое ИИ и как всё это работает. Хорошо, если студент будет понимать веб-технологии и общение сервисов друг с другом. Но если не будет хватать какой-то информации из разряда «как бегают запросы по HTTP и HTTPS» — можно будет доучить по ходу курса.

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

Для обучения на курсе студенту достаточно уровня Junior+ или Middle-. Если студент может писать, читать и понимать код, если он знает хотя бы один язык — этого достаточно: он будет решать задачи и разбирать примеры на своём языке.

На курсе будет куча практики: разберём workflow, MCP и RAG через Яндекс AI Studio, на первом же модуле курса займёмся Helpdesk-агентами и сделаем небольшого помощника разработчика из разряда «сходи в Jira, посмотри задачи, сходи в Трекер, сходи в Git, посмотри пул-реквесты».

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

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

И в конце будет развёртывание своего корпоративного решения: развернём модели, построим workflow и выдать некоторую базу для разработчиков MLOps. Есть базы для разработчиков GitOps и DevOps, а теперь новое слово: у нас есть ещё и MLOps.

От перфокарт до собеседника

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

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

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