Думаете, что знаете все про LLM? Тогда мы идем к вам

Почти все сегодня знают про LLM и могут сравнивать модели, спорить о качестве ризонинга, важности контекста и стоимости токенов.

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

Между тем инструменты для этого уже есть, например Evolution Foundation Models. И благодаря широкому пулу моделей помогают сделать продвинутый ИИ доступным для всех, а не только для сценариев разработки. 

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

Какие модели есть в сервисе

В Evolution Foundation Models у нас доступен большой набор моделей — как внутренних (передовые open-source модели, развернутые на мощностях Cloud.ru в ЦОДах на территории РФ), так и от внешних провайдеров. Все они уже готовы к использованию через OpenAI API и Anthropic API. Причем список моделей постоянно растет и обновляется — на момент написания статьи их более 50ти.

Из них можно собрать прикладной рабочий пайплайн: для поиска, суммаризации, анализа документов, RAG, поддержки и внутренних агентов.

У моделей есть несколько ключевых функций, которые напрямую влияют на сценарии внедрения: Structured Output, Reasoning, Function Calling. То есть выбрать можно не только по названию (и не нужно), но и по тому, подойдет ли она для строгого JSON-ответа, многошагового анализа и интеграции с внешними функциями.

Отдельно можно посмотреть и учесть диапазон размера контекстного окна и модальность.

Далее в статье рассмотрю четыре класса моделей и для каждой расскажу про тип задач и пайплайн.

Группа 1. Универсальные LLM для повседневных задач

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

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

В таких задачах нам обычно важны: скорость запуска сценария, умеренная стоимость токенов, предсказуемость ответа и возможность быстро проверить гипотезу в песочнице, при необходимости изменяя такие параметры, как Temperature, Maximum tokens, Presence penalty и Top-p threshold.

Оговорюсь в рамках всей статьи: песочница в Evolution Foundation Models подходит прежде всего для самых базовых и быстрых проверок гипотез. Например, чтобы посмотреть, как модель отвечает на короткий текстовый запрос, как меняется результат при другой температуре или как она соблюдает заданный формат ответа.

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

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

Какие модели входят в группу

В качестве универсального слоя в Evolution Foundation Models доступны:

• GigaChat 2 Max — внутренняя модель, контекст 131 072 токена.

• openai/gpt-5.4 — внешняя модель, Function Calling, Structure Output, Reasoning, Vision, контекст 1 050 000 токена.

• Qwen 3.6 — внутренняя модель, Function Calling, Structure Output, Reasoning, Vision, контекст 262 144 токена.

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

Какие задачи они закрывают

Маркетинг и продукт

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

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

• На вход подать батч из 20–50 отзывов, но не смешивать в одном запросе разные продуктовые линейки, чтобы не размазывать кластеры.

• В системном промпте разделить три слоя: issue_cluster, sentiment, evidence_quote, чтобы модель не смешивала интерпретацию с цитатой.

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

• Если нужен формат для последующей аналитики, сразу просить табличный или JSON-ответ, а не текст в свободном формате (этот свободный формат будет каждый раз разный).

Пример системного промпта:

Ты анализируешь отзывы пользователей о продукте.
Для каждого отзыва верни:
— issue_cluster
— sentiment
— evidence_quote
— product_area

Правила:
— Не обобщай несколько отзывов в одну строку.
— evidence_quote должна быть дословной короткой цитатой.
— Если отзыв неясный, ставь issue_cluster="unclear".

Финансы и бэк-офис

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

Мини-инструкция для типовой задачи — собрать бриф деловой переписки:

• На вход подавать не весь почтовый архив, а только одну цепочку писем с темой и последними релевантными ответами.

• В промпте явно разделить, что модель должна вернуть: key_points, open_questions, requested_actions, deadlines.

• Если письмо чувствительное, перед отправкой нужно обезличить реквизиты и персональные данные.

• Для таких задач лучше ограничивать maximum tokens, чтобы бриф не превращался в пересказ каждого письма.

Пример системного промпта:

Ты готовишь служебное summary по цепочке деловой переписки.
Верни ответ в 4 блоках:
1. key_points
2. open_questions
3. requested_actions
4. deadlines

Правила:
— Не добавляй фактов вне переписки.
— Если срок не указан явно, помечай его как not_specified.
— Если действие не назначено, ставь owner=unknown.

