Как добавить YandexGPT в продукт

22 февраля 2026

YandexGPT - модели от Яндекса с OpenAI-совместимым API и сильной поддержкой русского языка. Если у вас уже есть интеграция с OpenAI, переключение занимает несколько строк. Но прежде чем браться за код, полезно увидеть рамку: почему текстовая генерация в принципе превратилась в публичный API, какие альтернативы существуют на российском рынке, какие задачи стоит отдавать LLM, а какие нет, и какие антипаттерны интеграции уже описаны на чужих ошибках. Ниже - история появления LLM-как-инфраструктуры, ландшафт российских моделей, инфраструктура в Yandex Cloud, способы интеграции, ценообразование, архитектурные паттерны для агентов, реальные примеры интеграций в российский бизнес, типовые антипаттерны и граница, за которой LLM - неправильный инструмент.

Когда LLM становится инфраструктурой продукта

Идея «вызвать языковую модель по HTTP так же, как сходить в Stripe или Twilio» - сравнительно новая. Ещё в 2019 году NLP в продуктах означало собственный pipeline на spaCy или BERT, обученный под конкретную задачу: классификатор тикетов, экстрактор сущностей, рекомендатель. Каждая такая модель требовала размеченных данных, переобучения и собственной инфраструктуры. Текстовая генерация как платный SaaS-эндпойнт массово не существовала.

Водораздел - июнь 2020 года, когда OpenAI опубликовала статью «Language Models are Few-Shot Learners» (Brown et al., NeurIPS 2020), в которой представила GPT-3. Главным был не размер модели сам по себе, а демонстрация in-context learning: одну и ту же модель можно было заставить решать новую задачу, просто описав её в промпте, без переобучения. Это превратило LLM из исследовательского артефакта в product API. К июню 2020 года первая публичная beta OpenAI API вышла на рынок, и с этого момента «дайте модели промпт - получите текст» стало стандартным способом интеграции NLP в продукт.

Andrej Karpathy в эссе «Software 2.0» (2017) сформулировал концептуальную рамку этого сдвига ещё до GPT-3. Он описал переход от Software 1.0 (программист пишет правила) к Software 2.0 (программист собирает данные, оптимизатор находит правила). LLM довели эту идею до логического конца: программист пишет промпт, и тот же набор весов используется для произвольного множества задач. Karpathy позже сам отметил, что промпт - это новый язык программирования, а LLM - новая виртуальная машина. Для продуктового инженера это означает простую вещь: если задача формулируется текстом, есть шанс, что её решит LLM по API, без собственного pipeline.

Стэнфордский отчёт «On the Opportunities and Risks of Foundation Models» (Bommasani и соавторы, 2021) ввёл термин «foundation model» и описал экономическую логику: одна большая модель обучается один раз и переиспользуется тысячами downstream-приложений. Это та же логика, что превратила в инфраструктуру электричество, операционные системы и облака - концентрация капитальных затрат на стороне поставщика, тонкий API на стороне потребителя. Для разработчика, который добавляет LLM в свой продукт, важна именно эта инверсия: модель уже обучена кем-то другим, ваша задача - правильно сформулировать запрос и обработать ответ.

Anthropic, основанная в 2021 году выходцами из OpenAI, добавила к этому ландшафту вторую опору. Их работа над Constitutional AI (Bai и соавторы, 2022) и линейка моделей Claude утвердили норму, что LLM-провайдеров на рынке должно быть несколько и переключаемых: OpenAI, Anthropic, Google, Meta, в России - Yandex, Sber, T-Bank, MTS AI. Эта норма важна для архитектора продукта - проектировать интеграцию так, чтобы переключение провайдера занимало день, а не квартал.

Российский ландшафт: YandexGPT, GigaChat, T-Bank, MTS AI

Для команд, работающих с российскими клиентами, выбор LLM-провайдера - это в первую очередь вопрос data residency и compliance. Федеральный закон 152-ФЗ требует, чтобы персональные данные граждан России обрабатывались на серверах в России; отправка ПДн в OpenAI или Anthropic без явного согласия и без локализации - формальное нарушение. Это толкает рынок к локальным провайдерам.

