{
    "version": "https:\/\/jsonfeed.org\/version\/1.1",
    "title": "Андрей Крисанов: заметки с тегом LLM",
    "_rss_description": "Блог Андрея Крисанова о разработке в эпоху ИИ: прикладной ИИ, инфраструктура ИИ, ИИ-нативные продукты и управление инженерными командами.",
    "_rss_language": "ru",
    "_itunes_email": "",
    "_itunes_categories_xml": "",
    "_itunes_image": "",
    "_itunes_explicit": "",
    "home_page_url": "https:\/\/agenticeng.ru\/tags\/llm\/",
    "feed_url": "https:\/\/agenticeng.ru\/tags\/llm\/json\/",
    "icon": "https:\/\/agenticeng.ru\/pictures\/userpic\/userpic@2x.jpg?1775503436",
    "authors": [
        {
            "name": "Андрей Крисанов",
            "url": "https:\/\/agenticeng.ru\/",
            "avatar": "https:\/\/agenticeng.ru\/pictures\/userpic\/userpic@2x.jpg?1775503436"
        }
    ],
    "items": [
        {
            "id": "8",
            "url": "https:\/\/agenticeng.ru\/all\/genai-cost\/",
            "title": "Сколько на самом деле стоит GenAI в продакшене",
            "content_html": "<p>Когда обсуждают стоимость внедрения генеративного ИИ, разговор часто сводится к цене за токен или цене за арендуемый GPU. Это удобно — одно число. Но в реальном продакшене такая оценка почти всегда обманчива.<\/p>\n<p>Стоимость GenAI-системы — это не только сколько стоит вызвать модель. Это инфраструктура, эксплуатация, безопасность, наблюдаемость, разработка, интеграции, поддержка пользователей и постоянные изменения вокруг моделей. Именно поэтому «мы поднимем open-source модель сами, будет дешевле» часто оказывается правдой только на первом слайде презентации.<\/p>\n<h3>Из чего складывается стоимость GenAI в продакшене<\/h3>\n<p>Типовая GenAI-система состоит не из одной модели. Даже если бизнес-задача звучит просто, например, сделать Q&A чат-бота по документам, внутри быстро появляются:<\/p>\n<ul>\n<li>backend-сервис (API)<\/li>\n<li>модель или несколько моделей<\/li>\n<li>RAG: индексация документов, эмбеддинги, векторный поиск<\/li>\n<li>хранилище документов<\/li>\n<li>авторизация и права доступа<\/li>\n<li>модерация и guardrails<\/li>\n<li>трассировка запросов<\/li>\n<li>мониторинг качества<\/li>\n<li>логирование ошибок<\/li>\n<li>рейт-лимиты, очереди и ретраи<\/li>\n<li>CI\/CD<\/li>\n<li>регламент обновления моделей<\/li>\n<li>поддержка пользователей и команд, которые интегрируются с этим сервисом<\/li>\n<\/ul>\n<p>Пока всё работает в демо-режиме, это кажется избыточным. Но как только сервис начинает использоваться внутри компании, особенно в задачах с персональными данными, документами, юридическими текстами, финансами или внутренними знаниями, нужна архитектура и практики.<\/p>\n<h3>Цена за токен — заметный, но не единственный расход<\/h3>\n<p>Если использовать <a href=\"https:\/\/aistudio.yandex.ru\/docs\/ru\/\">Yandex Cloud AI Studio<\/a>, стоимость зависит от режима работы модели и количества токенов: входных, исходящих, кешированных и токенов инструментов. Это уже важная деталь: один и тот же пользовательский сценарий может стоить по-разному в зависимости от длины промпта, длины ответа, истории диалога и использования tools.<\/p>\n<p>Например, в синхронном режиме YandexGPT Pro 5.1 стоит 0,8 ₽ за 1000 входящих токенов и 0,8 ₽ за 1000 исходящих токенов с НДС. YandexGPT Lite стоит 0,2 ₽ за 1000 входящих и 0,2 ₽ за 1000 исходящих токенов. DeepSeek V3.2 в AI Studio стоит 0,5 ₽ за 1000 входящих токенов и 0,8 ₽ за 1000 исходящих токенов.<\/p>\n<p>Допустим, у нас есть внутренний ассистент, который обрабатывает 1 млн запросов в месяц. Средний запрос:<\/p>\n<ul>\n<li>1000 входящих токенов<\/li>\n<li>500 исходящих токенов<\/li>\n<\/ul>\n<p>Тогда примерная стоимость генерации:<\/p>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td><b>Модель<\/b><\/td>\n<td><b>Расчёт на 1 запрос<\/b><\/td>\n<td><b>1 млн запросов в месяц<\/b><\/td>\n<\/tr>\n<tr>\n<td>YandexGPT Lite<\/td>\n<td>0,2 ₽ + 0,1 ₽<\/td>\n<td>300 000 ₽<\/td>\n<\/tr>\n<tr>\n<td>YandexGPT Pro 5.1<\/td>\n<td>0,8 ₽ + 0,4 ₽<\/td>\n<td>1 200 000 ₽<\/td>\n<\/tr>\n<tr>\n<td>DeepSeek V3.2<\/td>\n<td>0,5 ₽ + 0,4 ₽<\/td>\n<td>900 000 ₽<\/td>\n<\/tr>\n<\/table>\n<p>На этом этапе возникает соблазм сказать, что Lite дешевле Pro в 4 раза и нужно брать эту модель. Но если Lite отвечает хуже, чаще требует повторных запросов, хуже следует инструкциям, хуже работает с длинным контекстом или создаёт больше ошибок для пользователей, реальная стоимость может быть выше. Дешёвый токен может привести к дорогому бизнес-процессу.<\/p>\n<h3>Покупка GPU vs оплата за токены<\/h3>\n<p>Другой популярный подход — поднять open-source модель самостоятельно на своей инфраструктуре. Например, через vLLM, TGI или другой serving-стек.<\/p>\n<p>В Yandex DataSphere конфигурация g2.8 с 8 GPU A100 стоит 4 401,83808 ₽ в час. При расчёте 720 часов в месяц это примерно:<\/p>\n<pre class=\"e2-text-code\"><code class=\"txt\">4 401,84 ₽ × 720 ≈ 3 169 323 ₽ \/ месяц<\/code><\/pre><p>Конфигурация g2.1 с 1 GPU A100 стоит <i>550,22976 ₽ в час<\/i>, а g1.1 с 1 GPU V100 — <i>341,52192 ₽ в час<\/i>. Цены DataSphere для региона Россия указаны с НДС.<\/p>\n<p>На первый взгляд, 8×A100 за ~3,17 млн ₽\/месяц может выглядеть конкурентно, если у вас большой объём трафика. Но это только compute. Дальше нужно добавить:<\/p>\n<ul>\n<li>Kubernetes или другой runtime<\/li>\n<li>хранилище для моделей и образов (container registry)<\/li>\n<li>observability стек (наблюдаемость)<\/li>\n<li>сетевую инфраструктуру<\/li>\n<li>инженерную команду<\/li>\n<\/ul>\n<p>а также процессы вокруг:<\/p>\n<ul>\n<li>обновления моделей<\/li>\n<li>тестирования качества<\/li>\n<li>безопасности<\/li>\n<li>работу с деградациями и инцидентами<\/li>\n<\/ul>\n<p>DataSphere отдельно тарифицирует хранение моделей, Docker-образов, дисков, датасетов и других артефактов; например, хранение модели внутри DataSphere сверх бесплатных лимитов стоит 13,08 ₽ за 1 ГБ в месяц.<\/p>\n<p>То есть self-hosting может быть дешевле на большом масштабе. Но он редко бывает дешевле сам по себе. Он становится выгодным, когда у компании уже есть сильная инфраструктурная команда, понятный объём нагрузки и реальная потребность контролировать serving, latency, безопасность и модельный стек.<\/p>\n<h3>Главный скрытый расход — ФОТ<\/h3>\n<p>В России стоимость инженерной команды ниже, чем в США, но она всё равно быстро становится одной из основных категорий расходов. По данным Dream Job, средняя зарплата ML Engineer в России в 2026 году — 185 000 ₽ на руки, типичный диапазон — 140 000—230 000 ₽, а в Москве среднее значение указано как 260 000 ₽. Другой обзор по рынку ML-инженеров указывает ориентиры по грейдам: Middle — около 160 000—200 000 ₽, Senior — 280 000—350 000 ₽, Lead — 360 000—450 000 ₽ в зависимости от региона и формата работы.<\/p>\n<p>Но для продакшен GenAI вам обычно нужен не один ML Engineer. Минимальный состав может выглядеть так:<\/p>\n<table cellpadding=\"0\" cellspacing=\"0\" border=\"0\" class=\"e2-text-table\">\n<tr>\n<td><b>Роль<\/b><\/td>\n<td><b>Зачем нужна<\/b><\/td>\n<\/tr>\n<tr>\n<td>Backend Engineer<\/td>\n<td>API, бизнес-логика, интеграции<\/td>\n<\/tr>\n<tr>\n<td>ML \/ LLM Engineer<\/td>\n<td>выбор моделей, промпты, evals, качество<\/td>\n<\/tr>\n<tr>\n<td>Platform \/ DevOps Engineer<\/td>\n<td>Kubernetes, GPU, CI\/CD, observability<\/td>\n<\/tr>\n<tr>\n<td>Security \/ InfoSec<\/td>\n<td>доступы, данные, аудит, compliance<\/td>\n<\/tr>\n<tr>\n<td>Product \/ Analyst<\/td>\n<td>сценарии, метрики, приоритизация<\/td>\n<\/tr>\n<\/table>\n<p>Даже маленькая команда из 2—3 сильных инженеров может стоить компании заметно больше, чем API-вызовы модели. Особенно если считать не только зарплату на руки, а полную стоимость сотрудника: налоги, оборудование, менеджмент, найм, отпуска, простои, коммуникации и стоимость ошибок.<\/p>\n<p>Именно здесь часто ломается наивная математика: <i>API стоит 1 млн ₽ в месяц, а self-hosting на GPU — 3 млн ₽. Значит API дешевле<\/i>.<\/p>\n<p>Или наоборот: <i>GPU стоит 3 млн ₽ в месяц, а API при нашем объёме стоит 5 млн ₽. Значит self-hosting дешевле<\/i>.<\/p>\n<p>Обе оценки неполные. Нужно считать людей, эксплуатацию, риски и качество.<\/p>\n<h3>Доступ к LLM через API vs self-hosting<\/h3>\n<p>Упрощённо выбор выглядит так.<\/p>\n<h3>Доступ к LLM через API<\/h3>\n<p>Выгоднее если вы только запускаете продукт, нагрузка непредсказуема, команда маленькая, а главная задача — быстро проверить гипотезу. В этом случае YandexGPT, DeepSeek или другие модели через API позволяют не строить всю инфраструктуру с нуля.<\/p>\n<p>Плюсы:<\/p>\n<ul>\n<li>быстрый старт<\/li>\n<li>не нужно управлять GPU<\/li>\n<li>проще масштабироваться на раннем этапе<\/li>\n<li>меньше эксплуатационной нагрузки<\/li>\n<li>проще считать стоимость на уровне токенов<\/li>\n<\/ul>\n<p>Минусы:<\/p>\n<ul>\n<li>зависимость от провайдера<\/li>\n<li>ограничения по моделям и настройкам<\/li>\n<li>меньше контроля над latency (временем отклика)<\/li>\n<li>сложнее оптимизировать serving под свой сценарии и тип нагрузки<\/li>\n<li>возможные ограничения по данным и комплаенсу<\/li>\n<\/ul>\n<h3>Self-hosting моделей<\/h3>\n<p>Выгоднее если у вас большой и стабильный объём запросов, есть инфраструктурная команда, нужны строгие требования по данным, есть желание контролировать модели, serving-стек, batching, маршрутизацию и стоимость на большом масштабе.<\/p>\n<p>Плюсы:<\/p>\n<ul>\n<li>больше контроля<\/li>\n<li>можно оптимизировать serving<\/li>\n<li>можно выбирать open-source модели<\/li>\n<li>можно строить собственный роутинг и механизмы кэширования<\/li>\n<li>потенциально ниже стоимость за токен на большом объёме<\/li>\n<\/ul>\n<p>Минусы:<\/p>\n<ul>\n<li>высокая сложность<\/li>\n<li>нужен опыт с GPU-инфраструктурой<\/li>\n<li>нужны SRE-практики<\/li>\n<li>нужно самим решать инциденты<\/li>\n<li>нужно самим обновлять модели<\/li>\n<li>нужно самим строить evals и release gates<\/li>\n<\/ul>\n<h3>Скрытые расходы, о которых забывают<\/h3>\n<h3>Наблюдаемость<\/h3>\n<p>Для обычного backend-сервиса достаточно latency, error rate, throughput и логов. Для LLM-системы этого мало.<\/p>\n<p>Нужно понимать:<\/p>\n<ul>\n<li>сколько токенов потребляется<\/li>\n<li>какие промпты дают плохие ответы<\/li>\n<li>где растёт latency<\/li>\n<li>где модель галлюцинирует<\/li>\n<li>какие пользователи повторяют запросы<\/li>\n<li>какие инструменты вызываются<\/li>\n<li>какие документы попадают в контекст<\/li>\n<li>как меняется качество после обновления модели<\/li>\n<\/ul>\n<p>Без этого система становится чёрным ящиком: деньги тратятся, пользователи жалуются, а команда не понимает, где проблема.<\/p>\n<h3>Обновление моделей<\/h3>\n<p>Модель — это не статичная библиотека. Провайдеры обновляют версии, меняют поведение, добавляют новые режимы, снимают старые версии с поддержки.<\/p>\n<p>Каждое обновление требует:<\/p>\n<ul>\n<li>регрессионного тестования<\/li>\n<li>сравнения качества<\/li>\n<li>проверки промптов<\/li>\n<li>проверки latency<\/li>\n<li>проверки стоимости<\/li>\n<li>коммуникации с пользователями<\/li>\n<li>rollback-плана<\/li>\n<\/ul>\n<p>Если этого нет, можно обновить модель и сломать upstream-команды.<\/p>\n<h3>Безопасность<\/h3>\n<p>В корпоративном контексте вопрос не только в том, где дешевле токен.<\/p>\n<p>Нужно отвечать на вопросы:<\/p>\n<ul>\n<li>какие данные уходят в модель<\/li>\n<li>логируются ли запросы<\/li>\n<li>где хранятся трейсы запросов<\/li>\n<li>можно ли отправлять персональные данные<\/li>\n<li>как работает маскирование PII и других данных<\/li>\n<li>кто имеет доступ к истории запросов<\/li>\n<li>можно ли использовать внешние tools<\/li>\n<li>как аудитить действия агента<\/li>\n<\/ul>\n<p>Это не бесплатная часть системы. Её кто-то должен проектировать, внедрять и поддерживать.<\/p>\n<h3>Качество<\/h3>\n<p>Стоимость плохого ответа может быть выше стоимости токенов.<\/p>\n<p>Например, если модель помогает бухгалтерии, юристам, поддержке или инженерам, ошибка может привести к:<\/p>\n<ul>\n<li>потере времени<\/li>\n<li>неправильному решению<\/li>\n<li>ручной перепроверке<\/li>\n<li>недоверию пользователей<\/li>\n<li>отказу от продукта<\/li>\n<li>инциденту безопасности<\/li>\n<\/ul>\n<p>Поэтому более дорогая модель иногда дешевле в реальности, если она снижает количество ошибок и повторных запросов.<\/p>\n<h3>Как посчитать полную стоимость GenAI-системы<\/h3>\n<p>Хорошая формула выглядит не так:<\/p>\n<pre class=\"e2-text-code\"><code class=\"txt\">TCO = цена токенов<\/code><\/pre><p>где TCO — это Total Cost of Ownership, т. е. <b>полная стоимость владения<\/b>.<\/p>\n<p>А примерно так:<\/p>\n<pre class=\"e2-text-code\"><code class=\"txt\">TCO =\n  стоимость inference\n+ стоимость инфраструктуры\n+ стоимость хранения\n+ стоимость сети\n+ стоимость разработки\n+ стоимость эксплуатации\n+ стоимость observability\n+ стоимость безопасности\n+ стоимость обновления моделей\n+ стоимость ошибок<\/code><\/pre><p>Для managed API основная переменная часть — токены. Для self-hosting — GPU, инфраструктура и команда.<\/p>\n<p>Практический подход:<\/p>\n<ol start=\"1\">\n<li>Посчитать ожидаемый объём запросов.<\/li>\n<li>Разделить входные и исходящие токены.<\/li>\n<li>Посчитать стоимость для 2—3 моделей.<\/li>\n<li>Добавить RAG: embeddings, хранилища, поиск.<\/li>\n<li>Добавить observability и логи.<\/li>\n<li>Оценить стоимость команды.<\/li>\n<li>Оценить стоимость поддержки и инцидентов.<\/li>\n<li>Сравнить API и self-hosting не на демо, а на горизонте 6—12 месяцев.<\/li>\n<\/ol>\n<h3>Пример: внутренний AI-ассистент<\/h3>\n<p>Допустим, компания хочет сделать внутреннего ассистента для сотрудников.<\/p>\n<p>Параметры:<\/p>\n<ul>\n<li>1 000 активных пользователей<\/li>\n<li>30 запросов на пользователя в месяц<\/li>\n<li>30 000 запросов в месяц<\/li>\n<li>1 500 входящих токенов<\/li>\n<li>700 исходящих токенов<\/li>\n<\/ul>\n<p>Для YandexGPT Pro 5.1:<\/p>\n<pre class=\"e2-text-code\"><code class=\"txt\">Вход: 1500 \/ 1000 × 0,8 ₽ = 1,2 ₽\nВыход: 700 \/ 1000 × 0,8 ₽ = 0,56 ₽\nИтого: 1,76 ₽ за запрос\n\n30 000 × 1,76 ₽ = 52 800 ₽ \/ месяц<\/code><\/pre><p>Для YandexGPT Lite:<\/p>\n<pre class=\"e2-text-code\"><code class=\"txt\">Вход: 1500 \/ 1000 × 0,2 ₽ = 0,3 ₽\nВыход: 700 \/ 1000 × 0,2 ₽ = 0,14 ₽\nИтого: 0,44 ₽ за запрос\n\n30 000 × 0,44 ₽ = 13 200 ₽ \/ месяц<\/code><\/pre><p>На таком масштабе стоимость токенов почти наверняка не будет главным расходом. Главным расходом будет разработка, интеграция, поддержка, безопасность и внедрение в бизнес-процессы.<\/p>\n<p>Но если это уже не 30 000, а 3—10 млн запросов в месяц, математика меняется. Тогда имеет смысл отдельно смотреть на кэширование, роутинг запросов, batch-режимы, более дешёвые модели для простых задач и self-hosting.<\/p>\n<h3>Вывод<\/h3>\n<p>Главная ошибка при оценке GenAI систем — сравнивать только цену токена или часа за аренду GPU.<\/p>\n<p>Для прототипа это нормально. Для продакшена — нет.<\/p>\n<p>Managed API может быть дороже на единицу inference, но дешевле по TCO (полной стоимости владения), если экономит месяцы разработки и эксплуатации. Self-hosted open-source модель может быть дешевле на большом объёме, но только если у вас есть команда, инфраструктура и зрелые процессы.<\/p>\n<p>Правильный вопрос звучит не так:<\/p>\n<blockquote>\n<p>Какая модель дешевле?<\/p>\n<\/blockquote>\n<p>А так:<\/p>\n<blockquote>\n<p>Какая архитектура даёт нужное качество, время отклика, безопасность и управляемость при минимальной полной стоимости владения?<\/p>\n<\/blockquote>\n<p>И почти всегда ответ зависит не от одной цены в прайсе, а от масштаба, команды и зрелости компании.<\/p>\n",
            "summary": "Разбираемся, сколько на самом деле стоит GenAI-система в продакшене: токены, GPU, Yandex Cloud, self-hosted модели, зарплаты инженеров, эксплуатация и полная стоимость владения.",
            "date_published": "2026-04-27T21:55:46+03:00",
            "date_modified": "2026-04-27T22:01:07+03:00",
            "tags": [
                "LLM",
                "ИИ",
                "инфраструктура ИИ",
                "стоимость"
            ],
            "_date_published_rfc2822": "Mon, 27 Apr 2026 21:55:46 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "8",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [
                    "highlight\/highlight.js",
                    "highlight\/highlight.css"
                ],
                "og_images": []
            }
        },
        {
            "id": "4",
            "url": "https:\/\/agenticeng.ru\/all\/chto-ne-tak-s-vakansiyami-llm-engineer\/",
            "title": "Что не так с вакансиями LLM Engineer",
            "content_html": "<p>В 2026 году вакансий, связанных с ИИ, большими языковыми моделями и агентами, стало заметно больше и в России, и за ее пределами. Технологические компании, банки и даже обычный enterprise поняли, куда движется индустрия, и начали срочно внедрять ИИ в продукты и внутренние процессы.<\/p>\n<p>Если открыть hh.ru, LinkedIn или Telegram-каналы с вакансиями, легко увидеть набор ролей, которые постоянно пересекаются по описанию и требованиям:<\/p>\n<ul>\n<li>LLM Engineer<\/li>\n<li>ML Engineer<\/li>\n<li>AI Engineer<\/li>\n<li>AI Architect<\/li>\n<li>иногда еще что-то вроде «AI Automation Engineer»<\/li>\n<\/ul>\n<p>Особенно часто встречается вакансия LLM Engineer. И вот тут начинается путаница.<\/p>\n<p>Например, в одной вакансии Senior LLM Engineer требуют:<\/p>\n<ul>\n<li>2+ года коммерческой разработки на Python<\/li>\n<li>практический опыт с LangChain, LlamaIndex, prompt engineering, RAG<\/li>\n<li>подтвержденный опыт разработки и внедрения AI-решений<\/li>\n<\/ul>\n<p>Смотришь другую вакансию — уже Team Lead LLM Engineer. А там:<\/p>\n<ul>\n<li>создание и развитие RAG-систем, включая Agentic RAG<\/li>\n<li>observability для агентов<\/li>\n<li>сервисы обработки документов<\/li>\n<li>организация разметки данных<\/li>\n<li>дообучение мультимодальных моделей<\/li>\n<li>LLM-as-a-Judge и quality pipelines<\/li>\n<li>вывод моделей и сервисов в production<\/li>\n<\/ul>\n<p>Проблема в том, что под одним и тем же названием компании часто описывают <b>совершенно разные роли<\/b>.<\/p>\n<p>Где-то под LLM Engineer реально подразумевается человек, который работает с моделями как с объектом исследования и улучшения: оценка (evals), промптинг, fine-tuning, data curation, quality loops, иногда даже инференс и serving.<\/p>\n<p>А где-то под тем же названием ищут обычного сильного прикладного инженера, который должен собирать AI-функции в продукте: RAG, агенты, интеграции, пайплайны, наблюдаемость (observability), безопасность, продакшен-уровень.<\/p>\n<p>А иногда компания просто ищет единорога, который одновременно умеет:<\/p>\n<ul>\n<li>тренировать и дообучать модели<\/li>\n<li>строить RAG и агентные системы<\/li>\n<li>делать evals<\/li>\n<li>поднимать production-инфраструктуру<\/li>\n<li>выстраивать MLOps<\/li>\n<li>а в идеале еще и оптимизировать инференс<\/li>\n<\/ul>\n<p>Естественно, когда бэкенд- или фуллстэк-разработчик, который хочет перейти в прикладной ИИ (applied AI), читает такую вакансию, у него быстро появляется мысль: «я вообще не подхожу».<\/p>\n<p>И это часто ложное ощущение.<\/p>\n<h2>Где проходит граница<\/h2>\n<p>Проблема рынка в том, что названия ролей пока не устоялись. Но на практике полезно различать хотя бы два типа задач.<\/p>\n<h3>LLM Engineer<\/h3>\n<p>Это роль ближе к работе с самими моделями и качеством их поведения.<\/p>\n<p>Обычно сюда попадает:<\/p>\n<ul>\n<li>выбор и сравнение моделей<\/li>\n<li>построение evals (оценки)<\/li>\n<li>prompt engineering как системная дисциплина, а не просто подбор промптов<\/li>\n<li>эксперименты с quality loops<\/li>\n<li>работа с fine-tuning или post-training<\/li>\n<li>участие в проектировании AI-архитектуры на уровне поведения модели и ее качества<\/li>\n<\/ul>\n<p>Для такой роли действительно полезны:<\/p>\n<ul>\n<li>хороший кругозор в NLP и LLM<\/li>\n<li>понимание того, как устроены современные модели<\/li>\n<li>умение читать статьи, документацию и разбирать бенчмарки<\/li>\n<li>привычка много экспериментировать и валидировать гипотезы<\/li>\n<\/ul>\n<h3>AI Engineer \/ Applied AI Engineer<\/h3>\n<p>Это прикладная разработка: создание ценности для продукта с помощью уже существующих моделей и инструментов.<\/p>\n<p>Обычно сюда относится:<\/p>\n<ul>\n<li>AI-функции внутри продукта<\/li>\n<li>tool calling<\/li>\n<li>RAG<\/li>\n<li>агенты и их оркестрация<\/li>\n<li>интеграции с внешними системами<\/li>\n<li>оценка (eval) и наблюдаемость (observability) на уровне приложения<\/li>\n<li>надежный продакшен-код вокруг моделей<\/li>\n<\/ul>\n<p>Здесь важнее другое:<\/p>\n<ul>\n<li>умение строить сервисы<\/li>\n<li>понимать ограничения LLM и не ломать продукт об эти ограничения<\/li>\n<li>уметь отлаживать качество: проблема в данных, retrieval, prompt, tool use или модели<\/li>\n<li>уметь доводить систему до продакшена, а не просто собирать демо<\/li>\n<\/ul>\n<p>И вот здесь важный тезис: <b>во многих вакансиях под названием LLM Engineer на самом деле ищут именно AI Engineer<\/b>. То есть разработчика с сильной бэкенд- или фуллстэк-базой, который умеет применять LLM в реальных системах.<\/p>\n<h2>Как могут выглядеть вменяемые требования к AI Engineer<\/h2>\n<p>Например, так:<\/p>\n<ul>\n<li>уверенное владение Python или TypeScript<\/li>\n<li>умение писать чистый код, тесты и поддерживаемые сервисы<\/li>\n<li>базовое понимание LLM: токены, контекст, temperature, top-p, ограничения по длине контекста<\/li>\n<li>опыт промптинга моделей: шаблоны, few-shot, structured output, tool\/function calling<\/li>\n<li>опыт разработки RAG-систем и работы с векторными хранилищами<\/li>\n<li>опыт интеграции LLM в сервисы<\/li>\n<li>понимание Docker и контейнеризации<\/li>\n<li>навыки диагностики качества и производительности AI-сервисов<\/li>\n<li>базовое понимание безопасности и ограничений при работе с LLM<\/li>\n<\/ul>\n<p>Как видно, тут нет обязательного требования знать Transformer на уровне LLM-инженера\/исследователя, заниматься fine-tuning, строить MLOps-платформу или разбираться в CUDA.<\/p>\n<p>И это нормально.<\/p>\n<h2>Что с этим делать<\/h2>\n<p>У меня здесь два простых совета.<\/p>\n<h3>Рекрутерам и нанимающим менеджерам<\/h3>\n<p>Если вам нужен прикладной инженер, который будет встраивать ИИ в продукт, так и пишите.<\/p>\n<p>Не называйте вакансию LLM Engineer только потому, что это звучит модно. Чем точнее вы обозначите границы роли, тем лучше будет воронка:<\/p>\n<ul>\n<li>меньше нерелевантных откликов<\/li>\n<li>меньше самоотсечения хороших кандидатов<\/li>\n<li>выше шанс быстрее закрыть позицию<\/li>\n<\/ul>\n<p>Не стоит искать единорога там, где на самом деле нужен сильный инженер-разработчик с хорошим продуктовым и системным мышлением.<\/p>\n<h3>Разработчикам, которые хотят перейти в Applied AI<\/h3>\n<p>Не отбрасывайте вакансию только потому, что в ней в одну кучу свалены RAG, агенты, evals, дообучение, observability и MLOps.<\/p>\n<p>Очень часто это просто плохо написанное описание, а не реальный список того, чем вы будете заниматься каждый день.<\/p>\n<p>Поэтому:<\/p>\n<ul>\n<li>уточняйте на первом же созвоне, что реально входит в зону ответственности<\/li>\n<li>показывайте пет-проекты и рабочие кейсы<\/li>\n<li>рассказывайте не только про «я пробовал ChatGPT», а про реальные инженерные задачи<\/li>\n<li>не думайте, что без опыта в ML\/LLM вам закрыт путь в ИИ разработку<\/li>\n<\/ul>\n<p>Для входа в прикладной ИИ (applied AI) не обязательно быть исследователем. Во многих случаях достаточно хорошей инженерной базы и нормального понимания того, как LLM ведут себя в реальных системах.<\/p>\n<p>Рынок еще долго будет путаться в названиях. Но это не значит, что в него нельзя зайти.<\/p>\n",
            "summary": "В 2026 году вакансий, связанных с ИИ, большими языковыми моделями и агентами, стало заметно больше и в России, и за ее пределами",
            "date_published": "2026-04-10T10:27:43+03:00",
            "date_modified": "2026-04-22T11:58:12+03:00",
            "tags": [
                "AI",
                "LLM",
                "Карьера",
                "Найм"
            ],
            "_date_published_rfc2822": "Fri, 10 Apr 2026 10:27:43 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "4",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "2",
            "url": "https:\/\/agenticeng.ru\/all\/vnedrenie-ii-v-produktovyh-komandah\/",
            "title": "Внедрение ИИ в продуктовых командах",
            "content_html": "<p>За последние несколько месяцев мне довелось пообщаться с тремя компаниями по поводу роли руководителя кросс-функциональной команды или CTO в зрелом бизнесе. У каждой были свои ожидания от роли и свои цели на год. Но одна задача повторялась почти у всех: <b>внедрить ИИ в команды разработки и за счет этого повысить их эффективность<\/b>.<\/p>\n<p>Контекст обычно был примерно такой. Есть устоявшаяся команда, есть зрелый продукт, но, по мнению менеджмента, разработка идет слишком медленно. ИИ-инструменты и кодинговые агенты внутри команды либо почти не используются, либо используются точечно, каждым по-своему, без общего подхода. Иногда их уже пробовали, но результат оказался слабее ожиданий. А на рынке в это время появляются истории о том, как CEO или CPO за ночь собирают прототипы с помощью Codex или Claude Code.<\/p>\n<p>Выслушав такой запрос, я начинал задавать не вопросы про модели и инструменты, а совсем другие:<\/p>\n<ul>\n<li>как сейчас выглядит delivery-процесс от появления идеи до релиза<\/li>\n<li>как команда оформляет бизнес- и системные требования<\/li>\n<li>как работает с макетами и передает контекст между участниками<\/li>\n<li>как разработчики превращают требования сначала в архитектуру, а потом в код<\/li>\n<li>как команда контролирует качество на разных этапах<\/li>\n<\/ul>\n<p>На этом месте можно возразить: «А какое вообще отношение процессы разработки имеют к внедрению ИИ?» На мой взгляд — самое прямое. Чтобы объяснить почему, представим себе две команды.<\/p>\n<h2>Первая команда<\/h2>\n<p>У первой команды процессы более-менее выстроены. Люди умеют фиксировать мысли в текстовом и визуальном виде и передавать контекст друг другу. Типичная цепочка выглядит так:<\/p>\n<p>идея → бизнес-требования и макеты → системные требования → архитектура → задачи на разработку<\/p>\n<p>В такой команде разработчики не ждут, что аналитик, менеджер или кто-то еще полностью упакует контекст за них. До того как задача попадает в работу, команда уже думает про качество, риски, архитектуру и критерии приемки. В результате заранее появляются артефакты, которые сильно упрощают реализацию.<\/p>\n<p>Обычно такие команды неплохо умеют работать асинхронно. Люди пишут документы, оставляют после себя след в виде решений, описаний и ревью-комментариев. Это помогает не только людям, но и ИИ.<\/p>\n<h2>Вторая команда<\/h2>\n<p>Во второй команде тоже может быть формальный Scrumban, но по факту работа устроена иначе. Задачи сразу падают в таск-трекер. Требования, если и пишутся, то вперемешку: бизнес-логика, технические детали и допущения лежат в одном месте. Критерии приемки толком не продуманы. Архитектура рождается уже после того, как задачу взяли в работу. О рисках вспоминают позже. Фичи выкатываются быстро, а инциденты тушатся ситуативно.<\/p>\n<p>Снаружи может казаться, что команда движется быстро. Но внутри там обычно много недосказанности, устного контекста и зависимости от конкретных людей.<\/p>\n<h2>В какой команде ИИ взлетит быстрее<\/h2>\n<p>Теперь представим, что мы хотим внедрить ИИ в обе команды. Условный критерий успеха простой: команда должна делать больше тем же составом, без выгорания и без просадки по качеству.<\/p>\n<p>Допустим, разработчику выдали доступ к ChatGPT, Claude Code или другому ассистенту. Внутри такого инструмента — большая языковая модель. Она генерирует ответ, опираясь на тот контекст, который ей передали.<\/p>\n<p>И вот здесь возникает ключевой вопрос: <b>какая из двух команд быстрее получит реальную пользу от ИИ?<\/b><\/p>\n<p>Очевидно, первая.<\/p>\n<p>Почему? Потому что у нее уже есть зафиксированный контекст: требования, ограничения, архитектурные решения, стандарты разработки, критерии приемки. Разработчик может взять эти артефакты, явно обозначить границы задачи и начать работать с агентом почти сразу.<\/p>\n<p>Пример запроса может выглядеть так:<\/p>\n<blockquote>\n<p>Ты — опытный backend-разработчик. В приложенном документе описаны бизнес- и системные требования для фичи обработки банковских выписок. В RFC-123 зафиксирована текущая архитектура. Предложи вариант реализации нового метода API GET \/bank-statements\/. Также учти наши стандарты разработки: стиль кода, подход к REST API и требования к автотестам. Сначала предложи план реализации, затем список изменений по слоям системы и набор тест-кейсов.<\/p>\n<\/blockquote>\n<p>То есть разработчик из первой команды за несколько минут собрал хороший контекст и получил шанс на действительно полезный результат.<\/p>\n<p>Во второй команде тот же разработчик, скорее всего, останется один на один с агентом и начнет вручную восстанавливать недостающий контекст: что именно нужно сделать, какие ограничения есть у системы, какие договоренности приняты в команде, какие риски важны, как вообще здесь пишут код. Даже если в итоге что-то получится, путь будет долгим, а вероятность хорошего результата — заметно ниже.<\/p>\n<h2>Вывод<\/h2>\n<p>Из этого следует простой вывод: внедрение ИИ зависит не только от интереса к технологии, но и от зрелости производственных процессов.<\/p>\n<p><b>Context is king — и в общении с людьми, и в работе с ИИ.<\/b><\/p>\n<p>Если команда не привыкла фиксировать решения, оформлять требования и создавать артефакты, на которых потом строится работа, ей будет трудно быстро получить заметный эффект от ИИ. В такой ситуации лиды начинают выгорать: сверху ждут роста эффективности, снизу люди пробуют агентов, но результат не совпадает с ожиданиями.<\/p>\n<p>Поэтому, когда меня спрашивают про внедрение ИИ в продуктовой команде, мой ответ обычно один и тот же: <b>сначала выровняйте delivery-процесс, а потом уже системно внедряйте ИИ<\/b>.<\/p>\n<p>Современные модели и агенты действительно могут сильно ускорять работу. Но в хаотичных и плохо оформленных процессах они гораздо менее эффективны. ИИ хорошо усиливает уже существующую инженерную дисциплину. Если дисциплины нет, он редко становится волшебной таблеткой.<\/p>\n",
            "summary": "Почему внедрение ИИ в продуктовых командах часто не дает результата? Разбираемся, как delivery-процессы, требования, архитектура и рабочий контекст влияют на эффективность AI-инструментов и кодинговых агентов.",
            "date_published": "2026-04-08T18:40:09+03:00",
            "date_modified": "2026-04-08T18:40:06+03:00",
            "tags": [
                "delivery-процессы",
                "LLM",
                "ИИ",
                "управление разработкой"
            ],
            "_date_published_rfc2822": "Wed, 08 Apr 2026 18:40:09 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "2",
            "_e2_data": {
                "is_favourite": false,
                "links_required": [],
                "og_images": []
            }
        },
        {
            "id": "1",
            "url": "https:\/\/agenticeng.ru\/all\/llm-and-foundation-models\/",
            "title": "Прикладной ИИ: LLM и Foundation модели",
            "content_html": "<p>В декабре 2025 года, еще работая в ПланФакте, я начал рассказывать командам о прикладном ИИ и о том, как его можно внедрять в продукты. Через несколько недель мое сотрудничество с компанией завершилось, и я решил полностью сосредоточиться на системах искусственного интеллекта.<\/p>\n<p>На новом месте быстро появилась та же задача: помогать разработчикам, пользователям GenAI-платформы и менеджменту лучше понимать большие языковые модели (LLM), их возможности и ограничения. В итоге это выросло в серию лекций, часть которых я могу опубликовать.<\/p>\n<p>Первая лекция — «LLM и foundation-модели». Это вводный материал для тех, кто хочет понять:<\/p>\n<ul>\n<li>что такое AI Engineering и чем он отличается от подхода «просто взять и использовать ChatGPT»<\/li>\n<li>что такое foundation-модели и как они работают<\/li>\n<li>как устроен Transformer без математики и лишней теории<\/li>\n<\/ul>\n<p>Лекция может быть полезна разработчикам без опыта в ML\/AI системах, QA, а также менеджерам, тимлидам и продактам, которым важно понимать основы, чтобы принимать взвешенные решения.<\/p>\n<p>Ниже — запись.<\/p>\n<div class=\"e2-text-video\">\n<video src=\"https:\/\/agenticeng.ru\/video\/LLM-i-Foundation-modeli.mp4#t=0.001\" width=\"1920\" height=\"1080\" controls alt=\"\" \/>\n\n<div class=\"e2-text-caption\">LLM и Foundation модели<\/div>\n<\/div>\n",
            "summary": "Запись лекции для разработчиков, QA и менеджеров: что такое AI Engineering, LLM, embeddings и как устроен Transformer без математики.",
            "date_published": "2026-04-06T23:20:41+03:00",
            "date_modified": "2026-04-06T23:20:22+03:00",
            "tags": [
                "LLM",
                "ИИ",
                "Лекция"
            ],
            "_date_published_rfc2822": "Mon, 06 Apr 2026 23:20:41 +0300",
            "_rss_guid_is_permalink": "false",
            "_rss_guid": "1",
            "_e2_data": {
                "is_favourite": true,
                "links_required": [],
                "og_images": []
            }
        }
    ],
    "_e2_version": 4199,
    "_e2_ua_string": "Aegea 11.5 (v4199)"
}