А если нужно учитывать базу знаний компании при работе с такими файлами, то смотрим в сторону RAG поверх LLM.

Поддержка

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

Мини-инструкция для типовой задачи — классифицировать входящее обращение:

• Вход должен состоять из одного обращения и максимум из 1–2 контекстных полей, например канала и темы, иначе модель начнет путать кейсы.

• Системный промпт должен сразу требовать только JSON и запрещать объяснения вне схемы (свободный формат приведет к нестабильным выводам).

• Температуру лучше держать близко к нулю, потому что здесь важна воспроизводимость, а не вариативность. Но и это не панацея.

• После ответа нужен простой валидатор: категория заполнена, приоритет входит в разрешенный список, саммари не длиннее заданного лимита.

Пример промпта:

Ты классифицируешь клиентские обращения.
Верни только JSON.

Схема:
{
  "category": "string",
  "priority": "low|medium|high",
  "summary": "string",
  "needs_human_review": true
}

Правила:
— Не придумывай факты.
— Если данных недостаточно, ставь needs_human_review=true.
— Саммари не длиннее 250 символов.

А еще покажу пример API-вызова для Evolution Foundation Models через OpenAI-совместимый формат:

from openai import OpenAI

client = OpenAI(base_url="https://foundation-models.api..ru/v1", api_key="<TOKEN>")

response = client.chat.completions.create(
    model="Qwen/Qwen3.6-35B-A3B",
    temperature=0.2,
    max_tokens=300,
    messages=[
        {"role": "system", "content": "Ты классифицируешь обращения и отвечаешь только JSON."},
        {"role": "user", "content": "Клиент пишет: не проходит оплата по карте, срочно нужен счет."}
    ]
)

Группа 2. Reasoning-модели для сложного анализа

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

Эти модели имеет смысл подключать там, где цена логической ошибки выше цены дополнительного токена.

Для них типичен большой контекст, поддержка Structured Output, Function Calling и более комплексных и длинных ответов, если задача требует объяснения вывода.

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

Какие модели входят в группу

В Evolution Foundation Models к этой группе можно отнести:

• zai-org/GLM-5.1 — внутренняя модель с Function Calling, Structured Output и Reasoning, контекст 202 752 токена;

• MiniMaxAI/MiniMax-M3 — внутренняя модель с Function Calling, Structured Output и Reasoning, контекст 196 608 токенов;

• Qwen/Qwen3.5-397B-A17B — внутренняя модель с Function Calling, Structured Output, Reasoning и Vision, контекст 262 144 токена;

• openai/gpt-5 — внешняя модель с Function Calling, Structured Output, Reasoning и Vision, контекст 400 000 токенов;

• google/gemini-2.5-pro — внешняя модель с Function Calling, Structured Output, Reasoning и Vision, контекст 1 048 576 токенов;

• anthropic/claude-opus-4.6 — внешняя модель с Function Calling, Structured Output, Reasoning и Vision, контекст 1 000 000 токенов.

Какие задачи они закрывают

Финансы, аудит, комплаенс

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

Мини-инструкция для типовой задачи — сравнить новую редакцию регламента со старой:

• На вход подавать обе версии документа и короткое описание бизнес-процесса, которого касается изменение. Иначе модель будет видеть только текстовую дельту, но не прикладной контекст.

• В системном промпте разделить шаги — сначала changes, затем affected_processes, затем risk_level, затем recommended_actions.

• Просить модель не просто перечислить различия, а маркировать изменения как редакционные или влияющие на процесс.

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

Пример системного промпта:

Ты анализируешь различия между версиями регламента.

Инструкция:
1. Выдели только фактические изменения.
2. Отметь, какие изменения влияют на процесс, а какие — редакционные.
3. Укажи затронутые подразделения.
4. Оцени риск по шкале low/medium/high.
5. Верни только JSON.

Схема:
{
  "changes": [],
  "process_impact": [],
  "affected_units": [],
  "risk_level": "low|medium|high",
  "recommended_actions": []
}

