Почти все сегодня знают про 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": [] }
Оригинал JSON'a
{ "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
Оригинал json:
{ "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"] } } ]
Пример вызовов функций:
Шаг 1. Агент решает вызвать search_kb
{
"role": "assistant",
"content": null,
"tool_calls": [
{
"id": "call_001",
"type": "function",
"function": {
"name": "search_kb",
"arguments": "{\"query\": \"ошибка 403 при подключении к API причины и решение\"}"
}
}
]
}
Шаг 2. Система возвращает результат поиска с confidence
{
"role": "tool",
"tool_call_id": "call_001",
"content": "{\"results\": [{\"article_id\": \"KB-1142\", \"title\": \"Ошибка 403 при работе с API: причины\", \"snippet\": \"Ошибка 403 возникает при невалидном токене, истекшем API-ключе или отсутствии прав scope=read у токена.\", \"relevance\": 0.91}], \"confidence\": 0.87, \"kb_status\": \"hit\"}"
}
Шаг 3. Агент формирует черновик ответа (confidence ≥ порога 0.7 → автоответ)
{
"role": "assistant",
"content": "Здравствуйте! Ошибка 403 при подключении к API обычно связана с одной из трех причин:\n1. Невалидный или истекший API-ключ.\n2. Отсутствие необходимого scope (например, scope=read) у токена.\n3. Ограничения по IP в настройках проекта.\n\nПожалуйста, проверьте:\n— срок действия ключа в личном кабинете → Настройки → API;\n— наличие нужных scope у токена;\n— белый ли ваш IP в списке разрешенных.\n\nИсточник: KB-1142. Если проблема сохраняется — напишите, и я передам кейс инженеру L2.",
"metadata": {
"confidence": 0.87,
"kb_article": "KB-1142",
"routing": "auto_answer",
"handoff_required": false
}
}
Схема:
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": "Здравствуйте!\n\nВаш вопрос выходит за рамки стандартной политики отпусков — такие кейсы требуют индивидуального согласования. Вот что я нашел в политиках:\n\n? HR-POL-003 §5.2: непрерывный отпуск свыше 28 дней допускается только по согласованию с HR-директором.\n? HR-POL-011 §1.4: перенос неиспользованных дней — не более 14 дней за год, остальное сгорает или компенсируется.\n\nПоскольку ваш запрос сочетает несколько нестандартных условий (45 дней подряд + декретный переход + накопленные дни), я не могу дать окончательный ответ автоматически.\n\n✅ Я передал ваш кейс HR-бизнес-партнеру (тикет #HR-4421). Специалист свяжется с вами в течение 1 рабочего дня и предложит варианты оформления.\n\n---\n? Действие: route_to_team → hr_business_partner\n? Причина: 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" } }
Как могут выглядеть функции из промпта:
[
{
"name": "search_policy",
"description": "Найти релевантные политики и регламенты по тексту вопроса",
"parameters": {
"type": "object",
"properties": {
"query": {
"type": "string",
"description": "Текст вопроса сотрудника или ключевые слова"
},
"limit": {
"type": "integer",
"description": "Максимальное число документов в ответе",
"default": 5
}
},
"required": ["query"]
}
},
{
"name": "get_policy_fragment",
"description": "Получить конкретный фрагмент политики по идентификатору документа и раздела",
"parameters": {
"type": "object",
"properties": {
"document_id": {
"type": "string",
"description": "Идентификатор внутреннего документа политики"
},
"section_id": {
"type": "string",
"description": "Идентификатор раздела или пункта"
}
},
"required": ["document_id", "section_id"]
}
},
{
"name": "route_to_team",
"description": "Передать вопрос на рассмотрение ответственной команде",
"parameters": {
"type": "object",
"properties": {
"team": {
"type": "string",
"description": "Команда, которая должна обработать запрос (например, HR, Legal, Compliance)"
},
"question": {
"type": "string",
"description": "Сформулированный текст вопроса или кейса для эскалации"
},
"context_documents": {
"type": "array",
"items": {
"type": "string"
},
"description": "Список идентификаторов документов, на которые стоит сослаться"
},
"partial_coverage": {
"type": "boolean",
"description": "Флаг, указывающий, что базовых политик недостаточно для точного ответа"
}
},
"required": ["team", "question"]
}
}
]
Где:
search_policy — базовая функция поиска по корпусу политик и регламентов;
get_policy_fragment — функция для точной цитаты: ассистент не просто пересказывает, а подтягивает нужный пункт;
route_to_team — функция для эскалации: когда вопрос выходит за рамки автоматического ответа, ассистент оформляет кейс для нужной команды.
Operations
Агентный сценарий полезен для разбора входящих писем и создания карточек задач.
Мини-инструкция для типовой задачи — разобрать письмо и создать задачу:
Определить белый список функций: extract_entities, create_task, notify_owner.
Не давать модели права автоматически отправлять уведомления без промежуточной проверки, если задача критичная.
На первом шаге модель должна классифицировать письмо и извлечь сущности, а уже потом инициировать создание карточки.
Для повышения надежности полезно разделять функции на read-only и write-actions.
Пример маршрута:
Модель получает письмо.
Вызывает extract_entities.
Если сущности извлечены уверенно, вызывает create_task.
Если confidence низкий, передает письмо оператору.
И последний практический совет: свой мини-бенчмарк обычно дает больше пользы, чем спор о том, какая модель лучше на чужих бенчмарках. Вы можете прогнать данные в нашей песочнице или интегрировать модели из Evolution Foundation Models сразу в любое привычное приложение.