Базовая карта российского рынка LLM-as-API на момент написания статьи:

Выбор обычно сводится к четырём осям. Data residency - где физически лежит запрос и логи (для 152-ФЗ это критично, для GDPR-резидентов нужны другие гарантии). Стоимость - в рублях против долларов и без курсовых рисков. Латентность - запрос из московского ЦОДа в Yandex Cloud типично возвращается за десятки миллисекунд против сотен через зарубежный endpoint. Качество русского языка - российские модели обучены на корпусах с правильной морфологией и лучше держат склонения, падежи, деловой стиль; на узких задачах они часто опережают GPT-4 на русском (см. публичные бенчмарки MERA и RussianSuperGLUE в разделе «Источники»).

Эти оси не конфликтуют между собой - они просто сужают список. Если вашему продукту критична стенограмма телефонного звонка - SaluteSpeech у Сбера; если нужна тесная интеграция с Yandex Cloud (Object Storage, Managed Postgres, AI Studio) - YandexGPT; если вы T-Bank-friendly финтех с готовым контрактом - смотрите внутренний стек. На уровне архитектуры важно одно: код вызова LLM должен быть отделён от выбора провайдера, чтобы перенос занимал часы, а не недели.

Инфраструктура в Yandex Cloud

Прежде чем делать первый запрос к API, нужно подготовить облачное окружение. Это занимает 10–15 минут, но сделать один раз правильно - значит не возвращаться к этому при каждом новом сервисе.

Создание Folder и подключение Foundation Models

В Yandex Cloud ресурсы организованы по Folder (папкам) внутри облака. Folder - это единица изоляции: у неё собственные права доступа, квоты и история биллинга. Для каждого продукта или окружения рекомендуется создавать отдельный Folder.

1. Откройте консоль Yandex Cloud и создайте новый Folder (или выберите существующий).
2. В разделе AI Studio или Model Gallery включите сервис Foundation Models для нужного Folder - без этого шага API возвращает 403.
3. Зафиксируйте Folder ID - он нужен в каждом запросе к API для маршрутизации биллинга и прав.

Аутентификация

Для серверных интеграций доступны два способа аутентификации:

Для старта удобнее API Key: создаёте сервисный аккаунт, выдаёте ему роль ai.languageModels.user на Folder, генерируете ключ - и кладёте его в переменную окружения YANDEX_CLOUD_API_KEY. Folder ID - в YANDEX_CLOUD_FOLDER.

Выбор способа интеграции

YandexGPT предлагает два способа вызова модели. Выбор зависит от того, есть ли у вас уже обвязка под OpenAI SDK, и насколько вы хотите контролировать детали запроса.

A. OpenAI-совместимый API

Если в вашем проекте уже есть клиент под OpenAI - это самый быстрый путь. Меняете base_url и модель, добавляете параметр project с Folder ID - и всё остальное работает как прежде.

import openai
import os

YANDEX_CLOUD_API_KEY = os.environ["YANDEX_CLOUD_API_KEY"]
YANDEX_CLOUD_FOLDER  = os.environ["YANDEX_CLOUD_FOLDER"]

client = openai.OpenAI(
    api_key=YANDEX_CLOUD_API_KEY,
    base_url="https://ai.api.cloud.yandex.net/v1",
    project=YANDEX_CLOUD_FOLDER,
)

resp = client.responses.create(
    model="yandexgpt-lite",
    input=[
        {
            "role": "system",
            "content": "Ты помощник: отвечай кратко, структурно.",
        },
        {
            "role": "user",
            "content": (
                "Суммаризируй заявку клиента и выдели поля: "
                "компания, контакт, запрос."
            ),
        },
    ],
)

print(resp.output_text)

B. Нативный REST Foundation Models API

Прямой вызов эндпойнта генерации даёт полный контроль над параметрами запроса: температура, maxTokens, поддержка tool-calls согласно спецификации. Используйте этот вариант, если нужны возможности, которые OpenAI-совместимый интерфейс ещё не проксирует.