{

  "changes": [

    {

      "section": "3.1",

      "description": "Сокращение времени реакции на критический инцидент с 15 до 10 минут.",

      "type": "process",

      "risk": "high"

    },

    {

      "section": "3.2",

      "description": "Сокращение времени локализации критического инцидента с 1 часа до 45 минут.",

      "type": "process",

      "risk": "high"

    },

    {

      "section": "4.1",

      "description": "Добавление подразделения CSR в состав участников расследования инцидентов.",

      "type": "process",

      "risk": "medium"

    },

    {

      "section": "5.1",

      "description": "Введено обязательное согласование отчета об инциденте с руководителем SOC.",

      "type": "process",

      "risk": "medium"

    },

    {

      "section": "6.1",

      "description": "Сокращение срока уведомления клиента об инциденте с 24 часов до 4 часов.",

      "type": "process",

      "risk": "high"

    },

    {

      "section": "7.1",

      "description": "Добавлен новый тип критического инцидента — массовая фишинговая рассылка от корпоративного домена.",

      "type": "process",

      "risk": "medium"

    },

    {

      "section": "7.1",

      "description": "Уточнение формулировки: 'массовая рассылка фишинговых писем от корпоративного домена' вместо общей формулировки. Редакционное изменение по запросу юристов, не меняет сути.",

      "type": "editorial",

      "risk": "low"

    }

  ],

  "process_impact": [

    "Ужесточение SLA по реакции и локализации критических инцидентов требует пересмотра дежурств SOC и автоматизации эскалации.",

    "Включение CSR в расследование меняет процесс коммуникации с клиентом во время инцидента.",

    "Согласование отчета с руководителем SOC добавляет новый шаг в процесс закрытия инцидента.",

    "Сокращение срока уведомления клиента до 4 часов требует выделения дежурного менеджера или шаблонов экстренной коммуникации."

  ],

  "affected_units": [

    "SOC",

    "ИТ-инфраструктура",

    "Юридический отдел",

    "CSR (подразделение по работе с клиентами)",

    "Служба поддержки / аккаунт-менеджеры"

  ],

  "risk_level": "high",

  "recommended_actions": [

    "Провести расчет нагрузки на SOC с учетом нового SLA 10/45 минут — при необходимости увеличить штат дежурных.",

    "Согласовать с CSR новый регламент их участия в расследованиях и выделить ответственных.",

    "Назначить руководителя SOC утверждающим лицом и формализовать критерии согласования отчетов.",

    "Подготовить шаблоны экстренных уведомлений для клиентов, чтобы укладываться в 4-часовой срок.",

    "Настроить мониторинг корпоративной почты на предмет массовых фишинговых рассылок (новый критический кейс)."

  ]

}

Маркетинг

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

Мини-инструкция для типовой задачи — сделать разбор клиентских жалоб с гипотезами:

• Подавать отзывы батчами по сегментам или продуктовым линиям, чтобы не смешивать разные мотивации клиентов в одном анализе.

• Просить модель возвращать три отдельных блока: observations, hypotheses, actions.

• Для повышения устойчивости полезно требовать указывать evidence_quotes — короткие цитаты, на которых основан вывод.

• Не смешивать в одном запросе анализ отзывов и генерацию маркетинговых рекомендаций: сначала — анализ, а потом — отдельный шаг по гипотезам.

Пример системного промпта:

Ты анализируешь клиентские жалобы.
Разделяй факты, гипотезы и действия.

Верни структуру:
— observations
— evidence_quotes
— hypotheses
— actions

Правила:
— observations должны опираться только на входные отзывы;
— hypotheses не должны выдавать себя за факты;
— actions формулируй как проверяемые шаги.

Здесь батч отзывов мы вставляем прямо в запрос, но если он очень большой и в формате JSON, то нужно использовать не песочницу, а сторонние приложения и API.

Поддержка сложных кейсов

Если обращение тянется через несколько команд, reasoning-модель помогает сделать разбор инцидента и выделить конфликтующие данные.

Мини-инструкция для типовой задачи — разобрать длинный конфликтный кейс:

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

• В промпте просить модель сначала собрать timeline, потом выделить contradictions, потом предложить next steps.

• Если часть информации неполная, модель должна отдельно перечислять missing_data, а не скрывать пробелы внутри саммари.

• Для чувствительных кейсов полезно отключать лишнюю креативность: температуру устанавливаем ближе к нулю, требуем строгого формата ответа.

Пример технического промпта:

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

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

