TL;DR
Selective auditing (выборочный аудит) — это правило, по которому каждый ответ ИИ либо принимается автоматически, либо уходит на проверку человеку. У каждого ответа есть оценка уверенности от 0 до 1. Её даёт сама модель или отдельный агент-проверяющий. Всё, что ниже порога, проверяется всегда. Всё, что выше, проверяется случайно, с малой вероятностью («выборочная страховка»). Каждая найденная ошибка двигает порог.
Главная проблема: оценке уверенности модели нельзя слепо доверять. Она бывает завышена, и вы не знаете, сколько ошибок прячется среди «уверенных» ответов. Если проверять только неуверенное, ошибки в уверенной зоне вы никогда не увидите. Порог так и останется неправильным. Если проверять всё подряд, вы тратите деньги и время людей.
Авторы решают это так. Чтобы порог был честным, часть уверенных ответов нужно проверять случайно. Найденную там ошибку засчитывают с большим весом: она «представляет» много таких же непроверенных. Благодаря этому доля пропущенных ошибок остаётся около заданной цели (например, 10% от всех ошибок) при любом потоке данных и без предположений о качестве оценок уверенности.
Схема метода
ВХОД: α — допустимая доля пропущенных ошибок (напр. 10%)
γ — вероятность случайной проверки «уверенных» ответов (напр. 5%)
η — шаг сдвига порога
τ — стартовый порог (напр. 0,5)
КАЖДЫЙ ОТВЕТ ИИ (по очереди):
ШАГ 1: получить оценку уверенности C (от 0 до 1)
ШАГ 2: C < τ → проверяет человек (всегда)
C ≥ τ → проверяет человек с вероятностью γ, иначе принимаем без проверки
ШАГ 3: если проверка была и ошибка найдена → сдвинуть порог:
τ ← τ + η · (1 − π − α) / π
где π = 1 при проверке «ниже порога», π = γ при случайной проверке
ШАГ 4: если проверки не было → порог не меняется
Это реализуется скриптом или автоматизацией, не одним промптом. Ядро алгоритма (шаги 1–4) занимает около 15 строк кода.
Пример применения
Метод хорошо работает на больших потоках однотипных решений, где ошибки случаются регулярно, а проверка человеком дорога. Для редких ошибок он не годится (см. ограничения).
Задача: Селлер на Wildberries и Ozon использует ИИ-агента, который отвечает на вопросы покупателей и сортирует обращения: «возврат», «брак», «жалоба». Обращений около 2000 в день. Менеджер не может прочитать всё. Ему нужно, чтобы не более 10% реальных ошибок агента доходило до клиентов непроверенными. При этом читать он хочет как можно меньше.
Промпт 1 — для агента-проверяющего (даёт оценку уверенности):
Ты — строгий контролёр качества службы поддержки маркетплейса.
Тебе дают: обращение покупателя и ответ нашего ИИ-агента.
Оцени, насколько ответ корректен и безопасен для клиента и для нас.
Учитывай: верно ли определена категория, нет ли выдуманных условий возврата,
нет ли обещаний, которых мы дать не можем.
Верни строго JSON:
{"confidence": число от 0 до 1, "reason": "одно предложение"}
0 = ответ точно ошибочный или опасный, 1 = точно корректный.
Не завышай оценку: если сомневаешься — ставь ниже 0,7.
Обращение: {обращение}
Ответ агента: {ответ}
Промпт 2 — для Claude Code или Cursor (собирает сам механизм выбора):
Напиши Python-скрипт «выборочный аудит» для потока ответов ИИ.
Параметры: alpha=0.1, gamma=0.05, eta=0.01, стартовый порог tau=0.5.
Для каждого ответа с оценкой уверенности C из [0,1]:
1. Если C < tau → pi = 1 (проверка обязательна).
Иначе pi = gamma (проверка случайная, с вероятностью gamma).
2. Бросить монетку: H = 1 с вероятностью pi, иначе H = 0.
3. Если H = 1 → вывести ответ в очередь на проверку человеку,
дождаться результата e (1 = ошибка, 0 = нет ошибки).
Если H = 0 → принять автоматически, порог не менять.
4. Если H = 1: tau = tau + eta * (1 - pi - alpha) * e / pi.
Сохраняй в CSV: время, C, tau, pi, H, e.
Раз в неделю считай долю пропущенных ошибок и долю проверенных ответов.
Результат: Агент-проверяющий выдаёт оценку уверенности для каждого ответа. Скрипт отправляет менеджеру примерно все сомнительные ответы и небольшую случайную долю «уверенных». Порог со временем подстраивается: если случайные проверки находят ошибки среди «уверенных», порог растёт и проверок становится больше. Если ошибок там нет, проверок становится меньше. Доля пропущенных ошибок держится около 10% по теории алгоритма. Конкретные доли проверок зависят от вашего потока и качества проверяющего.
Почему это работает
Слабость: оценка уверенности модели — это текст, который она сгенерировала. Она не гарантирует точность. Модель может уверенно ошибаться. Если проверять только то, где она сомневается, вы не узнаете о её уверенных ошибках. У вас нет обратной связи по этой зоне, и порог невозможно настроить.
Сильная сторона: случайная проверка даёт несмещённую выборку. Если проверять уверенные ответы с вероятностью 5%, найденная ошибка «говорит» о том, что среди остальных 95% непроверенных вероятно есть ещё около 19 таких же. Поэтому ошибку из случайной проверки засчитывают с весом 1/γ. Это называется inverse probability weighting (взвешивание по обратной вероятности).
Как метод использует это: порог двигается по найденным ошибкам, и для него не нужна идеальная калибровка. Гарантия работает при любой оценке уверенности, даже плохой. Плохая оценка просто заставит проверять больше. Хорошая — меньше. Метод сам находит, где ошибки.
Рычаги управления: - α (допустимая доля пропущенных ошибок). Выше α — меньше проверок, больше риска. Для денег и безопасности ставьте 1–5%, для черновых текстов можно 20%. - γ (случайная проверка). Выше γ — быстрее обучается порог, но дороже. Ниже — дешевле, но порог медленнее реагирует. По теории γ не может быть больше 1−α. - η (шаг порога). Больше — быстрее адаптация, но порог «дёргается». Меньше — стабильнее, но медленнее реагирует на изменения. - Источник оценки. Отдельный агент-проверяющий обычно лучше самооценки: он не «привязан» к своему ответу. - Калибровка (Алгоритм 1 в статье). Можно дополнительно «выправлять» оценки онлайн, чтобы они лучше предсказывали правильность. Это экономит проверки, не ломая гарантию.
Шаблон промпта
Метод — это алгоритм, не промпт. Поэтому шаблон — это задание для кодового ассистента (формулы сохранены как в статье):
Напиши скрипт «выборочный аудит» (selective auditing) для потока решений ИИ.
Параметры: alpha={допустимая_доля_пропущенных_ошибок}, gamma={вероятность_случайной_проверки},
eta={шаг_порога}, стартовый порог tau={стартовый_порог}.
Вход для каждого ответа: оценка уверенности C из [0,1] от {источник_оценки}.
Правила:
1. pi = 1, если C < tau; иначе pi = gamma.
2. H ~ Bernoulli(pi): H=1 — отправить на проверку человеком.
3. Если H=1 — получить результат проверки e (1 = ошибка, 0 = верно),
вызвав {способ_получения_проверки}.
4. Если H=1 — обновить порог: tau = tau + eta * (1 - pi - alpha) * e / pi.
5. Если H=0 — принять автоматически, tau не менять.
Логируй: время, C, tau, pi, H, e.
Раз в {период} считай: долю проверенных ответов и оценку доли пропущенных ошибок
(найденные случайной проверкой ошибки среди непроверенных, взвешенные на 1/gamma).
Что подставлять:
- {допустимая_доля_пропущенных_ошибок} — 0,01–0,2 в зависимости от цены ошибки.
- {вероятность_случайной_проверки} — 0,03–0,1. Не больше 1 − alpha.
- {шаг_порога} — 0,005–0,05. Подберите на пробном потоке.
- {источник_оценки} — отдельный агент-проверяющий (лучше) или самооценка модели.
- {способ_получения_проверки} — очередь в Telegram, Google Sheets, CRM, форма.
🚀 Быстрый старт — вставь в чат с Claude/ChatGPT/Cursor:
Вот шаблон алгоритма выборочного аудита. Адаптируй под мою задачу: [твоя задача].
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про цену ошибки (чтобы выбрать alpha), объём потока (чтобы выбрать gamma и eta), откуда берётся оценка уверенности и как человек сообщит результат проверки. Без этих данных параметры придётся подбирать наугад. Она возьмёт структуру из шаблона и напишет готовый скрипт или сценарий для вашей платформы.
Ограничения
⚠️ Нужен скрипт или автоматизация: метод не применить одним промптом в чате. Нужно хранить порог, бросать случайные «монетки» и записывать результаты проверок. Это 15–30 строк кода, который можно собрать через LLM, но руками в таблице это неудобно.
⚠️ Нужен поток с регулярными ошибками: гарантия точности зависит от числа ошибок в потоке. Если ошибки редкие (скажем, раз на тысячи решений), строгих гарантий нет. Авторы предлагают отдельное расширение для таких случаев, но оно в доступной части статьи не разобрано.
⚠️ Нужна честная проверка: алгоритм предполагает, что человек-аудитор всегда исправляет ошибку правильно. Если проверяющий сам ошибается, гарантия теряется.
⚠️ Случайная проверка — обязательная часть: если выбросить её «для экономии», порог перестанет адаптироваться. Ошибки в уверенной зоне станут невидимыми.
⚠️ Гарантия касается среднего: контролируется доля ошибок в среднем за период. Отдельный неудачный день или клиент может получить ошибочный ответ. Для критичных случаев (медицина, деньги, безопасность) нужны дополнительные правила.
⚠️ Оптимальный алгоритм (Алгоритм 2) сложнее: он требует AdaHedge и дуальных переменных. Из практики подходит базовый вариант с аддитивным порогом, который авторы сами называют практичным.
Как исследовали
Авторы поставили задачу так. ИИ принимает решения по очереди. Для каждого есть оценка уверенности. Нужно решить, проверять ли его человеком, при этом доля пропущенных ошибок не должна превышать заданного α. Всё это в режиме онлайн, без предположений о том, откуда берутся данные. Данные могут даже подстраиваться под алгоритм.
Они разработали семейство алгоритмов с доказательствами (теоремы про контроль ошибок). Базовый вариант — аддитивный порог (Теорема 1). Затем — вариант с онлайн-калибровкой оценок (Алгоритм 1, Теорема 2). Затем — оптимально эффективный алгоритм (Алгоритм 2): он асимптотически проверяет не больше, чем нужно, даже против враждебных данных. Для оптимальности они опирались на теорию онлайн-оптимизации с ограничениями (Mannor et al., 2009).
Авторы подчёркивают отличие от соседней работы (Kiyani et al., 2026). Их метод даёт двустороннюю гарантию: ошибка близка к α, а не просто не выше. И оценка точнее: O(1/T) вместо O(1/√T). Кроме того, метод Kiyani «проверяет чаще, чем нужно». Это показано в сравнении.
Эксперименты — на трёх задачах: фильтрация вредных запросов к LLM, качественная аннотация текстов и разметка данных. Заявлено, что методы держат заданный уровень ошибок на практике и существенно сокращают нагрузку на проверяющих относительно baseline. Конкретных цифр и перечня моделей в доступном фрагменте статьи нет, поэтому масштаб экономии здесь не оценить.
Главный вывод для практики: случайная проверка уверенных ответов — не лишние траты, а источник информации. Без неё порог слепнет.
Адаптации и экстраполяции
Это наши идеи, они не из статьи.
🔧 Техника: упростить без кода → «минимальная страховка». Если скрипт собрать нельзя, возьмите лишь принцип: проверяйте всё с оценкой ниже фиксированного порога (например, 0,7) и ещё 5% случайных ответов из остальных. Вручную сверяйте раз в неделю: сколько ошибок нашлось среди «уверенных»? Если больше допустимого, поднимите порог. Гарантий уже не будет, но вы увидите слепую зону, которую иначе не заметить.
Экстраполяция: связка «агент-проверяющий + аудит» для кода. Агент пишет изменения в репозитории, второй агент выдаёт оценку риска. В CLAUDE.md или правилах Cursor вы прописываете: «изменения с риском выше 0,8 идут на автоматический мерж, остальные — на ревью, плюс 5% случайных изменений тоже на ревью». Скрипт ведёт порог. Это перенос идеи на разработку, в статье он не проверялся.
Ресурсы
- Reliable AI-Assisted Decisions via Selective Auditing — Isaac Gibbs (University of Toronto), Elise L. Han (Stanford University), Ryan J. Tibshirani (UC Berkeley), Tijana Zrnic (Stanford University).
- Связанные работы: Kiyani et al. (2026) — простая онлайн-процедура с контролем ошибок, с которой авторы сравнивают метод; Mannor et al. (2009) — теория онлайн-оптимизации с ограничениями; Yu et al. (2026), Sinha & Vaze (2024) — primal-dual методы; Gibbs & Candès (2021) — онлайн conformal prediction.