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

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

Привет, Хабр! Я Игорь Зуриев, руководитель проектов по автоматизации бизнеса и внедрению систем на базе ИИ. Больше десяти лет управляю ИТ-проектами, в том числе для заказчиков из нефтегазовой отрасли и строительства — «Лукойла», аэропорта Шереметьево, «Трансгаза». Автор и преподаватель программ по ИТ-проектам и цифровым продуктам, в том числе в Университете Иннополис. В школе Karpov.Courses преподаю применение ИИ для анализа данных. Веду в ТГ канал «Нейросетка». 

Сам использую ИИ для работы с кодом, документами и прототипами. Fable 5.1 понравилась мне тем, что код получался практически без ошибок с первого раза. В Stitch я описывал изменения интерфейса словами и сравнивал варианты экранов. А один из запусков Sonnet 5 закончился исчерпанием лимита без готового результата. Поэтому меня интересует и качество ответа, и то, сколько работы после него остаётся человеку.

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

Что считать полезным результатом

Когда я исследовал возможности GPT-5.5, меня заинтересовал сдвиг к меньшему микроменеджменту. Хочется передать системе задачу вместе с исходными материалами и получить результат, который можно проверить, без необходимости руководить каждым шагом.

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

Поэтому при выборе я смотрю на три вещи:

• что получилось на выходе;

• сколько пришлось вмешиваться

• и насколько легко проверить результат.

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

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

Исправление кода и подготовка документов

Fable 5 мне нравилась в разработке, а первые два дня с Fable 5.1 усилили это впечатление: код получался практически без ошибок с первого раза. Документы и презентации тоже понравились. Это первые наблюдения, без подсчёта доли успешных решений и времени доработки.

Поэтому Claude — первый инструмент, который мне хочется открыть для кода или содержательного документа. Сравнительного прогона Fable и Gamma я не проводил; для выбора под конкретный проект предлагаю проверку с воспроизводимым результатом.

Как проверить исправление ошибки

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

Пример задания для такого прогона:

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

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

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

Как оценить доплату за модель

Базовые ставки Fable 5.1 составляют $10 за миллион входных и $50 за миллион выходных токенов. У Opus 5 — $5 и $25, у Sonnet 5 — $2 и $10. Это цены API, а не стоимость подписки Claude. Тарифы Anthropic.

Ниже — условный расчёт для 100 тысяч некэшированных входных и 10 тысяч оплачиваемых выходных токенов. Он изолирует разницу ставок: одинаковый текст разные модели могут токенизировать и обрабатывать по-разному. Расчёт не включает инструменты, дополнительные попытки и проверку человеком.

То есть при таких допущениях Fable стоит вдвое дороже Opus и впятеро дороже Sonnet. Переплата имеет смысл, если она даёт полезный результат или экономит достаточно времени на исправлениях.

Есть существенная деталь обновления Fable. Базовые цены у версий 5 и 5.1 одинаковы, но чтение кэша подешевело с $1 до $0,25 за миллион токенов. Поэтому заявленная Anthropic экономия особенно интересна для длинных агентных сценариев с повторным использованием контекста. Обещание «до 45% дешевле» нельзя переносить на каждый одиночный запрос.

Моя отправная точка для сложной доработки или важного документа — Fable. Для повторяемой операции имеет смысл сопоставить её с Opus или Sonnet: уменьшает ли более дорогая модель объём ручных исправлений настолько, чтобы оправдать расходы?

Что показал запуск без результата

Мой опыт с Sonnet 5 оказался менее удачным: в одном из запусков лимит закончился раньше, чем появился результат. По одному случаю нельзя отделить влияние тарифа, режима и самой задачи. Но пользовательский итог определённый — готового результата за эту попытку не было.

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

Анализ таблиц с несколькими источниками

Для этой задачи предлагаю сравнить GPT-5.6 Sol и GPT-6 Astra. Впечатление от GPT-5.5 о меньшей потребности в микроменеджменте подсказывает критерий проверки — сколько вмешательств потребуется до готового отчёта. Но оно не заменяет отдельного прогона новых версий.

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

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

Пример запроса для проверки:

Сопоставь orders.csv и refunds.csv по order_id. Сначала проверь уникальность ключей, пропуски, валюты и даты. Рассчитай выручку по правилам из revenue_rules.md. Если правила не определяют обработку отдельного случая, задай вопрос до итогового расчёта. Сохрани Python-скрипт, таблицу с результатами и список исключений. В отчёте отдели наблюдаемые изменения от предположений об их причинах.

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

Когда имеет смысл доплатить за Astra

У Sol и Astra заявлено одинаковое контекстное окно — 1,05 млн токенов. Базовые ставки Astra — $10/$50 за миллион входных/выходных токенов, у Sol — $4/$20. Тариф Sol промоционный, гарантирован как минимум до 21 ноября 2026 года. Карточка Sol, карточка Astra.