POST https://llm.api.cloud.yandex.net/foundationModels/v1/completion

Authorization: Api-Key <YANDEX_CLOUD_API_KEY>
Content-Type: application/json
x-folder-id: <YANDEX_CLOUD_FOLDER>

{
  "modelUri": "gpt://<FOLDER_ID>/yandexgpt-lite/latest",
  "completionOptions": {
    "stream": false,
    "temperature": 0.2,
    "maxTokens": 1000
  },
  "messages": [
    {
      "role": "system",
      "text": "Ты помощник: отвечай кратко, структурно."
    },
    {
      "role": "user",
      "text": "Суммаризируй заявку клиента и выдели поля: компания, контакт, запрос."
    }
  ]
}

Ответ приходит в поле result.alternatives[0].message.text. Для асинхронного режима - отдельный эндпойнт /foundationModels/v1/completionAsync, который возвращает operation_id, а результат получаете поллингом.

Выбор модели: Lite vs Pro

Между YandexGPT Lite и Pro - не «дешёвая и дорогая версии одной модели», а две разные точки на кривой «цена / качество / контекст». Lite оптимизирована под высокочастотные узкие задачи: классификация, извлечение полей, краткая суммаризация. Pro оптимизирована под задачи с длинным контекстом и составным рассуждением: ведение многошагового диалога, анализ документа целиком, генерация длинного связного текста в деловом стиле.

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

1. Сколько входных токенов в запросе? Если меньше двух тысяч - Lite справится. Если стабильно за 8 тысяч - нужен Pro с контекстом 32k токенов; на Lite вы либо не уложитесь, либо потеряете куски в начале.
2. Сколько шагов рассуждения нужно? Один шаг (классификация одного сообщения, извлечение полей из одной заявки) - Lite. Многошаговые цепочки (планирование - проверка - доработка - оформление) - Pro.
3. Виден ли результат конечному пользователю? Если ответ читает человек напрямую (деловое письмо, ответ клиенту) - Pro заметно лучше. Если результат - JSON для следующего шага пайплайна, Lite чаще достаточно.

Хорошая практика - не выбирать одну модель на весь сервис, а маршрутизировать каждый шаг отдельно. Классификатор входящего сообщения - Lite. Разбор и обновление карточки сделки с длинной историей - Pro. Генерация финального документа клиенту - Pro. Эта стратегия в литературе по агентным архитектурам известна как model routing - см. инженерные посты Anthropic про «small models for orchestration, large models for hard reasoning» (ссылка в разделе «Источники»).

Какие задачи решает YandexGPT

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

Генерация текста

Ответы клиенту, письма, инструкции, сценарии разговоров, краткие резюме - всё, где нужен качественный русскоязычный текст по заданным параметрам. YandexGPT заметно лучше справляется с нюансами русского языка: склонения, падежи, стиль деловой переписки.

Структурирование входящих данных

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

Классификация

Prompt-based классификация: маршрутизация обращений по типу, проставление тегов, определение приоритета и тона. Не требует файн-тюнинга - достаточно хорошего промпта с примерами (few-shot). Работает точнее жёстких правил на нестандартных формулировках.

Работа с длинным контекстом

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

Стоимость: токены, агенты, оценка

Ценообразование в AI Studio - по токенам (вход и выход считаются отдельно). Инструменты агентов тарифицируются отдельно. Ниже - актуальные цены без НДС.

Текстовая генерация

Инструменты агентов

Грубая оценка стоимости одного шага диалога

Допустим, один шаг агента - это ~800 input-токенов (системный промпт + история + входящее сообщение) и ~300 output-токенов (ответ модели). На YandexGPT Lite в синхронном режиме:

Input:  0.8 × $0.001639 ≈ $0.00131
Output: 0.3 × $0.001639 ≈ $0.00049
 - -  - -  - -  - -  - -  - -  - -  - -  - -  - -  -
Итого за шаг:          ≈ $0.0018

1 000 шагов диалога - около $1.80. Для продукта с сотнями пользователей в день это вполне управляемая статья расходов. При переходе на Pro - умножайте примерно на 4.

Архитектурные паттерны для агентов

