Исследование · AI-модели
Сравнение текстовых AI-моделей: что показали тесты Антимы
Четыре модели создавали рабочий чек-лист, модели Яндекса и Сбера искали документы, а GigaChat проходила текстовые тесты речевой аналитики. Методика, девять таблиц, ошибки и выводы для AI-проектов.
Для каких проектов Антима сравнивала текстовые модели
В проектах Антимы AI решает разные задачи: превращает материал пользователя в рабочую форму, помогает ориентироваться в документах и поддерживает сценарии автоматизации. Для таких задач общего впечатления от диалога мало. Важно проверить, выполнила ли модель конкретные требования и можно ли использовать результат без исправления человеком.
Мы восстановили два подробных исследования по материалам репозиториев Spice 360 Platform и Чек-листа AI и нашли сводки отдельного теста текстовых моделей для речевой аналитики. В них проверяли готовый оценочный лист, порядок найденных документов и применение правила к истории сделки. Результаты представлены раздельно с учётом полноты исходников.
| Проект | Задача | Что сравнивали | Что считали успехом |
|---|---|---|---|
| Чек-лист AI · 30.09.2026 | Превратить материал об обратной связи продавцу в сохранённый оценочный лист | GPT OSS 120B, GLM 5.3, Qwen 3.6 35B A3B, Kimi K2.6 | Сохранность требований, пригодность к заполнению, время и расход токенов |
| Платформа Антима · 10.08.2026 | Найти нужный документ среди смысловых и лексических отвлекающих | Шесть строк моделей и пар эмбеддингов Яндекса и Сбера | Первое место релевантного документа и его отрыв от ближайшего отвлекающего |
Во втором исследовании представлены модели экосистемы GigaChat для векторизации текста. Отдельные текстовые тесты GigaChat для речевой аналитики рассмотрены ниже. Найденные материалы не подтверждают сравнение всех чат-моделей GigaChat и YandexGPT. У эмбеддинга и чат-модели разные функции: качество поиска нельзя переносить на качество генерации ответа.
Задание: сохранить методику обратной связи продавцу
Основой теста Чек-листа AI стал практический материал для обратной связи после очной продажи украшений. В нём были пять этапов взаимодействия с покупателем: контакт, выявление потребностей, презентация, работа с возражениями и закрытие. Каждый этап включал наблюдаемые действия продавца.
Всего требовалось перенести 24 самостоятельные проверки с отметками «+» и «−». Затем пользователь должен был за одну-две минуты проговорить три вещи: что получилось, чего не хватило и какой один шаг стоит добавить. Дополнительно были заданы четыре правила обратной связи: обсуждать действия, связывать факт с советом, говорить от первого лица и начинать с сильных сторон.
Модель должна была сама выбрать роль заполняющего и подходящий тип листа, коротко объяснить выбор и сохранить готовый результат. Одинаковое уточнение для всех участников запрещало перекладывать выбор роли на пользователя. Проверялось обоснование выбора: сам по себе формат самооценки не считался ошибкой.
Такое задание проверяет сохранность требований лучше, чем просьба написать свободный текст. Если модель объединит приветствие, улыбку и зрительный контакт в одну отметку, наблюдатель уже не сможет отметить их независимо. Если она добавит обязательный норматив времени, которого не было в исходнике, сотрудника начнут оценивать по выдуманному правилу.
Можно ли доверить модели перенос рабочей методики в форму, сохранив её смысл, структуру и условия применения?
Как проходило сравнение текстовых AI-моделей
Для каждой модели создали отдельный пустой тестовый проект. Работал полный агент приложения: с одинаковыми системными инструкциями, навыками и доступными инструментами. Участники получали одно исходное задание и одно уточнение роли. В сохранённых результатах совпадает контрольная сумма текста задания.
Температура была 0,7, лимит max_completion_tokens — 8 000. Для GPT и GLM использовали режим рассуждений low, для Qwen и Kimi — none: минимальные документированные режимы участников. Это сопоставление прикладных конфигураций, но одинаковый вычислительный бюджет рассуждений оно не обеспечивает.
В основную таблицу вошёл один завершённый сравнительный прогон каждой модели. Результаты после сохранения вручную не исправляли. Автоматическую замену модели при сбое и повышение уровня отключили. Предварительные попытки с другой настройкой адаптера отделили от этого сравнения.
Важная особенность: проверялся весь ход работы агента до сохранённого листа. Модель могла обращаться к инструментам несколько раз. Поэтому время ниже — длительность операции на стенде, а входные токены включают повторную передачу контекста и результатов инструментов.
Семь критериев качества
Сохранённые листы оценили вручную по шкале с суммой весов 100. Наибольший вес получили сохранность 24 действий и правила проведения обратной связи. Такая оценка учитывает и содержание, и возможность пользоваться формой.
| Критерий | Максимум | Что проверяли |
|---|---|---|
| Сохранность действий | 30 | Все 24 действия остаются отдельными проверками, без смысловых подмен |
| Разделы и порядок | 10 | Сохранены пять исходных этапов и последовательность |
| Формат отметок | 10 | «+» и «−», без дополнительных шкал и оценочных уровней |
| Устный итог | 15 | Три части обратной связи и длительность 1–2 минуты |
| Общие правила | 10 | Все четыре правила перенесены в готовый лист |
| Критерии наблюдения | 15 | Критерии понятны и проверяемы, новые требования не придуманы |
| Готовность листа | 10 | Лист сохранён, пригоден к заполнению, роль и тип обоснованы |
Индекс 87,5 из 100 означает сумму ручных оценок по этим критериям. Он не означает 87,5% точности модели на произвольных заданиях. Оценку проводили в рамках одного исследования; независимой слепой оценки несколькими экспертами не было.
Результаты: какая модель лучше выполнила задание
| Модель | Индекс / 100 | Время, с | Независимые проверки | Основная проблема |
|---|---|---|---|---|
| GLM 5.3 | 87,5 | 27,8 | 24 из 24 | Лишние оценочные уровни, часть субъективных критериев, одно правило не выражено явно |
| Kimi K2.6 | 82,5 | 103,1 | 24 из 24 | Потеря длительности и первого лица, придуманные нормативы и веса |
| Qwen 3.6 35B A3B | 66 | 18,1 | 20 из 24 | Объединённые отметки, неполный устный итог, новые требования |
| GPT OSS 120B | 55 | 10,6 | 24 из 24 | Потеря правил и устного итога, пустые критерии, подмена очной продажи звонком |
Все четыре участника сохранили лист. Таким образом, технический признак «результат записан» не отделил удачное исполнение от неудачного. Разница проявилась при проверке конкретных требований.
GLM 5.3: наиболее полное исполнение в этом тесте
GLM сохранила 24 самостоятельных действия, пять этапов, три отдельных поля устного итога и длительность одна-две минуты. Роль наставника и формат оценки сотрудника согласовывались с задачей. Именно сочетание этих признаков дало наибольший итоговый балл.
Однако результат требовал проверки редактором. Модель добавила уровни вроде «отлично» и «хорошо», хотя исходник задавал только два состояния. Часть критериев опиралась на субъективные понятия, например искренность. Правило обсуждать действия, а не человека не было сформулировано явно в листе. Утверждение модели в сообщении, что правила сохранены, не заменяло их наличие в самом документе.
Kimi K2.6: подробность с дополнительными требованиями
Kimi также сохранила 24 действия и три поля обратной связи, обосновала роль наставника. По итоговой оценке она заняла второе место. Но в листе исчезли длительность устного разбора и требование говорить от первого лица. Появились отсутствовавшие в исходнике интервалы времени, детали скрипта и дополнительные нормы зрительного контакта.
На стенде операция заняла 103,1 секунды — примерно в 3,7 раза дольше, чем у GLM. Более развёрнутые критерии в этом прогоне не дали более высокого качества. Дополнительный текст увеличивал объём проверки человеком.
Qwen 3.6 35B A3B: все действия упомянуты, но часть нельзя оценить отдельно
Qwen упомянула все 24 исходных действия, однако свела их к 20 независимым отметкам. Приветствие, улыбка и взгляд стали составной проверкой. Подобные объединения произошли с реакцией на сомнение покупателя и завершением контакта. Для оценочного листа это существенная потеря: при частичном выполнении наблюдателю некуда поставить отдельную отметку.
Три темы устного итога были объединены в один комментарий. Не сохранились ограничение длительности и требование одного конкретного шага. В критериях появились новые условия, например обязательное использование имени клиента. Быстрая генерация не компенсировала изменение методики.
GPT OSS 120B: скорость при потере важных частей задачи
GPT OSS была самой быстрой: 10,6 секунды и два обращения к модели. Она перенесла 24 действия отдельно и сохранила пять разделов. Но критерии у пунктов оказались пустыми, правила обратной связи и устный итог исчезли.
Кроме того, модель описала сценарий как самооценку оператора после звонка. Это не соответствовало очной продаже с примеркой и зрительным контактом. Ошибка заключалась в выдуманном контексте, а не в самом выборе самооценки.
| Критерий · максимум | GPT OSS | GLM | Qwen | Kimi |
|---|---|---|---|---|
| 24 действия · 30 | 30 | 30 | 25 | 30 |
| Разделы и порядок · 10 | 10 | 10 | 10 | 10 |
| Отметки без лишней шкалы · 10 | 5 | 3 | 3 | 3 |
| Устный итог · 15 | 0 | 15 | 8 | 12 |
| Правила · 10 | 0 | 7,5 | 5 | 7,5 |
| Критерии наблюдения · 15 | 5 | 12 | 7 | 10 |
| Готовность листа · 10 | 5 | 10 | 8 | 10 |
| Итого · 100 | 55 | 87,5 | 66 | 82,5 |
Ни одна модель не получила полный балл за формат отметок. GPT заменила «+» и «−» на «Да» и «Нет». Остальные дополнительно ввели оценочные уровни или веса. Для продуктов, где пользователь приносит утверждённую методику, такие изменения нужно явно проверять.
Расход токенов: считать нужно всю операцию
| Модель | Входные токены | Выходные токены | Всего | Обращения |
|---|---|---|---|---|
| GPT OSS 120B | 29 694 | 888 | 30 582 | 2 |
| GLM 5.3 | 66 750 | 1 812 | 68 562 | 4 |
| Qwen 3.6 35B A3B | 66 724 | 2 161 | 68 885 | 4 |
| Kimi K2.6 | 84 438 | 2 959 | 87 397 | 4 |
Короткое пользовательское задание может приводить к десяткам тысяч входных токенов: агент повторно передаёт инструкции, контекст и результаты инструментов. Kimi в этом прогоне использовала примерно в 2,86 раза больше суммарных токенов, чем GPT OSS. При этом две модели выполняли разное число обращений и сохранили результат разного качества.
Для расчёта бюджета сначала суммируют вход и выход всех обращений, а затем применяют соответствующие ставки, правила кэширования и округления. Простой расчёт по длине первоначального запроса пропускает часть операции. Суммарные токены разных моделей также не являются одинаковой единицей текста из-за различий токенизации.
Отдельное число токенов рассуждений сервер в этих результатах не сообщил. Значение null означает отсутствие отдельного счётчика, а не доказанный нулевой расход. Об особенностях учёта рассуждений и режимах их выполнения см. документацию MWS.
Яндекс и GigaChat: сравнение эмбеддингов для поиска на русском языке
В платформе Антима исследовали другую проблему: как выбрать модель для поиска по базе документов. Эмбеддинг превращает текст в числовой вектор; близость векторов помогает находить фрагменты со сходным смыслом. Такое описание назначения моделей приводится в документации GigaChat.
Для помощника, который отвечает с опорой на документы, поиск — самостоятельный этап качества. Если вместо правила импорта система подставит похожее правило отчётности, генератор получит неподходящий контекст. Поэтому поисковые модели проверяли отдельно от моделей создания текста.
Шесть сценариев и смысловые отвлекающие
Исследование от 10 августа включало шесть русскоязычных запросов по сценариям платформы: запись клиента, биллинг, уведомления, отчёты, транскрибация и импорт из CRM. Для каждого запроса было шесть документов: один релевантный и пять отвлекающих. Два-три отвлекающих содержали похожие слова, поэтому задача требовала различать смысл.
Это шесть задач ранжирования с шестью документами в каждой, а не 36 независимых запросов. В консолидированном отчёте результаты сведены в шесть строк. Парные query/doc-модели показаны одной строкой; две базовые модели Сбера также объединены. Раздельных чисел для последних в таблице нет.
Какие метрики использовали
Попадание на первом месте фиксирует, оказался ли нужный документ выше всех отвлекающих. Отрыв — косинусная близость нужного документа к запросу минус наибольшая близость отвлекающего. Положительное значение означает правильный порядок; отрицательное — что отвлекающий документ обошёл нужный.
Средний отрыв показывает общую картину, худший — самый слабый набор. Эти разности не являются процентами и не измеряют качество будущего ответа чат-модели.
| Модель / пара | Размерность | Попадания | Средний отрыв | Худший отрыв | Время, ≈ мс |
|---|---|---|---|---|---|
| Yandex text-embeddings-v2 · query + doc | 256 | 6/6 | +0,100 | +0,045 | 211 |
| Yandex text-embeddings/latest | 1 536 | 4/6 | +0,077 | −0,066 | 320 |
| Yandex text-search · query + doc | 256 | 5/6 | +0,061 | −0,019 | 177 |
| Сбер EmbeddingsGigaR | 2 560 | 5/6 | +0,041 | −0,015 | 533 |
| Сбер GigaEmbeddings-3B-2025-09 | 2 048 | 4/6 | +0,033 | −0,075 | 631 |
| Сбер Embeddings / Embeddings-2 · объединённая строка | 1 024 | 5/6 | +0,019 | −0,010 | 464 |
Названия, размерности и время перенесены из отчёта на дату теста. Строка text-embeddings/latest с размерностью 1 536 описывает историческую конфигурацию отчёта; её нельзя считать характеристикой любой современной модели с похожим названием. Значения времени приблизительны, число повторов и распределение задержек в отчёте не указаны.
Что показала таблица
Пара text-embeddings-v2-query + text-embeddings-v2-doc была единственным участником без промаха. Её худший отрыв остался положительным: даже в самом трудном из шести наборов нужный документ сохранил первое место. Это наиболее убедительный результат именно на проверенном наборе.
Среди представленных вариантов Сбера EmbeddingsGigaR дала наибольший средний отрыв: +0,041 при пяти попаданиях. У GigaEmbeddings-3B-2025-09 были четыре попадания и худший отрыв −0,075. Более свежее обозначение и большая размерность в этом сравнении не обеспечили лучший результат.
Пара text-search была быстрее v2 по приблизительным значениям отчёта — 177 против 211 мс, — но допустила один промах. Для поиска инструкций эта разница качества может оказаться важнее небольшой разницы задержки. Решение зависит от требований конкретного проекта и должно проверяться на расширенном корпусе.
Почему query/doc и размерность имеют значение
Парные модели используют отдельные представления для короткого поискового запроса и документа. Для моделей v2 такой способ работы описан в документации Yandex AI Studio. Пару нужно использовать согласованно. Результат 6/6 против 4/6 у другого варианта в нашем отчёте поддерживает выбор конкретной пары, но не доказывает превосходство любой асимметричной модели над любой универсальной.
Вектор из 256 координат оказался достаточным для победителя этого теста. При хранении каждой координаты как float32 такой вектор занимает 1 024 байта, а вектор из 2 560 координат — 10 240 байт. Это десятикратная разница объёма самих числовых массивов. Общий объём базы и скорость поиска зависят также от индекса, метаданных, текстов, числа документов и реализации.
В историческом прогоне базовые Embeddings / Embeddings-2 также отклоняли слишком длинный фрагмент. Это сигнал проверять размер фрагментов и ограничение входа до внедрения. В актуальной на момент подготовки статьи карточке базовой Embeddings указано окно 512 токенов. Небольшое окно ограничивает работу с длинными фрагментами, но само по себе не делает модель непригодной для любого поиска.
Положительный отрыв ещё не задаёт порог релевантности
Победитель лучше ранжировал документы внутри проверенных наборов. Однако по отрыву нельзя автоматически выбрать универсальное значение косинусной близости, ниже которого нужно отвергать результат. Для порога понадобятся абсолютные оценки и отдельные примеры запросов, на которые в базе вообще нет ответа.
Для внедрения нужно дополнительно проверить новые документы, более сложные запросы, разбиение текстов на фрагменты и устойчивость поиска. Замена эмбеддинга также требует согласованного пересчёта векторов документов: сопоставлять запрос и базу следует в одном пространстве представлений. Исследование фиксирует рекомендацию на дату теста, а не подтверждает текущий состав работающего продукта.
Речевая аналитика: текстовый разбор сделок и правила SLA
Отдельное исследование платформы проверяло, как текстовые модели применяют правило «SLA 15 минут» к истории сделки. Это анализ текста коммуникаций и событий сделки после их получения, а не тест распознавания или синтеза речи. Подтверждения таких прогонов сохранились в журнале разработки за 6 и 8 октября 2026 года.
Для теста 6 октября подготовили шесть синтетических сделок с эталонными результатами. Четыре содержали сложные случаи: перевод входящего звонка, отсутствие смены ответственного, недозвон как действие и переход через полночь. Модели должны были корректно применить правило к этим событиям. В сравнении участвовала GigaChat-2-Max наряду с GLM, GPT OSS, Qwen и другими текстовыми моделями.
В справочнике сохранился широкий рейтинг, включая оценки промежуточного и усложнённого наборов. Исходные ответы, скрипт и подробная рубрика этого исследования находились вне репозитория. Поэтому проценты из сводки не переносим в единую шкалу точности: её определение и способ агрегирования сначала нужно восстановить.
| Прогон | Задача и участники | Наблюдение | Граница вывода |
|---|---|---|---|
| 06.10 · 6 синтетических сделок | Правило SLA, в том числе четыре сложных случая; GigaChat-2-Max, GLM, GPT OSS, Qwen и другие | Проверяли применение правила, скорость и нагрузку; GigaChat участвовала в сравнении генерации текста | Для воспроизведения численного рейтинга необходимы исходные результаты и рубрика |
| 08.10 · 11 сделок | Сопоставление GigaChat-2-Max с GLM 5.3 по вердиктам правила SLA | Вердикт GigaChat совпал с вердиктом GLM в 3 из 11 случаев | Это согласие двух моделей; показатель не означает 3 правильных ответа из 11 |
| 08.10 · режим рассуждений | GLM 5.3 с рассуждениями и без них на 11 сделках | Отключение ускорило обработку примерно в 2,6 раза, но изменило вердикт в 4 из 11 случаев; отмечены пропуски переведённого звонка | Нужна проверка каждого изменённого вердикта по эталону; скорость сама по себе не подтверждает качество |
Такой тест проверяет точность применения бизнес-правила к последовательности событий. Недостаточно уверенно пересказать разговор: нужно правильно установить начало отсчёта, учесть допустимое действие и особые случаи правила. Эти требования отличаются от сохранности оценочного листа и от поиска релевантного документа.
Для Сбера работа с текстовыми промптами речевой аналитики, таким образом, подтверждена. Для YandexGPT в найденных материалах есть проверка генерации и задержки при подключении, однако участие в этом сравнении SLA и результаты оценки качества пока не подтверждены. Это различие отражает полноту найденных источников.
Что изменили в Чек-листе AI после исследования
Повторяющиеся ошибки помогли сформулировать требования к приложению. Сохранность задания должна проверяться на уровне готового листа: модель может уверенно сообщить об успехе и всё же потерять часть исходника.
В инструкции добавили правила сохранения материала пользователя. Перед сохранением нового листа стали проверять непустые критерии, перенос явно заданных правил и количество проверок с отметками «+» и «−». При нарушении агент получает конкретные замечания до записи. Для новых листов предусмотрели подбор проверенных примеров.
Эти примеры составили по разбору 12 недавних клиентских проектов. Они охватывали обратную связь продавцу, закрытие смены в кофейне, сопровождение практики куратором и дословный перенос фрагмента памятки. Клиентские контакты в примеры не переносили. Использование примеров в контексте не является обучением весов модели.
| Показатель | Сравнительный прогон | Повтор после изменений |
|---|---|---|
| Независимые проверки | 20 | 24 |
| Устный итог | Один комментарий, неполные условия | Три записи, длительность 1–2 минуты |
| Четыре правила | Часть потеряна | Сохранены |
| Новые нормативы | Добавлены | В финальном повторе не обнаружены |
| Всего токенов | 68 885 | 86 338 |
| Время / обращения | 18,1 с / 4 | 16,663 с / 4 |
| Условия | Общее задание с уточнением роли | Исходное задание без уточнения; обновлены инструкции, примеры и проверка сохранения |
Финальный повтор сохранил 24 проверки, три записи, четыре правила и длительность обратной связи. Это полезная проверка исправления известной ошибки. Но задание уже было представлено в библиотеке примеров, а конфигурация приложения изменилась. Поэтому повтор нельзя включать в первоначальный рейтинг или считать независимым доказательством общей точности Qwen. Отдельный итоговый балл по первоначальной рубрике для него не присваивали.
Практический вывод для разработки: модель и приложение нужно оценивать совместно. Проверка формы перед сохранением защищает требования пользователя, а библиотека примеров помогает задать ожидаемый формат. После таких изменений нужен новый тест на ранее не использованных заданиях.
Что эти исследования позволяют утверждать
Сравнение даёт конкретные наблюдения о сохранённых результатах и выбранных конфигурациях. GLM лучше выполнила одно задание по нашей рубрике; пара Yandex v2 лучше ранжировала документы в шести наборах. Более широкие выводы требуют дополнительной проверки.
- Мало заданий и повторов. Четыре модели прошли по одному завершённому сравнительному запуску. У эмбеддингов было шесть сценариев. Доверительных интервалов и оценки разброса результатов нет.
- Одна ручная рубрика. Другие веса изменят итоговый индекс. Для работы с утверждённой методикой сохранность требований здесь намеренно оценивалась высоко.
- Разные режимы рассуждений. Минимальные доступные режимы не означают одинаковый объём вычислений.
- Время зависит от стенда. Нагрузка, сеть, маршрутизация и инструменты влияют на длительность. Одного замера недостаточно для обещания пользователю постоянной скорости.
- Разная полнота исходников. Для Чек-листа AI сохранены результаты и счётчики операций. Для эмбеддингов сохранилась сводная таблица и описание; исходный скрипт и полные результаты по каждому запросу в репозитории не обнаружены.
- Исторические версии. Названия и измерения относятся к датам тестов. Обновлённые версии моделей нужно сравнивать заново.
В исследовании создания чек-листа не измеряли общее знание русского языка, программирование или качество свободного диалога. В поисковом тесте не оценивали ответы чат-моделей. В частности, таблица эмбеддингов не позволяет ранжировать YandexGPT и генеративные модели GigaChat. Отдельный тест речевой аналитики показывает применение бизнес-правила; его сводные оценки также нельзя объединять с рубрикой Чек-листа AI.
Выводы для AI-проектов: что проверять перед выбором модели
Для Чек-листа AI важна верность материалу пользователя: независимые отметки, правила проведения процедуры и отсутствие придуманных норм. Для поиска платформы важны релевантность документа, работа со смысловыми отвлекающими и ограничения на размер текста. Одинаковая шкала для этих задач скрыла бы существенные различия.
| Сценарий | Вывод из исследования | Следующая проверка |
|---|---|---|
| Оценочный лист или рабочая инструкция | GLM дала наиболее полное исполнение проверенного задания | Новые материалы разных отраслей, повторные запуски, запрет выдуманных нормативов |
| Быстрая генерация формы | Самый быстрый результат может потерять обязательные условия | Сначала минимальный порог качества, затем сравнение времени и ресурсов |
| Помощник по базе документов | Yandex v2 query/doc лидировала на шести сценариях; GigaR была сильнейшей строкой Сбера по среднему отрыву | Расширенный корпус, запросы без ответа, длина фрагментов, дополнительные метрики поиска |
| Автоматизация с записью результата | Успешное сохранение не подтверждает сохранность задания | Проверки содержания до записи и понятные замечания для исправления |
| Расчёт бюджета AI | Контекст инструментов и повторные обращения увеличивают расход | Счётчики всей операции и доля результатов, прошедших проверку без ручной правки |
В следующем сравнении полезно разделить данные на набор для разработки и ранее не использованный проверочный набор. Для каждого задания заранее фиксируют обязательные требования, проводят повторные запуски и оценивают сохранённый результат. У поиска отдельно проверяют наличие ответа в базе и устойчивость к похожим документам.
Так выбор модели привязывается к работе пользователя. Победитель теста получает основание для дальнейшей проверки, а найденные ошибки превращаются в требования к продукту. Для Антимы эти исследования дали оба результата: кандидатов по качеству и конкретные способы проверить сохранность задания перед использованием AI-результата.
Подробнее о продуктах и сценариях — на странице Антима. Отдельные исследования голоса: сравнение синтеза русской речи и задержка голосового AI.
Частые вопросы о сравнении текстовых моделей
Какая модель оказалась лучшей для создания чек-листа?
В одном сравнительном прогоне задания об обратной связи продавцу GLM 5.3 получила 87,5 из 100 — наибольшую сумму по семи ручным критериям. Это результат конкретного задания и конфигурации.
Сравнивали ли Яндекс и GigaChat?
Да, в платформе сравнивали модели эмбеддингов Яндекса и Сбера для поиска по документам. Кроме того, GigaChat-2-Max участвовала в текстовых тестах речевой аналитики по правилу SLA. Участие YandexGPT в этом тесте качества пока не подтверждено найденными источниками.
Означают ли шесть попаданий из шести стопроцентную точность?
Это отсутствие промахов в шести проверенных задачах ранжирования. Для оценки точности на реальных данных нужны более широкий набор запросов, новые документы и повторные проверки.
Почему Qwen получила 66 баллов, если упомянула все действия?
Часть действий была объединена: осталось 20 независимых отметок вместо 24. Дополнительно изменились условия устного итога и появились новые требования. Упоминание действия не равно сохранению отдельной проверки.
Что важнее — модель или правила приложения?
Исследование показывает значение обоих факторов. Модели по-разному выполнили одинаковую задачу, а обновление инструкций, примеров и проверки сохранения помогло исправить известный случай. Их вклад нужно проверять на новых заданиях.