Как проверить модель с длинным контекстом на своих документах
Миллион токенов в описании модели — характеристика входа, а не оценка качества ответа. Большой договор с приложениями может целиком уместиться в запросе, но модель всё равно перепутает редакции пункта или уверенно ответит на вопрос, которого документы не раскрывают. Поэтому полезнее проверять не максимальный размер загружаемого файла, а рабочий маршрут от исходника до принятого человеком вывода.
Ниже — тест на один день для команды, у которой уже есть документы и понятная задача. Он подойдёт для договора, технического регламента, проектной переписки или набора отчётов. Не используйте реальные персональные данные и секреты в облачном сервисе без разрешения владельца и проверки условий обработки. Если документы нельзя передавать наружу, сначала подготовьте обезличенные копии или выберите разрешённую среду.
Шаг 1. Опишите решение, которое нужно принять
Плохой запрос: «Прочитай всю папку и расскажи главное». Такой ответ трудно признать правильным или неправильным. Лучше выбрать одно решение: «Какие условия оплаты действуют после дополнительного соглашения № 2?» или «В каких файлах указана ответственность за изменение срока?» Запишите, кто проверит ответ и какие ошибки критичны.
Для примера возьмём договор поставки, два приложения и три версии таблицы сроков. Итог должен содержать действующее условие, название файла, страницу или строку, а также короткое объяснение, почему более старая редакция не применяется. Если исходники противоречат друг другу, правильный результат — указать конфликт, а не самостоятельно выбрать удобную версию.
Шаг 2. Подготовьте небольшой, но сложный набор
Не начинайте с предельного объёма. Соберите около десяти документов: два простых, несколько взаимосвязанных и хотя бы один «ловушечный». Ловушка — это не выдуманный текст, а обычная рабочая неприятность: одинаковое название файла, скан без распознанного текста, отменённый пункт, таблица с другой валютой или письмо с предварительным обещанием вместо подписанного условия.
Каждому файлу присвойте короткий идентификатор и сохраните неизменённый оригинал отдельно. После OCR выборочно сравните цифры, даты и отрицания со сканом. Распознанный документ с ошибочным «не» способен сделать проверку бессмысленной. Для подготовки разных форматов можно использовать наш разбор Pandoc для документов, но PDF-сканы всё равно требуют отдельной проверки распознавания.
Шаг 3. Составьте ответы до запуска модели
Эксперт, который знает документы, заранее пишет пять–семь контрольных вопросов и фиксирует ожидаемые фрагменты. В наборе должны быть:
- простой факт, который легко найти;
- условие, разбросанное по двум файлам;
- конфликт старой и новой редакции;
- числовое значение с единицей измерения;
- вопрос, на который в архиве нет ответа.
Последний пункт особенно важен. Если модель не умеет сказать «в предоставленных документах этого нет», большой контекст лишь увеличит пространство для правдоподобной ошибки. Для каждого вопроса храните не только эталонную фразу, но и точный файл, страницу или строку. Без этого проверяющий начнёт оценивать стиль ответа вместо содержания.
Шаг 4. Проведите одинаковые прогоны
Сначала измерьте ручной способ: сколько времени сотрудник потратил на поиск и проверку. Затем загрузите тот же набор в модель с длинным контекстом. В запросе попросите отвечать по предоставленным файлам, указывать подтверждающие фрагменты и отдельно обозначать отсутствие данных. Не добавляйте в подсказку правильный ответ — иначе вы проверите способность модели перефразировать подсказку.
Повторите прогон ещё раз, поменяв порядок файлов. Если ответ резко меняется, причина может быть в расположении нужного места внутри большого входа. Зафиксируйте название версии модели и способ подключения: веб-интерфейс, прямой API и посредник могут иметь разные лимиты и настройки. Не смешивайте эти результаты в одну строку. Свежий анонс Kimi K3.1 Pro — повод добавить кандидата в такой тест, но не основание пропустить контроль.
Шаг 5. Проверяйте доказательства, а не убедительность
Проверяющий открывает каждый названный источник. Отметьте четыре состояния: верный ответ с точной ссылкой; верный ответ без проверяемой ссылки; ошибка; честный отказ при недостатке данных. Второе состояние нельзя приравнивать к первому: сотруднику всё равно придётся искать подтверждение вручную. В числовых ответах отдельно сверяйте единицы, период, валюту и округление.
Считать только процент правильных ответов недостаточно. Запишите время загрузки, время ожидания, время ручной проверки и время исправления. Если модель ответила за двадцать секунд, а проверка заняла двадцать минут, экономия может исчезнуть. Для задач с необратимыми решениями — подпись, платёж, публичное заявление — финальное подтверждение остаётся за человеком.
Шаг 6. Сравните с поиском по частям
Длинный контекст — не единственный маршрут. Простой текстовый поиск или индекс с извлечением нескольких подходящих фрагментов иногда оказывается дешевле и удобнее для объяснения результата. Проведите тот же набор вопросов через поиск по документам, передавая модели только найденные куски. Сравнивайте принятый ответ с подтверждением, а не число токенов или впечатление от диалога. Для выбора между текстовым и векторным индексом есть отдельный практический разбор поиска по документам.
Если большой вход лучше справляется с междокументными связями, это сильный аргумент в его пользу. Если же поиск по частям выдаёт те же проверенные ответы при меньшей стоимости, нет смысла загружать архив целиком по привычке. Часто подходит гибрид: сначала найти релевантные разделы, затем дать модели достаточно соседнего контекста для трактовки.
Шаг 7. Запишите решение и границу применения
В конце нужен не «победитель бенчмарка», а короткий протокол: какие типы вопросов модель решает, где ошибается, как часто не находит подтверждение, сколько стоит один принятый ответ и кто отвечает за проверку. Сохраните пять исходных вопросов для повторного теста после обновления модели. Не заменяйте старую дату публикации материала датой нового прогона: изменения в методике отмечайте отдельно.
Начать можно с десяти файлов и пяти вопросов. Масштабировать на весь архив разумно лишь после того, как второй человек повторил проверку и получил сопоставимый результат. Длинное окно помогает уменьшить подготовку входа; доверие к выводу по-прежнему строится на проверяемой ссылке на оригинал.
Частые вопросы
Сколько документов нужно для первого теста? Достаточно небольшого набора, если в нём есть версии, конфликт и вопрос без ответа. Случайная тысяча похожих файлов даст меньше пользы.
Можно ли сравнивать модели только по цене за миллион токенов? Нет. Важнее полная стоимость принятого результата: вызовы, исправления и время проверяющего.
Что делать, если модель не указывает страницу? Считать ответ неподтверждённым и открыть исходник вручную. Для регулярной работы лучше изменить подготовку файлов или выбрать маршрут, сохраняющий ссылки на фрагменты.