Инструкция:
1. Построй timeline только из событий, для которых есть явная временная или причинная опора.
2. Выдели contradictions — расхождения между сообщениями клиента, операторов и системными данными.
3. Отдельно перечисли missing_data — какие данные критически нужны для следующего шага, но отсутствуют.
4. Сформулируй probable_root_causes, но только как гипотезы с указанием confidence: low/medium/high.
5. Сформируй next_steps отдельно для support, engineering и account-команды, если это применимо.
6. Если данных недостаточно для вывода, не скрывай пробелы внутри summary, а явно выноси их в missing_data.
7. Не включай рекомендации, которые не опираются на входные материалы.

Формат ответа:
— timeline
— confirmed_facts
— contradictions
— missing_data
— probable_root_causes
— next_steps_by_team
— handoff_note

Группа 3. Модели с длинным контекстом

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

Особенно пригодится там, где грубый чанкинг 100% разрушит смысл, например когда важна связь между приложением к договору, старой перепиской и внутренней политикой.

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

Какие модели входят в группу

В длинноконтекстную группу входят популярные модели:

• deepseek-ai/DeepSeek-V4-Pro — контекст 1 000 000 токенов;

• anthropic/claude-opus-4.6 — контекст 1 000 000 токенов;

• anthropic/claude-sonnet-4.6 — контекст 1 000 000 токенов;

• google/gemini-2.5-pro — контекст 1 048 576 токенов;

• google/gemini-3.1-pro-preview — контекст 1 048 576 токенов;

• openai/gpt-5.4 — контекст 1 050 000 токенов;

• openai/gpt-5.4-pro — контекст 1 050 000 токенов;

• openai/gpt-4.1 — контекст 1 047 576 токенов.

Какие задачи они закрывают

Юридический и финансовый блок

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

Мини-инструкция для типовой задачи — проанализировать пакет документов целиком:

• Размечать вход блоками CONTRACT, APPENDIX, EMAIL_THREAD, INTERNAL_POLICY, чтобы модель видела границы источников.

• В начале запроса просить модель построить карту источников и указать, какие из них критичны для вывода.

• Запросить схему: facts и conflicts, risks и actions.

• Если пакет очень большой, рассмотреть двухшаговый пайплайн — сначала отбор релевантных фрагментов, затем финальный анализ. 

Пример системного промпта:

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

Контекст:
— Во входных данных могут быть договор, приложения, переписка, внутренняя политика и служебные комментарии.
— Источники могут содержать конфликтующие формулировки и устаревшие версии условий.
— Более высокий приоритет имеют договорные условия и явно датированные документы.

Инструкция:
1. Сначала построй index_of_sources: перечисли документы, их роль и относительный приоритет для анализа.
2. Затем выдели obligation_map: обязательства, сроки, ограничения и условия, которые прямо следуют из текста.
3. Отдельно собери contradictions: конфликты между документами, приложениями и перепиской.
4. Отдельно укажи missing_clauses_or_data: что нужно запросить дополнительно, чтобы принять решение без допущений.
5. После этого сформируй risk_assessment, разделяй contractual_risks, operational_risks и interpretation_risks.
6. Заверши ответ блоком recommended_actions, где каждое действие должно быть привязано к конкретному риску или конфликту.
7. Не объединяй выводы из разных источников без указания source_reference.
8. Если источник слабый или противоречит более приоритетному документу, пометь это явно.

Формат ответа:
— index_of_sources
— obligation_map
— contradictions
— missing_clauses_or_data
— risk_assessment
— recommended_actions

Поддержка и сервис

В этой сфере можно работать с историей переписки, инцидентами, заметками операторов и релевантными статьями из базы знаний.

Мини-инструкция для типовой задачи — прочитать долгую историю клиента без потери контекста:

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

• Отдельно маркируйте CURRENT_ISSUE, PAST_INCIDENTS, OPERATOR_NOTES, KB_EXTRACTS.

• Просите сначала собрать timeline, затем unresolved_issues, потом next_action.

• Не смешивайте в одном вызове весь архив клиента, если старая история не влияет на текущий кейс: длинный контекст не должен заменять фильтрацию данных.

Пример системного промпта:

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

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

Инструкция:
1. Сначала собери chronological_timeline только из событий с явной временной опорой.
2. Затем выдели unresolved_issues — вопросы и проблемы, которые остались без решения.
3. Отдельно перечисли customer_commitments — что компания уже пообещала клиенту и было ли это исполнено.
4. Собери internal_gaps — где у команд не хватает данных, согласования или ответственного.
5. Сформируй customer_risk: churn_risk, escalation_risk, trust_risk с кратким основанием по каждому пункту.
6. В next_action раздели шаги по ролям: support, engineering, account.
7. Если часть старой истории нерелевантна текущему инциденту, не включай ее в финальный вывод.
8. Не скрывай противоречия внутри summary — выноси их отдельно.