Когда LLM перестаёт быть «one-shot вопрос - ответ» и встраивается в продуктовый поток, появляются повторяющиеся архитектурные паттерны. Большинство из них описаны в инженерных постах Anthropic «Building Effective Agents» (декабрь 2024) и в публичных рекомендациях OpenAI по агентным системам. Все они применимы к YandexGPT - модель меняется, паттерны нет.

Multi-step reasoning через цепочку специализированных шагов

Соблазн начинающего разработчика - написать один большой промпт, который «разберёт сообщение, обновит карточку, сформулирует ответ и подготовит документы». Такой промпт работает плохо: модель размазывает внимание, путает форматы, иногда возвращает не JSON, а свободный текст. Правильный паттерн - chain-of-prompts: каждая задача отдельным шагом с собственным системным промптом, собственной моделью (Lite или Pro) и собственным форматом ответа. Один шаг - одна задача.

Fallback to human

Любая агентная система должна заранее проектировать переход на оператора. Триггеры типичны: модель вернула confidence < 0.6; пользователь нажал «соединить с человеком»; распознан чувствительный сценарий (жалоба, юридический вопрос, упоминание персональных данных третьих лиц). Передача оператору - это не «упало», а нормальный путь работы. У оператора должна быть полная история диалога и все артефакты, которые модель уже собрала; он не должен начинать с нуля.

Cost guardrails

У каждого пользователя или сессии должен быть бюджет токенов. Без него один пользователь, нашедший как зациклить диалог, может за час съесть месячный лимит на API. Реализация простая: счётчик потраченных токенов в Redis или БД, после превышения порога - graceful degradation (ответ «обратитесь к оператору», более дешёвая модель, отказ выполнить запрос). Аналогично - rate limit по запросам в минуту.

Контекст через RAG, а не через переразбухание промпта

Соблазн «положить всю базу знаний в системный промпт» очень велик: технически работает на YandexGPT Pro с 32k контекста. Но каждый запрос платится по токенам, и 30k токенов системного промпта + 2k собственно вопроса означают, что вы платите за базу знаний на каждый запрос. Правильный паттерн - retrieval-augmented generation: храните базу в векторном индексе (в Yandex Cloud это Managed Service for OpenSearch с k-NN или собственный индекс на pgvector), при запросе ищете top-3-5 релевантных фрагментов и кладёте их в промпт. Это снижает стоимость в десятки раз и обычно повышает качество за счёт фокуса.

Структурированный вывод и его валидация

Промпт, который заканчивается «верни JSON», возвращает JSON в подавляющем большинстве случаев - но не всегда. Модель может добавить пояснение, обернуть JSON в markdown, потерять кавычку. Production-код должен валидировать ответ через схему (jsonschema, pydantic) и иметь стратегию retry: при невалидном ответе - повторный вызов с явной инструкцией «верни ТОЛЬКО валидный JSON по схеме», максимум 2-3 попытки, потом fallback. Никогда не JSON.parse(resp) без обёртки.

Пример: агент для ведения сделки

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

Роль агента в процессе

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

Что делает YandexGPT на каждом шаге

1. Разбор входящего сообщения (Telegram, почта, форма)

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

Системный промпт (упрощённо):

Ты - ассистент по обработке входящих заявок.

Задача: проанализируй сообщение и верни JSON:
{
  "type": "lead" | "question" | "change_request" | "problem",
  "entities": {
    "client_name": str | null,
    "company": str | null,
    "service": str | null,
    "deadline": str | null,
    "budget": str | null,
    "contact_channel": str | null,
    "documents_mentioned": list[str]
  },
  "confidence": float  // 0.0–1.0
}

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

Пользовательское сообщение (входящая заявка):

Добрый день! Мы ООО "Ромашка", ищем подрядчика для разработки CRM.
Бюджет - до 800 тысяч, нужно к 1 июня. Контакт - Иванов Сергей,
можно писать в Telegram @ivanov_s. Готовы предоставить ТЗ.

Модель возвращает структуру, которая сразу ложится в карточку сделки - не нужен ручной разбор.

