Как не потерять полезные данные при ИИ-фильтрации: пороги, ошибки и контроль

Привет, на связи Папа Карло. ИИ-фильтрация данных помогает сократить количество материалов, которые поступают на дорогостоящую обработку, но главный критерий её качества — не число удалённых записей, а сохранность полезной информации. Практичный подход состоит из четырёх элементов: чётких категорий, осторожного порога отказа, проверки решений на размеченных данных и сохранения исходников. Разберём эту схему на реальных примерах компактных моделей Jev и Strands Decider 2B, а также инструментов OmniExtractBench и PDF Desk.

Почему фильтрация может навредить

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

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

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

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

Что показала проверка Jev на сохранённых материалах

В опубликованном примере компактную модель Jev от TypeSafe включили перед Claude Sonnet в конвейер обработки сохранённых материалов из Telegram. Изначально скрипт ежедневно передавал новой языковой модели все собранные записи, после чего выполнялся отдельный редакторский отбор.

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

Результаты первоначальной проверки

На размеченной выборке из 67 записей находилось 28 ненужных материалов. Модель исключила 10 из них и при этом сохранила все материалы, которые в этой выборке были признаны полезными. Таким образом, доля отклонённых среди ненужных составила примерно 35,7%. Это показатель конкретного теста, а не универсальная эффективность Jev.

Затем модель работала в теневом режиме с 26 сентября по 3 октября 2026 года. Она оценивала новые сообщения и записывала решения, не изменяя действующий производственный конвейер. За этот период поступило 19 материалов. Фильтр предложил исключить девять, из которых восемь впоследствии отклонил и основной редакторский этап. Девятый материал на момент оценки ещё не был разобран.

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

Почему формулировка вопроса влияет на результат

В отдельном эксперименте качество заметно зависело от постановки задачи. При расплывчатом вопросе о полезности факта показатель AUC составлял 0,46. После уточнения конкретного критерия он вырос до 0,95 на том же наборе данных.

Этот контраст особенно полезен при разработке классификатора. Вопрос «Полезен ли материал?» допускает слишком много трактовок. Более определённая постановка — содержит ли запись инструкцию, которую можно применить, или конкретную воспроизводимую идею — ближе к фактическим требованиям отбора.

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

Как выбирать порог отказа

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

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

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

Особого внимания требует обработка ошибочного или пустого ответа. В рассмотренной конфигурации Jev при отсутствии корректного результата материал сохранялся. Это осознанная политика отказоустойчивости: техническая ошибка классификатора не должна автоматически превращаться в удаление информации.

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

Как разделить компактный фильтр и основную языковую модель

Модель, принимающая короткое решение, не обязана выполнять ту же работу, что и универсальный генератор текста. Это различие хорошо иллюстрирует Strands Decider 2B. Она предназначена для выбора вариантов, оценки вероятности ответа «да/нет» и получения числового скора с калиброванной уверенностью.

Strands Decider 2B содержит 1,9 млрд параметров и основана на Qwen3.5-2B-Base. Для операции выбора заявлено время около 115 мс. Такое значение показывает потенциальную пригодность для оперативных решений, но не служит гарантией задержки на любом компьютере или для любой конфигурации.

Модель рассчитана на самостоятельное развёртывание и может работать на CPU, потребительских видеокартах и компьютерах Mac с Apple Silicon. Веса распространяются по лицензии Apache-2.0. Пакет strands-decider включает командную строку и HTTP-сервер.

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

Рабочую архитектуру удобно разделить следующим образом:

1. Приём данных. Система сохраняет материал вместе с исходным содержимым и идентификатором.
2. Быстрое решение. Компактная модель определяет, нужно ли передавать запись на подробную обработку.
3. Основная обработка. Большая языковая модель анализирует сохранённые материалы и готовит содержательный результат.
4. Контроль. Редактор или другой проверяющий сопоставляет итог с исходными данными.
5. Архив решений. Система хранит основания отбора, чтобы можно было пересмотреть спорные случаи.

