TL;DR
Sharding (дробление) — техника проверки: вместо того, чтобы просить LLM сверить документ сразу со всеми пунктами чек-листа за один заход, критерии разбивают на маленькие группы, каждую группу проверяют отдельным запросом с полным контекстом документа, а потом результаты собирают вместе.
Когда LLM просят проверить документ по 50–100 пунктам за один раз, модель не проверяет каждый пункт — она физически не может удержать в фокусе внимания сотню условий одновременно. Она начинает угадывать: по данным исследования, модель честно признаётся, что не проверила 70–85% пунктов, и просто ставит «соответствует» по умолчанию. Самое неприятное — больше бюджета (токенов, шагов рассуждения) эту проблему не решает. Дело не в объёме вычислений, а в количестве решений, которые нужно держать в голове за один заход.
Дробление решает это буквально: маленькие группы критериев (по 4–32 штуки) проверяются отдельными запросами с тем же полным контекстом. Каждый пункт действительно попадает в фокус внимания, а не угадывается. Против атак, где кто-то пытается «продавить» проверку убедительной подачей материала, дробление тоже защищает — а если атакующий убеждает модель по каждому пункту отдельно (не эксплуатируя перегрузку), добавляют «оппонента»: отдельный шаг, где модель ищет контраргумент против каждого «зачтено».
Схема метода
БАЗОВЫЙ ВАРИАНТ (Sharding):
ШАГ 1: Разбей чек-лист на группы по 4–32 пункта (отдельные запросы)
ШАГ 2: Каждой группе — отдельный запрос: полный текст документа + только эти пункты → вердикт "выполнено/не выполнено" + цитата-доказательство
ШАГ 3: Собери вердикты всех групп → сводный отчёт
УСИЛЕННЫЙ ВАРИАНТ (Sharding + Opposition) — для проверки материалов, где кто-то мог попытаться "продать" соответствие:
ШАГ 4: Для каждого пункта, отмеченного "выполнено" → отдельный запрос: "найди контраргумент, почему это НЕ выполнено"
ШАГ 5: Финальный запрос: сравни аргумент "за" и "против" по каждому пункту → вынеси окончательный вердикт
Шаги 1–3 требуют нескольких отдельных запросов (не один промпт). Шаги 4–5 — дополнительные запросы поверх базового шардинга.
Пример применения
Задача: Вы — предприниматель, проверяете договор поставки от подрядчика на соответствие 30 важным пунктам (сроки, штрафы, ответственность, форс-мажор, порядок оплаты). Обычно вы кидаете в ChatGPT весь договор и весь список пунктов сразу — и модель иногда пропускает риски, особенно если формулировки подрядчика звучат гладко и убедительно.
Промпт (запрос 1 из серии):
Вот полный текст договора:
{текст_договора}
Проверь ТОЛЬКО эти 5 пунктов чек-листа. Не отвлекайся на остальные, они будут проверены отдельно:
1. Указан точный срок поставки с датой
2. Прописана ответственность за просрочку (конкретная сумма/процент пени)
3. Есть пункт о порядке приёмки товара
4. Форс-мажор описан конкретно, а не общей фразой
5. Прописан порядок расторжения договора
Для каждого пункта:
— приведи точную цитату из договора, подтверждающую или опровергающую условие
— вынеси вердикт: выполнено / не выполнено / нет данных в тексте
Далее — ещё 5 таких запросов с оставшимися группами пунктов (по 5 в каждой), каждый раз с полным текстом договора.
Финальный запрос:
Собери все вердикты из предыдущих проверок в одну таблицу. Выдели красным пункты "не выполнено" и "нет данных" — это риски, требующие внимания перед подписанием.
Результат: Вместо одного общего ответа "договор в целом нормальный, пара мелочей" вы получите таблицу из 30 строк, где по каждому пункту — цитата из текста и чёткий вердикт. Пункты, где подрядчик использовал обтекаемые формулировки без конкретики, модель поймает — потому что в маленькой группе у неё физически есть внимание перебрать текст пункт за пунктом, а не бегло пробежать по всему документу разом.
Почему это работает
LLM не «сканирует» весь документ равномерно по каждому критерию — у неё ограниченное внимание на один запрос. Когда критериев много, часть решений принимается не по факту, а по общему впечатлению от текста: если документ выглядит аккуратным и убедительным, модель ставит «выполнено» без реальной проверки. Это системная ошибка в одну сторону — не случайный шум, а именно склонность пропускать нарушения, если их удачно "упаковали".
Сильная сторона модели — она отлично проверяет маленький набор конкретных пунктов против конкретного текста, если попросить процитировать доказательство перед вердиктом. На малой нагрузке точность резко выше.
Дробление использует эту сильную сторону: каждый запрос содержит мало пунктов — модель реально идёт по тексту и ищет цитату, а не угадывает. Рычаги управления: - Размер группы (4–32 пункта) — чем меньше группа, тем точнее, но дороже по времени/токенам. Для важных решений (юридические риски, крупные сделки) — группы поменьше (4–8). Для рутинной проверки — можно и по 20–30. - Требование цитаты перед вердиктом — заставляет модель реально искать доказательство, а не угадывать. - Шаг "оппонент" — добавляйте, когда проверяете материал от кого-то, у кого есть мотив вас убедить (отчёт подрядчика, самооценка сотрудника, коммерческое предложение). Для внутренней проверки своих же текстов он избыточен.
Шаблон промпта
Вот полный контекст/документ:
{текст_документа}
Проверь ТОЛЬКО эти пункты (остальные проверяются отдельно, не отвлекайся):
{группа_критериев}
Для каждого пункта из этой группы:
1. Приведи точную цитату из документа, подтверждающую или опровергающую условие
2. Вынеси вердикт: выполнено / не выполнено / нет данных в тексте
--- (повторить для каждой группы критериев) ---
Финальный запрос:
Собери вердикты всех групп в одну таблицу. Отдельно выделены пункты "не выполнено" и "нет данных".
--- (опционально, для проверки материалов с мотивом убедить вас) ---
Для каждого пункта, который отмечен "выполнено": найди контраргумент — почему на самом деле условие может быть НЕ выполнено. Сравни аргумент "за" и "против" с текстом документа и вынеси финальный вердикт.
Что подставлять: {текст_документа} — весь документ целиком (одинаковый в каждом запросе группы), {группа_критериев} — 4–10 пунктов чек-листа на один запрос.
🚀 Быстрый старт — вставь в чат:
Вот шаблон техники "дробление проверки" (sharding). Адаптируй под мою задачу: {твоя задача — проверка договора/отчёта/заявки/резюме против чек-листа}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит, сколько всего пунктов в вашем чек-листе и насколько важна точность (чтобы предложить размер группы), а также нужен ли шаг с "оппонентом" — потому что от этого зависит, сколько отдельных запросов нужно и стоит ли добавлять защиту от убеждающей подачи.
Ограничения
⚠️ Не помогает, если каждый пункт проверяется локально: если критерии не требуют целостного понимания всего документа (например, простые фактчеки без завязки друг на друга), дробление не даёт выигрыша — модель и так справляется.
⚠️ Не помогает, если хватает бюджета: если чек-лист короткий (условно, до 15–20 пунктов) и модель достаточно мощная — она справляется и без дробления. Дробление в этом случае просто увеличивает стоимость проверки без прироста точности.
⚠️ Дробление не защищает от точечного убеждения: если кто-то приводит убедительный отдельный аргумент по каждому пункту (не эксплуатируя перегрузку внимания) — дробление само по себе не спасает. Нужен дополнительный шаг с "оппонентом".
⚠️ Дороже и дольше: каждая группа критериев требует отдельного запроса с полным контекстом документа — это больше сообщений и токенов, чем один общий запрос.
Как исследовали
Команда из Карнеги-Меллона взяла три набора данных с реальными экспертными оценками: проверка научных отчётов (сотни критериев на документ), проверка юридических документов профессиональными юристами (контракты до 183 тысяч токенов), и оценка клинических испытаний по стандартным медицинским опросникам. Сравнивали четыре варианта: обычная проверка всех критериев за раз, та же проверка с увеличенным бюджетом (больше шагов размышления/токенов), проверка тем же бюджетом, но раздутая дублированием, и — дробление на маленькие группы.
Главный сюрприз: увеличение бюджета в одном запросе почти не помогало — точность оставалась на месте, а дробление на группы поднимало согласие с экспертами существенно, при том же суммарном бюджете. Слабый по капризности judge (модель) после дробления обгонял более мощную модель, работающую по старинке.
Отдельно проверили атаку: заставили одну модель генерировать несколько версий "презентации" одной и той же работы (аргументируя, что все критерии выполнены), и выбирали версию, которая лучше всего обманывала проверяющего. Против цельной проверки атака резко повышала долю ложно принятых нарушений (в разы). Дробление почти полностью закрывало эту дыру — кроме случая, когда атакующий убеждал по каждому пункту отдельно (а не эксплуатировал перегрузку). Против такой адаптивной атаки помог только дополнительный шаг с "оппонентом" — моделью, которая ищет контраргумент против каждого положительного вердикта.
Ресурсы
Sharding Prevents LLM Oversight Failures and Adversarial Exploitation. Victor Akinwande, J. Zico Kolter, Aran Nayebi — Carnegie Mellon University (preprint). Датасеты: PaperBench (JudgeEval), JudgmentBench, ROBoto2 (Cochrane RoB2).