2. Нормализация в карточку сделки

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

Системный промпт:

Ты ведёшь карточку сделки. Текущее состояние:
<state>{{ deal_state_json }}</state>

На основе нового сообщения обнови карточку и верни JSON:
{
  "stage": "new" | "data_collection" | "docs_requested" | "ready",
  "missing_fields": [...],
  "missing_docs": [...],
  "next_action": "Краткое описание следующего шага",
  "updated_fields": { ... }
}

3. Управление диалогом

Агент генерирует точечный запрос одного недостающего поля - не список из десяти вопросов сразу. Один шаг - один вопрос. После ответа клиента - обновление карточки и следующий запрос (если ещё что-то нужно) или подведение итогов:

Системный промпт:

На основе карточки сделки и списка missing_fields задай клиенту
один конкретный вопрос. Тон - деловой, вежливый, без лишних слов.
Не перечисляй все пропущенные поля - только один, наиболее важный.

4. Подготовка артефактов для исполнителя

Когда карточка заполнена, агент генерирует:

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

Минимальный стек: агентный цикл

# Псевдокод агентного цикла
def process_message(deal_id, new_message):
    deal    = db.get_deal(deal_id)       # Текущая карточка сделки
    history = db.get_history(deal_id)    # Последние N сообщений

    # Шаг 1: классификация + извлечение сущностей (дешёвая модель)
    parsed = yandex_gpt(
        system=CLASSIFY_PROMPT,
        user=new_message,
        model="yandexgpt-lite",
    )

    # Шаг 2: обновление карточки (Pro - нужен больший контекст)
    updated_deal = yandex_gpt(
        system=UPDATE_DEAL_PROMPT.format(state=deal.to_json()),
        user=parsed.to_json(),
        model="yandexgpt-pro",
    )

    db.update_deal(deal_id, updated_deal)

    # Шаг 3: запрос недостающих данных
    if updated_deal["stage"] != "ready":
        reply = yandex_gpt(
            system=NEXT_QUESTION_PROMPT,
            user=updated_deal.to_json(),
            model="yandexgpt-lite",
        )
        return reply

    # Шаг 4: артефакты для исполнителя
    artifacts = yandex_gpt(
        system=ARTIFACTS_PROMPT,
        user=updated_deal.to_json(),
        model="yandexgpt-pro",
    )
    db.save_artifacts(deal_id, artifacts)
    return "Сделка готова к передаче исполнителю."

Почему здесь YandexGPT "в тему"

Задача - чистая работа с текстом, контекстом, структурированием и контролем полноты. Никаких специфических вычислений или внешних данных. YandexGPT Pro с контекстом 32k токенов держит весь тред сделки целиком - не теряет контекст при длинных переговорах. Качество русскоязычного текста в деловом стиле - на уровне, который заметен клиентам.

Реальные примеры интеграции в российский бизнес

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

Yandex Practicum - онлайн-помощник студентам. Yandex Practicum - собственный EdTech-продукт Яндекса, и логично, что они одними из первых публично запустили в нём AI-помощника на YandexGPT. Помощник отвечает на вопросы по материалам курса, объясняет код, подсказывает направление поиска ошибки. Продуктовая ценность здесь не «заменить наставника», а снять с наставников типовые повторяющиеся вопросы и оставить им сложные методические разборы. Подробности - в публикациях Яндекса о продуктах AI Studio (ya.ru/ai) и в инженерном блоге Яндекса.

Sber GigaChat в Сбербанк Онлайн. Сбер интегрировал GigaChat в потребительское приложение - в чат поддержки и в отдельные сценарии (объяснение операций, помощь с продуктами). Это редкий публичный пример массовой интеграции LLM в b2c-приложение в России; масштаб - десятки миллионов активных пользователей. Описание архитектуры и подходов - в материалах SberDevices и в выступлениях команды на конференциях AI Journey (aij.ru). Важный урок этой интеграции - строгая граница между «информационный ответ» и «транзакция»: GigaChat объясняет, но решения по деньгам всегда требуют явного подтверждения и идут через старый деревянный flow.

