Цель этой статьи — дать простой фреймворк для выбора моделей под типичные задачи, с которыми сталкиваются технические писатели. Статья актуальна для апреля 2026 года для российского рынка.
Эта статья — только о языковых моделях. Я не говорю здесь об инструментах или фреймворках. Фокус исключительно на том, какие модели выбрать под разные классы задач.
Ниже приведена схема, которая показывает три основных класса задач, которые я выделяю, и знакомые мне модели для решения таких задач:
%%{init: {'flowchart': {'rankSpacing': 120, 'nodeSpacing': 60}}}%%
flowchart TD
Task{Категория задачи} --> V[Вспомогательные]
Task --> N[Контент,
низкая неопределённость]
Task --> H[Контент,
высокая неопределённость]
V --> V_Loc[Локально:
Qwen 3.6 4B/14B, Mistral 3/4]
V --> V_API[API:
Alice AI LLM, GLM 4.7 Flash]
N --> N_Loc[Локально/Свой контур:
Qwen 3.6 35B, Hermes 4 70B,
GPT-OSS 120B]
N --> N_API[Китайские модели в API:
GLM 5.1, DeepSeek 4, Kimi k2.6]
H --> H_Loc[Локально/Свой контур:
GLM 4.7, Kimi k2.6,
Minimax 2.5, DeepSeek 3.2]
H --> H_API[Фронтирные модели в API:
Claude Opus/Sonnet, GPT-5]Главная развилка: можно ли отправлять данные наружу
Первый и самый важный вопрос при выборе модели — не «какая модель лучше», а «могут ли данные покидать контур компании».
Модели у внешних поставщиков и дешевле, и мощнее того, что вы сможете развернуть у себя. За $20–100 в месяц вы получаете доступ к вычислительным мощностям, которые в локальном развёртывании потребовали бы минимум на порядок больших затрат, а получить необходимое оборудование для фронтирных моделей может быть практически невозможно. В общем и целом, практически нет смысла разворачивать что-то у себя, если можно довериться внешнему поставщику.
Если данные подпадают под локальные регуляторные требования или внутренние политики безопасности, выбор сужается до развёртывания в собственном контуре или работе с российскими провайдерами при условии заключения соответствующего договора.
Если данные можно отправлять наружу — начинайте с фронтирных моделей через API. Оцените выгоду на реальных задачах, а затем ищите более дешёвые альтернативы для оптимизации стоимости. Выбирайте наиболее удобный для вас способ работы по API — часто имеет смысл использовать прокси наподобие OpenRouter для унификации интерфейсов и способов оплаты.
Если данные должны оставаться внутри — готовьтесь к компромиссам. Локальные модели проигрывают по качеству, скорости развития и удобству, но дают полный контроль над данными.
Две основные категории задач
Я выделяю две основные категории задач:
- Задачи по созданию контента. Это самая требовательная по ресурсам категория. Грубо говоря, стабильно создавать качественные черновики, не говоря уже о материалах, которые сразу могут быть опубликованы на проде, способны не так много моделей. Это фронтирные модели второй половины 2025 года и китайские модели 2026 года.
- Вспомогательные задачи. Сюда входит всё то, что помогает создавать документацию и управлять знаниями, не создавая новые единицы информации.
Внутри этих категорий есть градация по степени неопределённости условий, в которых должна работать модель. Чем выше степень неопределённости и масштабнее задачи, тем сильнее растут требования к модели.
Вспомогательные задачи
Это всё, что помогает поддерживать базу знаний в рабочем состоянии, но не порождает новый материал для читателя напрямую: ревью с проверкой фактов, стилистики и орфографии, поиск информации, расшифровка созвонов, суммаризация разрозненной информации, построение графов знаний, мониторинг актуальности документации и так далее.
Для этих задач важны надёжность, скорость и предсказуемость. Модель должна уметь следовать инструкциям, формировать структурированный вывод и не уходить в творческую импровизацию. Степень неопределённости здесь обычно низкая: входные данные понятны, формат заранее определён.
Самые объёмные вспомогательные задачи также стабильно решаются либо лучшими моделями, либо очень качественной инфраструктурой. Например, Deep Research по всей огромной базе внутренних документов и кода Яндекса работает с помощью дообученной Alice AI LLM и тщательно обработанных для этой цели данных. Подробнее можно почитать в статье от разработчика на Хабре.
Для умного поиска генеративная языковая модель не нужна — используйте эмбеддер (multilingual-e5-large или bge-m3) и гибридный поиск, например на основе Qdrant.
Создание контента
Здесь модель генерирует материалы непосредственно для основной аудитории. Внутри этой категории есть градация по неопределённости.
Работа в условиях низкой неопределённости — задачи с чёткими входными данными и заранее определённым форматом: история изменений из Git, переводы, справочник API на основе спецификации, например OpenAPI. Здесь нужна точность и низкая латентность, а не топовый интеллект.
Работа в условиях высокой неопределённости — задачи, где нет заранее известного результата, а качество зависит от синтеза разрозненных данных. В число возможных документов входят архитектурная документация, концептуальные статьи, объёмные руководства.
Требования к мощности
Требования к мощности модели определяются самой сложной частью пайплайна. В большинстве случаев стоит выбрать самую мощную модель из доступных, и вам не придётся переключаться между инструментами. Не поддавайтесь желанию сразу начать экономить, потому что экономическая эффективность определяется не только стоимостью миллиона токенов, но и временем людей, которые будут работать с моделью. Чем лучше модель, тем быстрее опытный сотрудник сможет добиться от неё качественного результата.
Например, задача вида «научиться генерировать документацию из записей созвонов» может декомпозироваться следующим образом:
Трансформировать речь в текст с разбивкой по спикерам. Это самая простая задача, которую могут решить модели наподобие Whisper или десятки других качественных speech-to-text моделей, доступных как локально, так и через API.
Суммаризовать получившийся текст и выделить основные мысли. Эта задача уже сложнее, если требовать стабильного результата. Я бы оценил необходимое количество параметров как 15–35 миллиардов.
Обработать получившийся промежуточный документ и определить, в какие места в документации нужно внести изменения. Нужна достаточно сильная модель, желательно имеющая доступ к гибридному поиску по существующей документации. Минимальные требования к моделям зависят от объёма документации, но они должны быть не ниже, чем на предыдущем этапе, а скорее выше.
Сформировать изменения, адаптировать их под правила, шаблоны и требования к документации. Чем сложнее целевые документы, тем больше требований к моделям. Я бы сказал, что для стабильной работы нет смысла рассматривать модели, у которых менее 70 миллиардов параметров. Лучше всего использовать хотя бы GPT-OSS 120B при развёртывании в собственном контуре, а при работе через API я бы рекомендовал модели наподобие GLM 4.6, DeepSeek 3.2 и схожего класса.
Соответственно, чтобы выстроить весь пайплайн, нужно иметь модель, удовлетворяющую требованиям последнего пункта. Если такая модель есть в наличии, то стоит использовать её на всех стадиях. С высокой долей вероятности потенциальная экономия от использования более слабых моделей будет нивелирована из-за ошибок, галлюцинаций и более длительных проверок. Единственная стадия, на которой имеет смысл задействовать другую модель — преобразование речи в текст, риск появления ошибок невелик, а расшифровывать можно большие объёмы данных.
Рассказы про полную автоматизацию всех процессов и замену людей — это рассказы про практически неограниченный доступ к лучшим моделям в своих категориях. В реальных условиях автоматизация часто приходит поэтапно: Сначала вспомогательные задачи с низкой неопределённостью, потом — создание контента в условиях чётких входных данных, и только в самом конце — сложный синтез из разрозненных источников.
Фронтирные модели и китайские альтернативы
Фронтирные модели, например Claude Opus 4.7 от Anthropic и GPT-5.5 от OpenAI, опережают лучшие китайские модели минимум на поколение. Лучшие китайские модели — GLM 5.1, Kimi k2.6, DeepSeek 4, Minimax 2.5 — доступны через OpenRouter или напрямую и дают значительную часть качества фронтирных моделей за существенно меньшие деньги. Для русскоязычных задач Qwen и GLM показывают лучшие результаты среди моделей с открытыми весами благодаря хорошей поддержке русского языка в токенизаторе. Я также много работаю с русскоязычными текстами с помощью моделей Kimi, но мне не встречались исследования, подтверждающие мои положительные впечатления.
На что обращать внимание при выборе
- Активные параметры × контекстное окно — главное сочетание для моделей с архитектурой Mixture of Experts, а не общее число параметров.
- Эффективное контекстное окно — 128K от производителя может означать 32K–64K до деградации. Проверить можно на релевантных бенчмарках и своих собственных тестах. Проверяется по методу Needle In A Haystack, типичный бенчмарк — LongBench.
- Квантование — выбирайте и тестируйте конкретную комбинацию общих и активных параметров и квантизации. Актуально для локального развёртывания.
- Токенизатор — Qwen 3.6 (~4 символа/токен) позволяет уместить в одинаковое количество токенов примерно на 30% больше текста, чем токенизатор Llama 3 (~2.5 символа/токен). В общем случае, 100 токенов в английском языке — это примерно 75 слов. В русском языке для западных моделей это соотношение может быть ближе к 30–50 словам на 100 токенов.
Оценивайте модель комплексно, а не по одному бенчмарку. Синтетические тесты вроде MMLU полезны только для оценки базовых возможностей моделей. Для русскоязычных задач можно посмотреть на Russian SuperGLUE — но помните, что бенчмарки измеряют общие способности в достаточно стерильных условиях, а не качество на ваших конкретных задачах. Агентские бенчмарки (SWE-bench, TAU-bench) ближе к реальности, но их важно сочетать с собственным набором тестов из 5–10 реальных задач. Лично я проверяю редактуру намеренно испорченного текста по заданному шаблону, создание кода для простого сервиса, пересказ статьи и некоторые опциональные варианты.
Старайтесь выбирать мультимодальные модели.
Техническая документация — это не только текст, но и скриншоты, диаграммы и скринкасты. А ещё мультимодальная модель позволяет получить информацию из предоставленных изображений и отразить её в тексте.
Если нет возможности выбрать мультимодальную модель, используйте оркестрацию с отправкой изображений в одну модель и обработкой полученных данных в другой.