Формат ответа:
— chronological_timeline
— unresolved_issues
— customer_commitments
— internal_gaps
— customer_risk
— next_action_by_team

{

  "chronological_timeline": [

    {

      "event": "Начало миграции клиента на тариф Enterprise Plus",

      "time": "01.03.2026",

      "source": "Тикет #SUP-4401"

    },

    {

      "event": "Клиент обнаружил отсутствие данных после миграции (настройки интеграций, отчеты за январь — февраль)",

      "time": "15.03.2026",

      "source": "Тикет #SUP-4401"

    },

    {

      "event": "Отдел миграции первоначально сообщил, что данные перенесены корректно",

      "time": "18.03.2026",

      "source": "Комментарий Дмитрия в тикете #SUP-4401"

    },

    {

      "event": "Клиент прислал скриншоты, подтверждающие отсутствие данных",

      "time": "19.03.2026",

      "source": "Ответ клиента Сидорова А."

    },

    {

      "event": "Отдел миграции признал проблему, эскалировал в инженеры",

      "time": "20.03.2026",

      "source": "Внутренний комментарий Дмитрия, создание тикета #ENG-2210"

    },

    {

      "event": "Инженеры восстановили данные из бэкапа",

      "time": "25.03.2026",

      "source": "Комментарий Алексея в тикете #ENG-2210"

    },

    {

      "event": "Клиент подтвердил восстановление данных",

      "time": "27.03.2026",

      "source": "Ответ клиента Сидорова А."

    },

    {

      "event": "Обновление интерфейса, после которого пропали пользовательские фильтры",

      "time": "08.05.2026",

      "source": "Тикет #SUP-4502"

    },

    {

      "event": "Клиент сообщил о пропаже фильтров",

      "time": "10.05.2026",

      "source": "Тикет #SUP-4502"

    },

    {

      "event": "Продукт-менеджер подтвердил проблему, запланировал исправление на 20.05.2026, обещал компенсацию (бесплатный месяц поддержки)",

      "time": "12.05.2026",

      "source": "Комментарий Ирины, письмо Марии клиенту"

    },

    {

      "event": "Клиент выразил недовольство, угрожает пересмотром сотрудничества",

      "time": "13.05.2026",

      "source": "Ответ клиента Петрова В."

    }

  ],

  "unresolved_issues": [

    {

      "issue": "Пользовательские фильтры клиента не восстановлены",

      "status": "Ожидается исправление 20.05.2026",

      "impact": "Клиент тратит часы на ручную фильтрацию",

      "source": "Тикет #SUP-4502"

    }

Аналитика

Модель может прочитать длинный отчет, комментарии к нему, обсуждение результатов и собрать на этой базе единое саммари.

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

• На вход подавать отчет и комментарии как разные блоки, чтобы модель различала первичные данные и интерпретации.

• В ответе разделять facts_from_report, stakeholder_comments, key_risks, open_questions.

• Если задача управленческая и требует решения — добавлять поле decisions_needed, но только если для него есть опора в материалах.

Пример системного промпта:

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

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

Инструкция:
1. Сначала выдели facts_from_report — только подтвержденные данные, выводы и тенденции из основного отчета.
2. Затем собери stakeholder_comments как отдельный слой: кто что интерпретирует или предлагает.
3. Отдельно укажи divergences — где комментарии стейкхолдеров не совпадают с фактами отчета.
4. Сформируй key_risks, разделяя стратегические, операционные и коммуникационные риски.
5. Собери open_questions — что еще нужно уточнить до принятия решения.
6. В decisions_needed включай только те решения, которые логически следуют из материалов.
7. Не объединяй факты и мнения в один пункт.

Формат ответа:
— facts_from_report
— stakeholder_comments
— divergences
— key_risks
— open_questions
— decisions_needed

HR и управление знаниями

Здесь длинный контекст полезен для работы с СУЗ, внутренними политиками и FAQ.

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

• Разделять вход по документам и версиям, особенно если в компании есть старые и новые редакции политик.

• Просить модель в каждом ответе указывать, из какого документа взят вывод.

• В спорных случаях модель должна возвращать policy_conflict=true, а не скрывать противоречие.

Пример системного промпта:

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

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

Инструкция:
1. Для начала определи, какие документы действительно релевантны вопросу.
2. По каждому релевантному документу выдели source_document и source_section.
3. Сформируй answer отдельно по каждому источнику, если между ними есть расхождения.
4. Если нормы противоречат друг другу, пометь policy_conflict=true и явно опиши conflict_reason.
5. Если по материалам нельзя дать уверенный ответ, верни insufficient_policy_basis=true.
6. Не синтезируй единую норму из нескольких противоречащих документов без явного основания.

Формат ответа:
— relevant_documents
— source_document
— source_section
— answer
— policy_conflict
— conflict_reason
— insufficient_policy_basis

Группа 4. Агентные модели и function calling

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

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

Здесь особенно важен ограниченный набор функций, белый список действий, guardrails на входе и выходе, а также human-in-the-loop для критичных сценариев. Без этих слоев агент может сильно подставить бизнес.

Какие модели входят в группу

Для agentic-сценариев рассматриваем:

• Qwen/Qwen3.6-35B-A3B — Function Calling + Structured Output + Reasoning;

• zai-org/GLM-4.7 — Function Calling + Structured Output + Reasoning;

• openai/gpt-oss-120b — Function Calling + Structured Output + Reasoning;

• MiniMaxAI/MiniMax-M2.5 — Function Calling + Structured Output + Reasoning;

• openai/gpt-5 — Function Calling + Structured Output + Reasoning + Vision, контекст 400 000 токенов;

• google/gemini-2.5-pro — Function Calling + Structured Output + Reasoning + Vision, контекст 1 048 576 токенов;

• anthropic/claude-sonnet-4.6 — Function Calling + Structured Output + Reasoning + Vision, контекст 1 000 000 токенов.

Какие задачи они закрывают

Поддержка

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

Мини-инструкция для типовой задачи — построить support-flow с поиском по базе знаний:

• Разделить функции минимум на два слоя: search_kb и create_ticket, — чтобы не смешивать поиск и запись в систему в одном вызове.

• Явно задать правило: без релевантного результата поиска модель не формирует уверенный ответ пользователю.

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

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

Пример схемы функций:

[
  {
    "name": "search_kb",
    "description": "Search internal knowledge base",
    "parameters": {
      "type": "object",
      "properties": {
        "query": {"type": "string"}
      },
      "required": ["query"]
    }
  },
  {
    "name": "create_ticket",
    "description": "Create support ticket",
    "parameters": {
      "type": "object",
      "properties": {
        "category": {"type": "string"},
        "summary": {"type": "string"}
      },
      "required": ["category", "summary"]
    }
  }
]

Схема:

HR и внутренние сервисы

Модель может принимать вопрос сотрудника, искать по внутренним политикам и передавать этот кейс в нужную функцию.

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

• Нужны как минимум функции search_policy, route_to_team, а иногда и create_hr_request.

• Модель должна сначала пробовать найти ответ в базе, а не эскалировать вопрос к человеку автоматически.

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

• Если вопрос относится к исключениям или спорным кейсам, агент должен сразу вызывать человека, а не продолжать автогенерацию.

Пример промпта:

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

Инструкция:
1. Сначала вызывай поиск по политикам и ищи релевантные документы.
2. Если найденные документы дают прямой ответ, сформируй краткий ответ и укажи source_document и source_section.
3. Если вопрос требует исключения, согласования или связан с конфликтом политик, не отвечай самостоятельно — вызывай route_to_team.
4. Если найденные документы частично релевантны, но не покрывают вопрос полностью, пометь partial_coverage и передай кейс человеку.
5. Не подменяй отсутствие ответа вероятностной догадкой.
6. В каждом ответе указывай, на каком основании был выбран следующий шаг: answer_directly или route_to_team.

Пошагово

Сотрудник пишет: «Мне нужно взять отпуск на 45 дней подряд: я хочу совместить основной отпуск с декретным переходом, плюс у меня есть накопленные дни за прошлый год. Это, вообще, возможно?»

Шаг 1. Модель вызывает search_policy

{

  "tool_calls": [{

    "id": "call_201",

    "type": "function",

    "function": {

      "name": "search_policy",

      "arguments": "{"query": "отпуск 45 дней подряд совмещение с декретом перенос накопленных дней", "policy_area": "hr"}"

    }

  }]

}

Шаг 2. KB возвращает результат с пометкой «исключение»

{

  "tool_call_id": "call_201",

  "content": "{"results": [{"doc_id": "HR-POL-003", "section": "§5.2", "snippet": "Непрерывный отпуск свыше 28 дней допускается только по согласованию с HR-директором и при наличии производственной возможности.", "relevance": 0.78}, {"doc_id": "HR-POL-011", "section": "§1.4", "snippet": "Перенос неиспользованных дней отпуска на следующий год — не более 14 дней. Остаток свыше 14 дней сгорает или компенсируется по заявлению.", "relevance": 0.71}], "confidence": 0.62, "status": "exception_required", "note": "Запрос выходит за рамки стандартной политики — требуется согласование HR-директора."}"

}

Шаг 3. Модель НЕ отвечает сама, а вызывает route_to_team

{

  "tool_calls": [{

    "id": "call_202",

    "type": "function",

    "function": {

      "name": "route_to_team",

      "arguments": "{"team": "hr_business_partner", "reason": "Запрос сотрудника выходит за рамки стандартной политики отпусков: (1) непрерывный отпуск 45 дней превышает лимит 28 дней из §5.2 HR-POL-003 и требует согласования с HR-директором; (2) совмещение с декретным переходом — отдельный кейс, не описанный в политике; (3) накопленные дни за прошлый год — нужно проверить, не превышен ли лимит переноса 14 дней (§1.4 HR-POL-011). Требуется индивидуальное согласование.", "case_summary": "Сотрудник хочет взять 45 дней непрерывного отпуска с учетом декретного перехода и накопленных дней за прошлый год. Требуется исключение из политики.", "partial_coverage": true}"

    }

  }]

}



Шаг 3. Модель отвечает сотруднику с handoff

{

  "role": "assistant",

  "content": "Здравствуйте!nnВаш вопрос выходит за рамки стандартной политики отпусков — такие кейсы требуют индивидуального согласования. Вот что я нашел в политиках:nn📄 HR-POL-003 §5.2: непрерывный отпуск свыше 28 дней допускается только по согласованию с HR-директором.n📄 HR-POL-011 §1.4: перенос неиспользованных дней — не более 14 дней за год, остальное сгорает или компенсируется.nnПоскольку ваш запрос сочетает несколько нестандартных условий (45 дней подряд + декретный переход + накопленные дни), я не могу дать окончательный ответ автоматически.nn✅ Я передал ваш кейс HR-бизнес-партнеру (тикет #HR-4421). Специалист свяжется с вами в течение 1 рабочего дня и предложит варианты оформления.nn---n🎯 Действие: route_to_team → hr_business_partnern📌 Причина: exception_required — запрос выходит за рамки стандартной политики",

  "metadata": {

    "decision": "route_to_team",

    "confidence": 0.62,

    "source_document": ["HR-POL-003", "HR-POL-011"],

    "source_section": ["§5.2", "§1.4"],

    "coverage": "partial",

    "exception": true,

    "ticket_id": "HR-4421"

  }

}

Где:

• search_policy — базовая функция поиска по корпусу политик и регламентов;

• get_policy_fragment — функция для точной цитаты: ассистент не просто пересказывает, а подтягивает нужный пункт;

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

Operations

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

Мини-инструкция для типовой задачи — разобрать письмо и создать задачу:

• Определить белый список функций: extract_entities, create_task, notify_owner.

• Не давать модели права автоматически отправлять уведомления без промежуточной проверки, если задача критичная.

• На первом шаге модель должна классифицировать письмо и извлечь сущности, а уже потом инициировать создание карточки.

• Для повышения надежности полезно разделять функции на read-only и write-actions.

Пример маршрута:

1. Модель получает письмо.

2. Вызывает extract_entities.

3. Если сущности извлечены уверенно, вызывает create_task.

4. Если confidence низкий, передает письмо оператору.

И последний практический совет: свой мини-бенчмарк обычно дает больше пользы, чем спор о том, какая модель лучше на чужих бенчмарках. Вы можете прогнать данные в нашей песочнице или интегрировать модели из Evolution Foundation Models сразу в любое привычное приложение.