Bitrix24 - встроенный AI-копилот. Bitrix24, доминирующая на российском рынке CRM-платформа, в 2023-2024 году встроила AI-функции в редактор писем, в обработку лидов, в чат-боты. Под капотом - партнёрство с Яндексом и собственные модели. Пример показывает, что LLM в CRM становится feature-параметром: без AI-копилота продукт перестаёт восприниматься как «современный». Сама компания регулярно публикует обновления функциональности (bitrix24.ru); подробности архитектуры - в их product-блоге. Стилизованный паттерн для команд, повторяющих этот ход: модель отвечает за черновик, человек принимает финальное решение, корректировки используются для дальнейшего улучшения промптов.

Avito - модерация контента и экстрактивные задачи. Avito публично описывает, что использует LLM в pipeline модерации объявлений, для извлечения структурированных полей из произвольного текста описания, для борьбы с дубликатами и мошенничеством. Это типовая работа NLP в e-commerce, и Avito - один из немногих российских игроков, кто масштабно публикует свои инженерные подходы (блог Avito на Habr). Стилизованный паттерн модерации: классификатор первого уровня (быстрая модель отбрасывает явный спам), LLM второго уровня для пограничных случаев, ручная модерация для самых сложных. Многоуровневый стек снижает нагрузку на дорогие модели в десятки раз.

T-Bank голосовой ассистент в мобильном приложении. T-Bank (бывший Tinkoff) одним из первых в российской рознице вложился в собственный голосовой ассистент в мобильном банке. Архитектура построена на стеке T-Bank AI: ASR для распознавания речи, NLU для понимания намерения, диалоговый менеджер с маршрутизацией в LLM или в детерминированные сценарии. Стилизованный паттерн интеграции в финтех: критические транзакционные операции (перевод денег, открытие кредитной карты) идут через жёсткие сценарии с явным подтверждением; информационные запросы (баланс, история, объяснение операции) - через LLM с обязательной валидацией ответов перед показом пользователю.

Полезный сравнительный вывод. Эти пять интеграций показывают одно и то же на разных рынках: LLM хорошо работает там, где раньше пользователь упирался в форму или в ожидание оператора (Practicum - очередь к наставнику, Сбер и T-Bank - очередь в чат поддержки, Bitrix - ручное составление писем, Avito - очередь модератора). Везде, где есть очередь к человеку из-за повторяющихся однотипных вопросов, LLM сокращает её на 40-70% при правильно спроектированном fallback. Везде, где требуется юридически значимое решение или транзакция с деньгами, LLM остаётся в роли черновика, а не подписанта.

Антипаттерны интеграции

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

Vendor lock-in: жёсткое прибивание к одному провайдеру. Команда пишет код прямо против YandexGPT REST API, со всеми его особенностями полей и ошибок, и через год оказывается в ситуации, когда нужно протестировать GigaChat или OpenAI - и переписывание занимает недели. Правильный подход - тонкий собственный интерфейс (LLMClient с методами complete(), stream(), extract_json()), за которым прячется адаптер конкретного провайдера. Переключение должно занимать день, а не квартал.

Отсутствие PII-редактирования перед отправкой. Это не только этический, но и юридический антипаттерн. По 152-ФЗ персональные данные граждан России не должны утекать за границу инфраструктуры обработчика без согласия. YandexGPT - российский сервис, и формально это решает проблему, но не решает другую: логи запросов хранятся, и попадание туда паспортных данных, СНИЛС, номеров карт - утечка с ответственностью. Правильно - PII redaction слой перед вызовом модели: маскирование номеров карт, паспортов, телефонов, email. Если модели нужно работать с этими полями - использовать токенизацию (placeholder), а реальные значения подставлять уже в финальный текст после генерации.

Отсутствие token budget на пользователя. Без бюджета один зацикленный пользователь или баг в клиенте, который шлёт запросы в loop, может за час превысить недельный лимит на API. Правильно - rate limit на уровне rps + cumulative token budget на сессию или сутки. После превышения - graceful degradation, не отказ.