На условных 100 тысячах входных и 10 тысячах оплачиваемых выходных токенов получается $0,60 для Sol и $1,50 для Astra. Это расчёт по базовым ставкам без кэша, инструментов и повторов. Для запросов свыше 272 тысяч входных токенов у обеих моделей действуют повышенные ставки; в нашем примере этот порог не достигнут. Условия Sol, условия Astra.

Для первого прогона предлагаю Sol, затем — Astra на тех же данных и с теми же инструментами. Особенно показательны противоречащие документы, многочисленные исключения и цепочки из поиска, расчётов и подготовки результата. Основанием доплатить станет сокращение ошибок или времени проверки.

Прототипирование интерфейса

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

Это помогает быстро показать идею и пройти пользовательский сценарий. Здесь я оцениваю приложение целиком: опыт работы со Stitch не доказывает качество конкретной версии Gemini.

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

Пример запроса: 

«Создай два варианта экрана фильтрации заказов по периоду, статусу и сумме. Свяжи экран фильтров со списком результатов. Покажи выбранные фильтры, возможность их сбросить и состояние без результатов. Используй демонстрационные данные».

Разбор интервью и мультимодальных материалов

Для совместной обработки записи интервью, скриншотов и документа с требованиями предлагаю проверить Gemini 3.6 Flash. По документации модель принимает текст, изображения, аудио, видео и PDF, поддерживает структурированный вывод и вызовы функций. Это основание включить её в сравнение; результат на ваших материалах ещё предстоит оценить. Документация Gemini 3.6 Flash.

Задание для такого сравнения:

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

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

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

Мониторинг обсуждений продукта

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

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

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

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

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

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

Стоимость мониторинга стоит считать вместе с получением данных: у X Search есть собственная тарификация. Условия оплаты поиска. Практичная единица сравнения — обработка одного периода мониторинга, включая проверку источников.

Извлечение данных из скриншотов

Моё наблюдение о прежней DeepSeek-V4-Flash-Vision-Exp касалось расхода токенов: примерно 384 токена на изображение. Это не оценка точности распознавания и не гарантия стоимости для текущей версии. Расход для нового запуска стоит проверять по фактическому использованию.

Причина вполне конкретная: в текущей документации Vision старый идентификатор уже обозначен как устаревший. Запросы с ним обслуживает новая Flash; в примерах используется deepseek-flash. Поэтому одинаковое имя в старом скрипте ещё не означает прежнюю модель под капотом. Документация DeepSeek Vision.

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

Пример задания:

Извлеки со скриншота значения в формате JSON: metric, value, unit, period. Переноси только явно читаемые данные. Если значение неразборчиво, используй null и поясни причину в отдельном поле. Не вычисляй отсутствующие показатели по внешнему виду графика.

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

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

Ответы по внутренним документам в своём контуре

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

Для проверки в собственном контуре предлагаю Qwen и GigaChat, выбрав конкретный релиз под оборудование. Карточка Qwen3-8B описывает режимы с рассуждением и без него и варианты запуска. Это документированный вариант для начального эксперимента. У ai-sage опубликованы и более крупные модели, включая GigaChat 3.5 Reasoning. Репозитории ai-sage.

Подходящая задача — ответы на вопросы по внутренним регламентам. Критерии: точные названия, ссылки на пункты и явное указание, когда правило в документах отсутствует.

Для начала рекомендую передать моделям одинаковые готовые фрагменты регламентов. Так проще отделить ошибку генерации от ошибки поиска. Следующий этап — подключить поиск документов и оценить систему целиком.

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

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

Шпаргалка по задачам и инструментам

Эта таблица поможет составить список для первого прогона. В ней личные наблюдения отделены от предложений по проверке. Названия моделей со временем придётся обновить; критерии в последнем столбце можно перенести на новые версии.

Как сравнить результаты запусков

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

Отдельно полезно записывать вмешательства: пришлось подсказать путь к файлу, повторить требование, исправить расчёт, попросить запустить тест. Так «мне показалось удобнее» постепенно превращается в наблюдение, которое можно проверить.

Ниже — заготовка для задачи с CSV из раздела об анализе таблиц. Достаточно добавить по столбцу на каждую модель и заполнить их результатами запусков.

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

Сохранённые задания пригодятся после обновления модели. При повторном прогоне важно оставить прежние данные и критерии приёмки, а изменения инструментов и настроек записать отдельно.

Заключение

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

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

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

Новая LLM лидирует в тестах, но поможет ли она с вашим кодом и таблицами?
Привет, Хабр! Я Игорь Зуриев, больше десяти лет управляю ИТ-проектами по автоматизации бизнеса и занимаюсь внедрением систем на базе ИИ, преподаю в онлайн-школе Karpov.Courses. Покажу, какие модели имеет смысл сравнить на рабочих задачах, какие запросы им дать и как оценить результат. Поделюсь личными наблюдениями, а в конце — шпаргалками для выбора инструментов и сравнения запусков.