TL;DR
AI-фильтры безопасности (guardrails) отлично находят угрозы, мошенничество и токсичный контент в коротких текстах — но стабильно пропускают ту же самую фразу, если она "спрятана" в длинном документе. Причина не в том, что текст длинный сам по себе, а в том, что доля опасного фрагмента относительно всего объёма падает — модель буквально распределяет внимание по всему тексту, и на конкретную опасную строчку его остаётся всё меньше.
Исследователи вставляли одну и ту же опасную фразу в документы разной длины — от 250 слов до 32 тысяч. При коротком тексте фильтры находили угрозу почти всегда. При длинном — обнаружение падало больше чем в два раза. Причём если ту же опасную фразу просто повторяли много раз (без "мусорного" текста вокруг), падение было в разы меньше. Значит, дело не в длине как таковой, а в разбавлении — чем больше "шума" вокруг иголки, тем хуже видно иголку.
Решение простое: не кидай модели весь длинный текст целиком для проверки. Разбей его на куски, проверь каждый кусок отдельно, и если хотя бы один кусок помечен как опасный — весь документ считается опасным. Это возвращает текст в "короткий" режим, где модель видит опасность отчётливо.
Схема метода (Chunked Detection)
ШАГ 1: Разбей длинный текст на куски по N слов → список кусков
ШАГ 2: Проверь каждый кусок ОТДЕЛЬНЫМ запросом на наличие опасного контента → вердикт safe/unsafe по каждому куску
ШАГ 3: Агрегируй по правилу "ИЛИ": если хоть один кусок помечен unsafe → весь документ = unsafe
Все три шага можно выполнить как отдельные запросы к LLM в одном чате — без кода и API.
Пример применения
Задача: Служба поддержки крупного маркетплейса (условно Wildberries) хочет автоматически проверять длинные переписки с покупателями — искать угрозы, попытки мошенничества с возвратами, скрытые манипуляции — чтобы эскалировать диалог на живого модератора.
Промпт:
Вот длинная переписка поддержки с клиентом (около 8000 слов).
Раздели её на части по 300 слов.
Для каждой части отдельно ответь:
- Номер части
- Есть ли признаки угрозы, мошенничества или манипуляции (да/нет)
- Короткая причина, если "да"
В конце дай итоговый вердикт: если хотя бы одна часть помечена "да" — весь диалог считается подозрительным и требует внимания модератора.
Текст переписки:
{текст}
Результат: Модель выдаст таблицу или список из N частей с вердиктом по каждой, короткое пояснение к подозрительным кускам, и финальную строку с общим вердиктом. Если кинуть тот же текст без разбивки одним запросом — есть высокий риск, что единственная опасная фраза среди тысяч нейтральных слов останется незамеченной.
Почему это работает
Внимание модели — это ограниченный ресурс, который делится между всеми токенами входа. Когда опасная фраза занимает 90% текста — модель смотрит почти только на неё. Когда та же фраза занимает 0,5% от документа в 32 тысячи слов — внимание "разбавляется" окружающим текстом, и модель буквально видит опасность слабее, даже если смысл фразы не изменился.
На коротких текстах у модели нет конкурентов за внимание — она видит опасность отчётливо. Разбивка на куски искусственно пересобирает длинный документ в набор коротких — и возвращает модель в её сильную зону.
Рычаги управления: - Размер куска — меньше кусок → выше чувствительность к мелким деталям, но больше запросов и дороже по времени/токенам. - Правило агрегации — вместо строгого "хоть один кусок unsafe = весь текст unsafe" можно поставить порог ("минимум 2 куска из 10"), если хочешь меньше ложных срабатываний. - Критерий проверки — вместо "угроза/мошенничество" можно подставить любой другой критерий поиска: противоречие в договоре, ошибку в отчёте, нарушение регламента.
Шаблон промпта
У меня длинный текст на проверку: {критерий_проверки} (например: угрозы, токсичность, скрытое мошенничество, нарушение регламента).
Раздели текст на части по {N} слов.
Для каждой части ответь:
- Номер части
- Обнаружен ли {критерий_проверки} (да/нет)
- Краткое объяснение, если "да"
В конце дай итоговый вердикт по всему тексту: если хотя бы одна часть помечена "да" — весь текст считается проблемным.
Текст:
{текст}
Подставь свой критерий проверки (что именно ищешь), размер куска (обычно 200–500 слов достаточно) и сам текст.
🚀 Быстрый старт — вставь в чат:
Вот шаблон для проверки длинного текста по частям (Chunked Detection). Адаптируй под мою задачу: {твоя задача}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит какой критерий проверки использовать и какой размер куска подойдёт — потому что от этого зависит чувствительность метода к твоей конкретной задаче.
Ограничения
⚠️ Не всё из статьи применимо в чате: метод "заострение внимания" (Attention-Head Sharpening) требует прямого доступа к весам модели и её внутренним attention-механизмам — это невозможно сделать в обычном чате ChatGPT/Claude. Из всей статьи руками применим только принцип разбивки на части (Chunked Detection).
⚠️ Больше запросов — дороже и дольше: разбивка длинного документа на куски по 300 слов означает десятки отдельных проверок вместо одной. Для очень длинных текстов это заметно увеличивает время и расход токенов.
⚠️ Не универсальное улучшение: на одной из моделей в исследовании (PolyGuard) разбивка почти не дала прироста — метод сильнее работает там, где модель изначально плохо держит длинный контекст.
⚠️ Проверено на специализированных фильтрах безопасности, не на обычных ChatGPT/Claude в роли "проверь текст на риски". Перенос принципа на обычные диалоговые модели логичен, но не проверен напрямую в этой работе.
Как исследовали
Исследователи взяли 15 популярных фильтров безопасности (guardrails) и синтетически создали тексты разной длины — от 250 слов до 32 тысяч, — куда вставляли одну опасную фразу ("иголку") среди нейтрального текста из Википедии ("стога"). Чтобы отделить эффект "разбавления" от эффекта "просто длины", сделали два варианта: Benign-Fill (опасная фраза среди нейтрального текста) и Needle-Repeat (опасную фразу просто повторяли много раз без разбавления).
Оказалось: в первом варианте обнаружение падало вдвое, во втором — почти не менялось. Это и доказало, что виноват именно эффект разбавления, а не длина сама по себе. Дальше команда залезла "под капот" шести моделей и посмотрела на паттерны внимания на уровне отдельных нейронных "голов" — обнаружили, что несколько специализированных голов внимания реально отслеживают опасный контент, но их сигнал слабеет пропорционально степени разбавления. На основе этого предложили два метода лечения: разбивку на части (работает без доступа к весам) и "заострение" специализированных голов внимания (работает только с доступом к внутренностям модели). Оба метода протестировали на пяти разных наборах данных, включая атаки типа Many-shot Jailbreaking — и оба дали устойчивый прирост качества обнаружения.
Ресурсы
LongGuard: Mechanistic Analysis and Training-Free Mitigation of Long-Context Failure in Safety Guardrails. Ziyang Chen, Xing Wu, Songlin Hu — Institute of Information Engineering, Chinese Academy of Sciences. Код и данные: github.com/czyPL/LongGuard