Over-prompting: вся база знаний в каждом запросе. Команды, открывшие для себя длинный контекст YandexGPT Pro, иногда начинают пихать в системный промпт всю документацию продукта - 25 000 токенов «чтобы модель точно знала всё». В прайс это превращается в линейное умножение всех расходов, в качество - в размытость ответа (модель теряется в массиве). Правильный путь - RAG: индекс + ретривер + 3-5 релевантных фрагментов в промпте. Дешевле и точнее.

Fallback на rules никогда не реализован. Команда пишет «если LLM упала - вернём 500». В продакшне это значит, что любой инцидент у Yandex Cloud (а они бывают) превращается в полный отказ продукта. Правильно - всегда иметь хотя бы тривиальный fallback: для классификации - правила по ключевым словам; для ответов - заготовленные шаблоны с предложением связаться с оператором; для извлечения сущностей - регулярки для самых частых форматов.

LLM как классификатор там, где хватает простой модели. Если задача - классифицировать тикет на 5 категорий, и у вас есть тысячи размеченных примеров, обученный SVM или distilled BERT даст точность выше LLM, latency в 10-100 раз меньше и стоимость в 1000 раз меньше. LLM выигрывает там, где разметка дорогая или категории меняются. Использовать LLM как «универсальный классификатор для всего» - дорогая привычка.

Игнорирование морфологии в промптах. Промпт, написанный на английском или с грубым русским, на русскоязычном входе работает заметно хуже. Особенно болезненно - инструкции типа «extract entity»: модель воспринимает это как формальную инструкцию, а не как часть задачи на русском. Правильно - промпт на том же языке, что и пользовательский ввод; примеры few-shot на русском; явное указание ожидаемой формы ответа («ответ - именительный падеж, единственное число»).

Отсутствие версионирования промптов. Через полгода работы продукта вы обнаружите, что половина проблем - «мы что-то поменяли в промпте, и теперь хуже работает на Х». Без версионирования и регрессионных тестов на промпты вы не сможете быстро откатиться. Правильно - промпты в репозитории, тесты на корпусе из 30-50 типовых входов, golden output для регрессии.

Когда LLM - неправильный инструмент

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

Детерминированная классификация при наличии разметки. Если у вас есть 5 000 размеченных примеров и стабильный набор категорий, классификатор на distilled-модели (например, RuBERT или fine-tuned маленький энкодер) даст точность 95%+, latency 10-50 мс, стоимость почти ноль. LLM в этой задаче даст 85-90% при latency в секунды и стоимости в тысячи раз выше. LLM имеет смысл, когда категории меняются часто или разметка отсутствует.

Точная математика и арифметика. LLM генерирует токен за токеном по статистике; «подсчитать сумму НДС с точностью до копейки» - не та задача. Правильный паттерн - tool use или code generation: модель не считает сама, а пишет код или вызывает функцию (calculate_vat(amount, rate)), которая выполняется детерминированно. Не доверяйте LLM числовых вычислений, где правильность критична.

Жёсткая валидация формата. Распарсить ИНН, КПП, СНИЛС, дату в формате DD.MM.YYYY - регулярка делает это с точностью 100%, мгновенно и бесплатно. LLM здесь даст 99%, но непредсказуемо ошибётся в одном случае из ста и не предупредит об этом. Используйте структурированный output модели только там, где формат «свободный» (имя клиента, описание услуги), а жёсткие поля валидируйте классическими методами.

Генерация SQL или кода без последующей валидации. LLM хорошо пишет правдоподобные SQL-запросы, и часть из них корректна. Но LLM с одинаковой уверенностью напишет DROP TABLE users в ответ на «удалить устаревшие записи». Никогда не выполняйте сгенерированный SQL/код напрямую: всегда через ограниченное окружение (read-only пользователь, sandbox), всегда с предварительным показом запроса человеку, всегда с журналированием.

Высокообъёмные низкоценные задачи. Если задача стоит 0.001 рубля «человеческой ценности» (классификация одного из миллионов сообщений в секунду), а вызов LLM стоит 0.1 рубля, экономика не сходится никогда. Считайте unit economics до интеграции: «сколько в день вызовов x цена вызова vs. ценность результата». Если нет - либо задачу решает не LLM, либо нужно спускаться на дешёвую модель (Lite, distilled) и убирать всё лишнее.