Это логическая схема, составленная из возможностей рассматриваемых инструментов, а не описание готовой интеграции Jev и Strands Decider 2B. Для реального проекта необходимо отдельно реализовать передачу данных, журналирование и обработку ошибок.

Если используется локальный HTTP-сервер Strands Decider 2B, нужно учитывать его конфигурацию. В комплектном варианте он привязывается к адресу 127.0.0.1 и не имеет собственной аутентификации. Публикация такого сервиса в сети потребовала бы отдельного защитного слоя. Поэтому локальный запуск и сетевой доступ необходимо рассматривать как разные условия эксплуатации.

Как оценивать качество решений, а не только общую точность

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

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

OmniExtractBench оценивает извлечение, а не является готовым инструментом измерения качества фильтра Jev. Однако его принцип — разбирать итоговую оценку на отдельные проверяемые решения — полезен и для анализа классификаторов.

Какие результаты нужно различать

Фактическое состояниеРешение фильтраИнтерпретацияМатериал полезенСохранитьКорректное сохранениеМатериал ненужныйОтклонитьКорректное исключениеМатериал полезенОтклонитьОшибочная потеря полезного материалаМатериал ненужныйСохранитьЛишняя нагрузка на следующий этап

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

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

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

Зачем сохранять связь ответа с исходным документом

Предварительная фильтрация отвечает на вопрос, нужно ли обрабатывать запись. Следующая задача — убедиться, что после обработки ИИ не исказил сведения. Особенно заметно это при работе с договорами, инструкциями и техническими PDF.

Приложение PDF Desk предлагает механизм, при котором пользователь задаёт вопрос к PDF и может перейти к физической странице исходного документа, на которую ссылается модель. Проект использует Python, Streamlit и PageIndex.

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

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

Однако ссылка на страницу ещё не подтверждает правильность интерпретации. Человек должен проверить не только наличие фразы, но и её смысл, соседние условия и ограничения. PDF Desk облегчает такую проверку, но не подменяет её.

Практическая последовательность внедрения фильтра

Шаг 1. Сформулировать критерий пригодности

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

Шаг 2. Подготовить контрольную выборку

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

Шаг 3. Проверить несколько формулировок задачи

Сравните конкретные вопросы, отражающие критерии отбора. Результаты эксперимента с Jev показывают, что формулировка может существенно влиять на качество ранжирования. Поэтому промпт следует рассматривать как часть конфигурации системы, которую нужно фиксировать и проверять при изменениях.

Шаг 4. Выбрать осторожный порог

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

Шаг 5. Запустить теневой режим

Сначала пусть классификатор только записывает решения, но ничего не исключает из существующего конвейера. Так можно сравнивать предложения фильтра с решениями действующего процесса. Именно такой подход использовался при дополнительной проверке Jev.

Шаг 6. Сохранить восстановимость

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

Шаг 7. Проверять качество после включения

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

Типичные ошибки при автоматическом отборе

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

Использование расплывчатого критерия. Слова вроде «интересный» или «качественный» без определения оставляют модели слишком широкую свободу интерпретации. Решение — связать категории с конкретными признаками записи.

Перенос порога из чужого проекта. Значение 0,2 оказалось частью конкретного эксперимента с Jev, а не универсальным стандартом. Решение — подбирать порог на собственных размеченных данных.

Удаление записей при техническом сбое. Отсутствие ответа нельзя автоматически трактовать как отсутствие ценности. Решение — сохранять исходник и отдельно отмечать техническую ошибку.

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

Принятие готового текста без проверки документа. Даже корректно отобранный PDF может быть неверно интерпретирован основной моделью. Решение — сохранять возможность перехода к исходному фрагменту и проверять его контекст.

Как проверить, что фильтрация действительно работает

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

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

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

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

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

Итог: экономия должна быть проверяемой

Пример Jev показывает, что компактный классификатор способен сокращать число ненужных обращений к большой языковой модели. Strands Decider 2B иллюстрирует возможности отдельной модели для быстрых решений, OmniExtractBench — ценность детального разбора оценок, а PDF Desk — практическую пользу перехода от ответа к исходному документу.

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