Выбирать нейросеть по одной удачной демке — почти гарантированный способ купить не то. Сегодня сервис бодро пишет письмо клиенту, а завтра пропускает срок в договоре, придумывает ответ по базе знаний или не проходит проверку кода. Команде нужен не «самый умный чат», а инструмент для конкретной работы.
Сразу разделите два вывода. Лучше по качеству — точнее выполняет задачу в слепом тесте. Удобнее для внедрения — проходит ваши требования по доступу, данным, договору и интеграциям. Это не одно и то же. Удобная оплата не делает модель сильнее, а сильный ответ не отменяет запрет службы безопасности.
Отсейте то, что компания не сможет использовать
Не начинайте с промптов. Сначала составьте короткий фильтр. Он спасает от недель тестов сервиса, который потом не согласуют бухгалтерия, юристы или ИБ.
| Критерий | Что проверить до теста |
|---|---|
| Доступ | Можно ли работать из вашей страны официально, без обходов? |
| Оплата и договор | Подходит ли способ оплаты и можно ли согласовать нужные условия? |
| Данные | Разрешено ли загружать в сервис ваши материалы? |
| Интеграция | Есть ли API, работа с файлами, права доступа и нужные коннекторы? |
| Лимиты | Помещаются ли ваши документы и запросы в контекст? |
Отдел продаж хочет делать письма по расшифровкам звонков. Но политика компании запрещает отправлять записи разговоров во внешнее облако. В такой ситуации неважно, насколько красиво модель пишет: она не прошла входной фильтр.
Если рассматриваете OpenAI, отдельно проверьте список поддерживаемых стран и территорий. Компания предупреждает, что доступ или оплата из неподдерживаемой страны могут привести к блокировке аккаунта.
Возьмите до четырёх кандидатов, прошедших фильтр. Добавьте международные модели, если у компании есть официальный доступ. Добавьте решения из уже согласованной инфраструктуры. Не называйте этот список рейтингом: это просто участники вашего теста.
Пять задач покажут больше, чем общий рейтинг
Не выводите средний балл «за интеллект». Сильный текст не компенсирует пропущенный пункт в договоре, а хороший ответ о стратегии не исправит сломанный pull request. Каждую задачу оценивайте отдельно на одинаковых материалах.
Перед запуском зафиксируйте дату, точное название и версию модели, режим рассуждений, промпт, входные файлы и настройки. Названия моделей скройте от проверяющих. Два сотрудника независимо смотрят ответы, а потом сверяют оценки.
1. Коммерческий текст: ищите выдуманные обещания
Возьмите обезличенный бриф реального продукта: аудитория, функции, ограничения, факты для клиента. Попросите сделать первый экран лендинга и письмо после встречи. Редактор отмечает добавленные скидки, сроки, гарантии и интеграции, которых в брифе не было.
Ты — редактор B2B-сервиса.
На основе брифа подготовь:
1. Заголовок первого экрана — до 12 слов.
2. Подзаголовок — до 28 слов.
3. Письмо для отдела продаж — до 900 знаков.
Не добавляй фактов, которых нет в брифе.
Если данных не хватает, перечисли пробелы отдельным списком.
Бриф:
[вставить обезличенный бриф]Победитель по качеству — модель, после которой редактор меньше правит факты и структуру. Для внедрения выбирайте только сервис, который можно подключить к вашему рабочему контуру.
2. Документ до 32 тысяч токенов: дайте всем равные условия
Возьмите регламент или договор, который целиком помещается в контекст каждого кандидата. Попросите найти обязательства сторон, противоречия и вопросы для юриста. Красивый пересказ не считается результатом, если модель пропустила срок расторжения или запрет.
Проверяйте четыре вещи: найденные обязательные условия, ссылки на пункты, выводы без основания и время на проверку ответа человеком.
3. Длинный документ: лимит не равен качеству
Разделите файлы на классы: до 32 тысяч токенов, от 32 до 128 тысяч, от 128 до 256 тысяч и больше. В таблице отмечайте, получила ли модель документ целиком или частями. Не штрафуйте её за «низкий интеллект», если файл не помещается: это ограничение сценария.
Юрист проверяет длинное приложение к договору и ищет конфликт между условиями оплаты и приложением со сроками. Полезный ответ показывает оба пункта и объясняет конфликт. Гладкое резюме на две страницы здесь только тратит время.
4. База знаний: ответ без источника опасен
Загрузите одинаковую базу инструкций: правила возвратов, тарифы и сценарии поддержки. Спросите: «Когда клиенту можно вернуть деньги и кто согласует исключение?» Хороший ответ называет документ, раздел и короткую цитату. Уверенная формулировка без источника не годится: сотрудник может отправить её клиенту и нарушить правило.
Отвечай только по приложенным документам.
Для каждого вывода укажи:
— название документа;
— раздел или пункт;
— короткую цитату-основание.
Если в документах нет ответа, напиши:
«В базе нет подтверждённой информации».
Вопрос:
[вставить вопрос сотрудника]5. Код: решение принимает CI, а не красивое объяснение
Дайте всем моделям один баг, одинаковый фрагмент репозитория и существующие тесты. Например, в форме оплаты пустое поле проходит проверку и сервер возвращает ошибку. Проверка простая: проект собирается, тесты проходят, регрессий нет, изменение можно принять в pull request.
По качеству выигрывает модель с большим числом принятых изменений и меньшим числом исправлений после ревью. По внедрению — инструмент, который разрешён в среде разработки и не отправляет код туда, куда его отправлять нельзя.
Сведите ответы в таблицу решений
Не смешивайте цену, удобство и качество в один балл. Иначе дешёвый ответ, который сотрудник переписывает, незаметно победит хороший результат. Заполните таблицу после слепой проверки.
| Задача | Критерий качества | Лидер по качеству | Ограничение внедрения | Выбранный сервис |
|---|---|---|---|---|
| Коммерческий текст | Факты, структура, число правок | [после теста] | Данные и CRM | [после согласования] |
| Короткий документ | Пропуски и ссылки на пункты | [после теста] | Лимит и файлы | [после согласования] |
| Длинный документ | Работа с полным файлом | [после теста] | Контекст и цена | [после согласования] |
| База знаний | Точность цитат и права доступа | [после теста] | Поиск и доступы | [после согласования] |
| Код | CI, тесты, регрессии | [после теста] | Среда разработки | [после согласования] |
Типичной команде без сильной разработки стоит начать с коммерческих текстов, коротких документов и базы знаний. Эти задачи быстро показывают, экономит ИИ время или производит новые правки. Код, изображения и огромные архивы подключайте отдельными тестами: один чат не обязан быть лучшим во всём.
Сегодня возьмите пять задач из прошлой рабочей недели, обезличьте материалы и запустите их у кандидатов с одинаковыми промптами. Через один рабочий цикл у вас появится не чужой рейтинг, а решение, которое можно защитить перед командой и закупкой.
Статья помогла?