Real-time задачи с жёстким SLA на latency. Типовой ответ YandexGPT - десятки и сотни миллисекунд для Lite, секунды для Pro. Если ваш SLA - 50 мс на ответ (например, ranking в поисковой выдаче), LLM не подойдёт. Подойдёт - предобученный embedder + ANN-индекс. LLM имеет смысл там, где пользователь готов подождать секунду-две.

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

Резюме

YandexGPT - рабочий выбор для продуктов с русскоязычным текстом. Интеграция через OpenAI-совместимый API занимает часы, не недели. На старте учтите следующее:

• Контекст рынка: LLM - инфраструктура, а не магия. Выбор провайдера (Yandex, Sber, T-Bank, MTS AI) делается по data residency, цене в рублях, латентности и качеству русского языка.
• Инфраструктура: отдельный Folder на окружение, сервисный аккаунт с минимальными правами, API Key в переменных окружения.
• Способ интеграции: OpenAI-совместимый API - быстрый старт; нативный REST - когда нужен полный контроль над параметрами и поддержка tool-calls.
• Модель: Lite для простых задач (суммаризация, классификация, извлечение сущностей), Pro для длинного контекста и сложных генераций. Маршрутизируйте по задачам, а не выбирайте одну на сервис.
• Стоимость: Lite в синхронном режиме - около $0.0018 за один типичный шаг диалога. Считайте токены заранее, оптимизируйте промпты, ставьте token budget на пользователя.
• Архитектурные паттерны: chain-of-prompts, fallback to human, cost guardrails, RAG вместо переразбухшего промпта, валидация структурированного вывода.
• Антипаттерны: vendor lock-in, отсутствие PII-редактирования, over-prompting, отсутствие fallback на rules, использование LLM как классификатора без необходимости.
• Граница применимости: детерминированная классификация при наличии разметки, точная математика, жёсткая валидация формата, real-time с SLA < 100 мс - не для LLM.
• Пайплайн: разбивайте агента на маленькие специализированные шаги (классификация → обновление карточки → запрос → артефакты). Один промпт - одна задача.

Источники

Основополагающие работы и фреймворки

• Brown et al. Language Models are Few-Shot Learners (NeurIPS 2020). Статья, представившая GPT-3 и идею in-context learning - точка, с которой LLM стали product API.
• Andrej Karpathy. Software 2.0 (2017). Концептуальная рамка перехода от написанных правил к обученным моделям.
• Bommasani et al. On the Opportunities and Risks of Foundation Models (Stanford CRFM, 2021). Введение термина «foundation model» и анализ их влияния как инфраструктуры.
• Bai et al. Constitutional AI: Harmlessness from AI Feedback (Anthropic, 2022). Метод, лежащий в основе моделей Claude.
• Anthropic. Building Effective Agents (декабрь 2024). Инженерные паттерны для агентных систем: chain, routing, parallelization, evaluator-optimizer.

Российский ландшафт и бенчмарки

• Yandex Foundation Models - официальная документация по YandexGPT (цены и доступные модели могут меняться).
• GigaChat API - документация SberDevices.
• SaluteSpeech - распознавание и синтез речи от Сбера.
• MERA - российский бенчмарк оценки LLM на русском языке.
• Russian SuperGLUE - набор задач для оценки понимания русского.

Реальные кейсы и блоги

• Yandex AI products - публикации Яндекса про AI Studio, Practicum-помощника, продуктовые применения.
• AI Journey - конференция Сбера, доклады про GigaChat в Сбербанк Онлайн и других сценариях.
• Блог Avito на Habr - инженерные посты про NLP и ML в e-commerce-модерации.
• Bitrix24 - примеры встроенных AI-функций в CRM на российском рынке.
• Блог T-Bank на Habr - публикации про NLP-стек и голосовые ассистенты в финтехе.

Compliance и данные

• 152-ФЗ «О персональных данных» - базовое требование data residency для российских пользователей.