Как выбрать LLM для рабочих задач: методика проверки качества и стоимости

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

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

Начните с задач, а не с названий моделей

Сначала составьте список сценариев, для которых нужна LLM. Обычно они делятся на несколько групп:

• генерация и исправление кода;
• анализ документов и подготовка выводов;
• работа с таблицами и расчётами;
• подготовка черновиков, писем и технических заданий;
• извлечение структурированных данных;
• создание прототипов и интерфейсных решений.

Для каждого сценария зафиксируйте исходные материалы, ожидаемый результат и допустимый объём ручной доработки. Формулировка «модель должна хорошо анализировать документы» слишком расплывчата. Гораздо полезнее: «модель должна найти все операции возврата в трёх файлах, применить правила из инструкции и сформировать итоговую таблицу с указанием источника каждой суммы».

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

Соберите небольшой, но показательный тестовый набор

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

1. обычная задача с очевидным решением;
2. пример с неполными или неоднозначными данными;
3. документ с противоречивыми правилами;
4. запрос, где нужная информация находится в нескольких файлах;
5. пример с редкими исключениями;
6. задача, требующая строго заданного формата ответа.

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

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

Определите критерии приёмки

Перед запуском тестов составьте таблицу оценки. Для каждой задачи можно использовать шкалу от 0 до 2:

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

Отдельно оценивайте разные свойства:

Корректность

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

Полнота

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

Формат

Соблюдён ли требуемый JSON, список, таблица или шаблон письма? Форматная ошибка может сделать хороший по смыслу ответ непригодным для автоматической обработки.

Проверяемость

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

Объём ручной работы

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

Сравнивайте стоимость полного сценария

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

В Протоке на дату публикации доступны, в частности, такие котировки за 1 млн токенов:

• GPT-6 Sol — 13,60 ₽ за вход и 67,98 ₽ за выход;
• GLM-5.2 — 3,66 ₽ за вход и 11,50 ₽ за выход.

Например, запрос с 20 000 входных токенов и ответом на 3 000 токенов для GPT-6 Sol будет стоить около 0,48 ₽: 20 000 × 13,60 / 1 000 000 плюс 3 000 × 67,98 / 1 000 000. Для GLM-5.2 аналогичный запуск составит около 0,11 ₽. Это ориентир для одного вызова без учёта возможных повторов и дополнительной обработки.

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

Проведите тест в одинаковых условиях

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

• системную инструкцию;
• параметры генерации;
• состав и порядок входных данных;
• ограничение на объём ответа;
• формат результата;
• время запуска и стоимость каждого теста.

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

Для подключения достаточно использовать совместимый API-адрес Протока: https://dualchat.pro/v1. Ключ вида sk-dc-… создаётся в кабинете в разделе «Ключи». В коде параметр model указывается как slug модели из котировок. Например, запрос к GPT-6 Sol выглядит так:

from openai import OpenAI

client = OpenAI(
    api_key="sk-dc-ваш-ключ",
    base_url="https://dualchat.pro/v1"
)

response = client.chat.completions.create(
    model="gpt-6-sol",
    messages=[
        {"role": "user", "content": "Проверь расчёт и перечисли найденные ошибки."}
    ]
)

print(response.choices[0].message.content)

Тот же тест можно запустить на GLM-5.2, заменив значение model на glm-5.2. Это позволяет сравнивать модели в одном клиенте и с одинаковой логикой интеграции.

Разделяйте модели по ролям

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

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

Например, GLM-5.2 на дату публикации может быть экономичным вариантом для предварительной обработки больших объёмов, а GPT-6 Sol — одним из вариантов для задач, где важны сложные рассуждения и качество итогового ответа. Но окончательное решение следует принимать по собственному тестовому набору, а не только по цене или названию модели.

Что проверить перед запуском в работу

Перед внедрением ответьте на пять вопросов:

1. Какова доля результатов, прошедших приёмку с первого раза?
2. Какие ошибки повторяются чаще всего?
3. Сколько минут занимает проверка одного ответа?
4. Какова стоимость одного принятого результата, а не одного запроса?
5. Есть ли понятный способ остановить автоматизацию при низкой уверенности?

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

Вывод

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

В Протоке можно подключить модели через https://dualchat.pro/v1, сравнить их на едином наборе запросов и оплачивать использование по факту в рублях. Посмотрите актуальные котировки и попробуйте провести собственный тест на сайте: https://dualchat.pro?utm_source=blog&utm_medium=article&utm_campaign=kak-vybrat-llm-dlya-rabochih-zadach