Четыре урока автоматизации: фильтрация данных, голосовой ввод, ИИ-агенты и production

Привет, на связи Папа Карло. Четыре технических кейса октября 2026 года показывают, почему автоматизацию с ИИ нужно проверять на каждом этапе обработки данных. Компактная модель Jev помогает отсеивать ненужные материалы до обращения к большой языковой модели, связка Whisper и LLM превращает диктовку в отредактированный текст, тестирование ИИ-агентов выявляет действия с невыполненными условиями, а production smoke-тесты обнаруживают проблемы реального сервиса, но сами способны испортить аналитику. Общий практический вывод: для надёжной системы недостаточно проверить, что программа получила ответ или выполнила команду. Нужно установить, сохранились ли полезные данные, не изменился ли исходный смысл, имелось ли право выполнить действие и не повредила ли проверка рабочему процессу.

Четыре кейса и их результаты

КейсОсновная задачаПодтверждённый результат или ограничениеJev и Claude SonnetПредварительный отбор материаловНа выборке из 67 записей исключены 10 ненужных без потери размеченных полезныхHandy, Whisper и LLMРаспознавание и очистка диктовкиЛокальное распознавание, последующее редактирование текста и возврат исходной расшифровки при сбое APIАгенты с function callingПроверка условий вызова инструментовОписан класс ошибок, проходящих через обычные уровни контроляProduction smoke-тестыПроверка реального пользовательского путиТестовые операции затрагивают рабочие компоненты и могут нарушать аналитику

Jev: как отсеивать ненужные материалы до большой модели

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

Почему фильтр решает закрытую задачу

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

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

Что показали размеченная выборка и теневой режим

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

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

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

Как использовать этот подход

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

Whisper и LLM: как очищать диктовку без потери смысла

Второй кейс решает другую проблему входных данных. Человек может диктовать быстрее, чем печатает, но устная речь обычно содержит повторы, оговорки, слова-паразиты и исправления на ходу. Прямое распознавание сохраняет эти особенности. Для получения более аккуратного текста программу Handy объединили с Whisper, внешней языковой моделью и локальным посредником на Python под названием «Чистовик».

Как проходит обработка

Handy — открытая программа с лицензией MIT. Пользователь удерживает горячую клавишу, произносит фразу и отпускает клавишу. Whisper распознаёт звук непосредственно на компьютере. Затем полученный текст может передаваться на дополнительное редактирование языковой модели. В описанной реализации используется Whisper Large v3 Turbo и Claude Sonnet 5.5 через совместимый API.

В приведённой конфигурации на видеокарте RTX 4080 Super распознавание восьмисекундной записи занимало 0,17 секунды, а 42-секундной — 0,45 секунды. Редактирование внешней моделью занимало от полутора до трёх секунд. Эти значения получены для конкретного оборудования и реализации; использовать их как универсальный прогноз времени работы нельзя.

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

Зачем понадобился Python-посредник

Программа «Чистовик» принимает запросы Handy на локальном порту 8765 и перенаправляет их языковой модели. Для реализации используется стандартная библиотека Python. Промпт и словарь хранятся отдельно в текстовых файлах, которые перечитываются при каждой диктовке. Благодаря этому правила исправления можно менять без перезапуска посредника.

Почему контекст важнее механической замены

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

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

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

ИИ-агенты: когда корректный вызов инструмента становится ошибкой

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

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

Почему проверки схемы недостаточно

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

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

Что проверять разработчику

Из описанной методологии следует полезное разделение тестов. Сначала стоит проверить, способен ли агент правильно сформировать запрос. Затем — имелись ли фактические условия для вызова. Наконец, необходимо отдельно оценить, соответствует ли итоговый отчёт реально выполненным действиям.

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

Production smoke-тесты: реальная проверка с побочными эффектами

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

Как тестовые действия нарушают аналитику

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

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

Как ограничить воздействие проверок

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

Что объединяет четыре подхода

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

ЭтапОпасная ошибкаЧто нужно наблюдатьОтборИсключение полезного материалаРешение фильтра, категорию и дальнейшую судьбу записиПреобразованиеИскажение исходного смыслаИсходную и обработанную версии текстаДействиеВызов без необходимых условийСостояние системы и основание для выполненияПроверка сервисаИзменение реальных данных и аналитикиСозданные тестом операции и их последствия

Как организовать проверку своей автоматизации

До внедрения

1. Разделите процесс на получение данных, обработку, принятие решения, выполнение действия и фиксацию результата. Для каждого этапа сформулируйте отдельный критерий успеха.
2. Определите наиболее дорогую ошибку. Для архива это может быть потеря нужной записи, для голосового ввода — изменение смысла, для агента — недопустимое действие.
3. Подготовьте примеры правильного и неправильного поведения. Включите неоднозначные входные данные, отсутствующие условия и сбои зависимых компонентов.
4. Установите порядок работы при неопределённости. Если безопаснее сохранить запись, чем удалить её, такая логика должна быть явной. Если внешний редактор недоступен, предусмотрите использование первоначальных данных.

Во время проверки

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

Типичные ошибки внедрения

Копирование чужого порога классификации

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

Перенос результатов измерений на другое оборудование

Скорости распознавания Whisper приведены для RTX 4080 Super. Они показывают возможности одной конфигурации, но не гарантируют такую же задержку на другом компьютере. Отдельно следует учитывать время сетевого редактирования текста.

Подмена точного текста литературно красивым

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

Доверие отчёту агента без проверки состояния

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

Восприятие тестового трафика как настоящего

Production smoke-тест может работать через реальные сервисные компоненты и оставлять настоящие записи. Если его события не отличать от пользовательских, проверка станет источником ошибочных управленческих выводов.

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

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

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