Коротко: ИИ-аналитик может точно найти риск в длинном документе и процитировать его, но почти не изменить итоговую рекомендацию. Новое исследование финансовых отчётов на контекстах от 2 000 до 128 000 токенов называет это разрывом между извлечением и интеграцией. Поэтому приёмка системы должна проверять не только retrieval и ссылки, но и чувствительность решения к существенному факту: если факт добавить, удалить или усилить, вывод должен измениться в ожидаемую сторону и соразмерно риску.
Статья предназначена для руководителей, финансовых и риск-функций, владельцев документных процессов, команд RAG и AI-инженеров. Мы разбираем исследование от 25 августа 2026 года и проектирование пилота. Это не инвестиционная, бухгалтерская или юридическая рекомендация. Результаты эксперимента не доказывают частоту ошибки в конкретной компании и не переносятся автоматически с американских форм 10-K на договоры, закупки или российскую отчётность.
Содержание
- Что обнаружило новое исследование
- Что такое разрыв между извлечением и интеграцией
- Как был устроен эксперимент
- Какие результаты получены
- Почему цитата ещё не доказывает анализ
- Почему длинный контекст не является гарантией
- Какая архитектура сработала
- Метод СДВИГ для проверки ИИ-аналитика
- Как провести пилот на документах компании
- Какие метрики считать
- Когда нужен человек
- Ограничения исследования
- Источники
- Частые вопросы
- Как AI рассвет помогает проверить документный ИИ
- Вывод
Что обнаружило новое исследование
25 августа 2026 года Miao Liu и Zhizhe Liu опубликовали предварительную работу Reading Is Not Using. Авторы разделили две способности ИИ-аналитика: найти конкретное раскрытие риска в документе и использовать этот риск при инвестиционном суждении.
Главный результат неудобен для обычной приёмки RAG. На длинном документе модель могла назвать порог ковенанта, сумму урегулирования и последствия нарушения, но её рекомендация почти не реагировала на те же факты. Иначе говоря, правильный ответ на вопрос «что написано?» не гарантировал правильную реакцию на вопрос «что из этого следует?».
Это развивает более общий результат рецензированной работы Context Length Alone Hurts LLM Performance Despite Perfect Retrieval. В ней на пяти открытых и закрытых моделях, задачах математики, вопросов-ответов и кода производительность снижалась на 13,9–85% с ростом входа даже при идеальном retrieval. Новая работа переносит проблему из лабораторной точности в область веса, который ИИ придаёт факту в решении.
Что такое разрыв между извлечением и интеграцией
Разрыв между извлечением и интеграцией — ситуация, когда система способна корректно извлечь релевантный факт, но этот факт слабо влияет или не влияет на итоговое суждение. Retrieval отвечает на вопрос «нашли ли доказательство?», а integration — «изменило ли оно решение?».
| Уровень проверки | Вопрос | Что подтверждает | Чего не подтверждает |
|---|---|---|---|
| Retrieval | Нашла ли модель нужный фрагмент? | доступность факта для прямого вопроса | что факт участвовал в выводе |
| Grounding | Есть ли цитата и соответствует ли она источнику? | прослеживаемость ответа до документа | правильный вес факта |
| Judgment direction | Изменился ли вывод в ожидаемую сторону? | направленная чувствительность решения | достаточную величину изменения |
| Judgment magnitude | Соразмерно ли изменился вывод силе факта? | калибровку реакции в тестовом сценарии | правильность реального бизнес-решения |
| Outcome | Помогло ли решение процессу? | наблюдаемый эффект в заданном пилоте | универсальную пользу в других условиях |
Поэтому отчёт retrieval accuracy = 100% может быть правдивым и при этом недостаточным. Он измеряет промежуточную операцию, а не делегированную цель.
Как был устроен эксперимент
Основной дизайн использовал годовые отчёты 12 американских регистрантов. Для каждой компании исследователи создали количественно проверяемое раскрытие риска: например, порог обязательства, платёж по урегулированию или предел возмещения. У каждого целевого абзаца было пять нейтральных замен той же длины.
Авторы меняли только экономически нерелевантный окружающий текст, расширяя контекст до 2 000, 8 000, 32 000 и 128 000 токенов. Существенная информация о выбранной компании оставалась фиксированной. Влияние рассчитывали как разницу между суждением при наличии риска и средним суждением для пяти нейтральных замен.
Чтобы обычная вставка абзаца не выглядела влиянием, исследователи дополнительно использовали по 10 псевдо-вставок без значимого содержания и строили эмпирический шумовой фон. Retrieval проверяли отдельным вызовом по заранее замороженным ключам ответа. Так авторы не смешивали способность процитировать факт с его причинным вкладом в суждение.
Отдельные проверки включали три семейства моделей, лестницу из семи уровней тяжести риска и 20 реальных раскрытий из фактических 10-K, где исходный фрагмент хирургически удаляли. Последняя часть названа авторами exploratory и capability-conditional, а не универсальным подтверждением.
Какие результаты получены
| Наблюдение | Короткий контекст | Длинный контекст | Граница вывода |
|---|---|---|---|
| Влияние риска у основной 9B-модели | +3,2 п.п. sell probability при 2k | +0,4 п.п. при 128k; неотличимо от нерелевантной вставки | конкретная модель и экспериментальный readout |
| Retrieval основной модели | 12/12 компаний при 2k | 12/12 при 128k, без ложных срабатываний на нейтральных файлах | прямой вопрос по замороженному ключу |
| Диапазон реакции на 7 уровней риска | 0,23 | 0,04 | сжатие в 5,6 раза |
| Попарное упорядочивание тяжести | 0,93 | 0,79 | порядок сохранился лучше, чем масштаб реакции |
| Реальные раскрытия | эффект +0,042 для 16 явно негативных фрагментов | около 0 в полном документе; retrieval 20/20 | exploratory, наиболее способная open-weight модель |
| Более крупная open-weight модель | +0,105 при 2k | +0,034 при 128k | способность отодвинула, но не убрала границу |
Для production API-модели риск повышал заявленную вероятность дефолта на 6,06 п.п. при 2 000 токенов и на 3,15 п.п. при 128 000. На полном контексте эффект оставался отличим от нуля, но уже не был статистически отличим от шума нерелевантной вставки. Авторы отдельно подчёркивают: это две разные проверки, и слабый результат против шумового контроля нельзя превращать в абсолютный «ноль».
Самый практичный паттерн — разделение порядка и масштаба. На 128 000 токенов модель всё ещё чаще понимала, какой риск хуже, но почти переставала масштабировать рекомендацию по его тяжести. Для бизнеса это означает возможность получить правдоподобно ранжированный, но экономически сплющенный вывод.
Почему цитата ещё не доказывает анализ
Цитата решает важную задачу: позволяет человеку открыть первоисточник и проверить, не выдумала ли модель факт. Но она не показывает внутренний или системный вес доказательства. Один и тот же фрагмент может быть процитирован в объяснении и почти не изменить score, recommendation или выбранное действие.
Особенно опасны четыре ложных перехода:
Фрагмент найден → документ понят.Retrieval может быть точным только для явно названного вопроса.Фрагмент процитирован → факт учтён.Источник виден, причинная чувствительность не измерена.Риски перечислены → они взвешены.Модель может правильно упорядочить риски и сжать различия между ними.Ответ выглядит разумно → процесс надёжен.Правдоподобие не заменяет тест на изменённом входе.
Поэтому архитектура RAG для бизнеса должна иметь отдельные evals для retrieval и финального решения. Один агрегированный score скрывает, на каком этапе произошла ошибка.
Почему длинный контекст не является гарантией
Контекстное окно описывает максимальный объём, который модель технически принимает при заданных условиях. Оно не обещает, что каждый факт сохранит одинаковое влияние на итоговый вывод.
В исследовании более способные модели удерживали влияние глубже, но не становились доказанно неуязвимыми. У самой крупной open-weight модели эффект на 128k был примерно равен эффекту средней модели на 2k. Один дешёвый коммерческий вариант на длинном входе потерял и часть retrieval: с 12/12 до 7/12, тогда как влияние сократилось ещё сильнее.
Практическая формулировка:
Заявленное окно контекста — лимит входа, а не сертификат эффективного контекста решения.
Добавление reasoning budget тоже не стало универсальным исправлением. В протестированных режимах extended reasoning не восстановил влияние на 128k, а на коротком контексте даже снизил его. Это не доказывает, что рассуждение никогда не помогает; оно показывает, что в данном эксперименте вычисление не заменило правильную маршрутизацию доказательства.
Какая архитектура сработала
Авторы сравнили несколько способов донести риск до решения. Результат зависит не только от модели и документа, но и от формы промежуточного представления.
| Workflow | Что делает | Результат в исследовании | Практический риск |
|---|---|---|---|
| Прямое чтение | весь документ сразу перед решением | влияние затухает с длиной | найденный факт теряет вес |
| Chunk-and-summarize | каждый chunk сжимается, затем сводки объединяются | целевой факт часто исчезал из notes; влияние не восстановилось | eviction из-за ограниченного бюджета summary |
| Повтор raw-фрагмента | исходный абзац ставится перед вопросом | восстановил мало | близость без структуры недостаточна |
| Targeted extract-then-decide | отвечает на конкретный вопрос о риске, структурирует факт и ставит его рядом с решением, сохраняя исходник | восстановил влияние лучше других вариантов | качество зависит от вопроса и fidelity extraction |
В полном искусственном контексте targeted restatement поднял влияние до 8,5 п.п., и все 12/12 компаний сдвинулись в ожидаемую сторону. На 12 полных реальных отчётах этот workflow дал +0,043 с 11/12 ожидаемых направлений, тогда как direct reading был около нуля. Экспериментаторская структурированная выжимка работала не хуже self-extraction при сопоставимой форме, поэтому польза не требовала «интроспекции» той же модели.
Но нельзя упростить результат до «сделайте summary». Generic summary в этой работе как раз удалял существенный риск. Полезен был целевой структурированный restatement под конкретное решение, размещённый рядом с точкой решения при сохранении исходного документа для проверки.
Метод СДВИГ для проверки ИИ-аналитика
СДВИГ — практический контрфактуальный тест, который проверяет не красоту ответа, а причинную связь между доказательством и выводом.
| Шаг | Вопрос | Артефакт |
|---|---|---|
| С — Сценарий | Какое конкретное решение поддерживает система? | decision statement, владелец, допустимые действия |
| Д — Доказательство | Какие факты обязаны повлиять на решение и почему? | evidence matrix с источником, версией и ожидаемым направлением |
| В — Вариация | Что изменится, если факт удалить, заменить нейтральным или усилить? | парные counterfactual cases без изменения остального контекста |
| И — Изменение | Сдвинулся ли вывод в правильную сторону и величину? | direction, magnitude, confidence/abstention и citation diff |
| Г — Граница | Когда система должна остановиться или передать человеку? | acceptance threshold, escalation, audit record и stop condition |
Метод не требует знать скрытые рассуждения модели. Он рассматривает систему как объект испытания: меняет один существенный вход и наблюдает итоговый output или действие. Это ближе к проверке бизнес-функции, чем вопрос «найди пункт 7.3».
Как провести пилот на документах компании
1. Выберите одно решение
Не начинайте с задачи «анализировать все документы». Возьмите один bounded outcome: выделить договоры для обязательной юридической проверки, сформировать черновик риск-класса или подготовить список исключений для аналитика. Зафиксируйте текущий baseline и владельца решения.
2. Заморозьте корпус и ответы
Соберите разрешённые исторические или синтетические кейсы, версии документов и эталонные существенные факты. Размер набора выбирает команда по риску и разнообразию; универсального числа исследование не даёт.
3. Постройте пары
Для каждого критического факта создайте исходный и контролируемо изменённый вариант: удаление, нейтральная замена, усиление или ослабление. Остальные decision-relevant сведения должны оставаться одинаковыми. Иначе сдвиг нельзя приписать выбранному факту.
4. Разведите четыре оценки
Отдельно измеряйте retrieval, соответствие цитаты источнику, направление решения и величину изменения. Не усредняйте их в один балл до разбора ошибок.
5. Сравните workflow
Запустите те же пары через direct long context, текущий RAG, generic summarization и targeted structured extraction. Сохраняйте версии модели, prompt, retriever, reranker, chunking, tool graph и шаблон решения.
6. Проверьте длинные и плотные случаи
Добавляйте только контролируемый нерелевантный или жанрово сходный контекст. Отдельно проверяйте конфликты документов, таблицы, OCR, поздние приложения и обновлённые версии. Эти сценарии не были полностью покрыты новой работой, но критичны для реального document workflow.
7. Подключите доменного эксперта
Эксперт подтверждает не стилистику, а ожидаемое направление, существенность, допустимую величину и случаи, где однозначного ответа нет. Спорные пары маркируйте как requires review, а не заставляйте модель угадывать.
8. Запустите shadow mode
ИИ формирует вывод рядом с действующим процессом, но не инициирует необратимое действие. После frozen eval сравнивайте расхождения, overrides и пропущенные существенные факты. Архитектуру длительных задач и независимую проверку результата подробнее разбирает материал об асинхронных ИИ-агентах.
Какие метрики считать
| Метрика | Формула или правило | Что показывает |
|---|---|---|
| Retrieval accuracy | правильно извлечённые факты / проверенные факты | находит ли система доказательство |
| Citation fidelity | цитаты, соответствующие источнику / проверенные цитаты | не искажает ли она источник |
| Directional sensitivity | пары с ожидаемым направлением / валидные counterfactual pairs | реагирует ли решение правильно |
| Magnitude calibration | отклонение фактического сдвига от утверждённой шкалы | не сплющивает ли система тяжесть |
| Evidence survival | критические факты, дошедшие до decision representation / обязательные факты | где summary/RAG теряет сигнал |
| Unsupported movement | сдвиги на нейтральных заменах / neutral controls | насколько сам pipeline создаёт шум |
| Abstention adequacy | корректные requires review / неоднозначные случаи |
умеет ли система не решать лишнее |
| Human override rate | существенные правки / проверенные решения | где человек не принимает вывод |
Порог каждой метрики утверждает владелец процесса вместе с доменным экспертом, risk/compliance и технической командой. Исследование не задаёт универсальный pass rate и не позволяет обещать финансовый эффект.
NIST AI RMF Core рекомендует документировать тестовые наборы, метрики и условия, похожие на deployment, а также контролировать поведение системы в production. Опубликованный 7 августа 2026 года проект TEVV-Athlon также ориентирован на реальное воздействие и outcomes, а не на один удобный proxy. Эти документы добровольны и не сертифицируют конкретный ИИ-аналитик.
Когда нужен человек
Human review нужен не потому, что «ИИ всегда плох», а потому что цена ошибки, обратимость и полномочия различаются. Человек должен подтверждать вывод или действие, когда:
- решение влияет на деньги, права, обязательства, доступ или отчётность;
- документ содержит конфликтующие версии или неоднозначную норму;
- критический факт найден, но causal test показывает слабую или нестабильную реакцию;
- действие необратимо либо выходит за утверждённый порог;
- evidence survival, citation fidelity или directional sensitivity не проходят локальную границу;
- модель не умеет корректно отказаться.
Для финансового сектора Банк России 16 июня 2026 года рекомендовал подтверждение сотрудником для операций в критически важных процессах с высоким риском информационной безопасности, включая платёжные операции. Это конкретная рекомендация регулятора по ИБ, а не универсальное правило для всех document assistants; компания должна определить применимость со своими ответственными функциями.
Ограничения исследования
Работа Reading Is Not Using — very preliminary draft, опубликованный как arXiv v1. Авторы планируют выложить replication package примерно в конце сентября; на дату статьи он ещё не доступен. Основной дизайн использует 12 американских компаний и исследовательские раскрытия, а эксперимент с 20 реальными раскрытиями назван exploratory.
Поведенческий разрыв повторился в нескольких семействах моделей, но причинный анализ каналов выполнен на одной гибридной архитектуре. Модели, prompts, числовые readouts и контекстные режимы ограничивают переносимость. Одна post-trained 9B-модель показала необъяснённую зависимость знака эффекта от размещения документа; авторы не скрывают эту аномалию.
Исследование относится к финансовым раскрытиям и investment judgment. Перенос метода на договоры, тендеры, страховые дела или compliance — наша инженерная гипотеза, основанная на общей структуре «доказательство → решение», а не измеренный результат статьи. Не установлены production prevalence, влияние на пользователей, стоимость, latency, ROI, российская правовая применимость или эффект для конкретной компании.
Search volume, keyword difficulty, rankings, трафик, CTR, backlinks и AI citations этой страницы — Unknown.
Источники
- Miao Liu, Zhizhe Liu. Reading Is Not Using: Retrieval, Judgment, and the Design of AI Financial Research Workflows, arXiv v1, 25.08.2026.
- Yufeng Du et al. Context Length Alone Hurts LLM Performance Despite Perfect Retrieval, Findings of EMNLP 2025.
- NIST. AI RMF Core: Measure, observed 26.08.2026.
- NIST. The TEVV-Athlon Framework for Evaluating AI Systems, initial public draft announcement, 07.08.2026.
- Банк России. Рекомендации по безопасному использованию искусственного интеллекта в финансовой сфере, 16.06.2026.
Частые вопросы
Если ИИ правильно процитировал документ, можно ли доверять выводу?
Цитата подтверждает, что источник доступен для проверки, но не показывает, насколько факт повлиял на вывод. Для consequential use нужен парный тест: изменить один существенный факт и проверить направление и величину сдвига решения.
Решает ли проблему большое контекстное окно?
Не гарантированно. В исследовании способность модели отодвигала границу, но влияние факта всё равно снижалось с длиной. Заявленный context window — лимит входа, а не доказательство равного использования всех фактов.
Поможет ли обычное chunk-and-summarize?
В протестированной реализации generic summary работал хуже: критический риск выпадал из ограниченных notes до стадии решения. Это не означает, что любая суммаризация вредна; summary нужно проверять на evidence survival и проектировать под конкретный decision question.
Чем targeted extraction отличается от RAG?
RAG ищет релевантные фрагменты. Targeted extraction дополнительно превращает факты в структурированное представление под конкретное решение и ставит его рядом с decision step, сохраняя ссылку на источник. Эти слои могут работать вместе.
Как проверить ИИ без доступа к chain of thought?
Используйте counterfactual pairs: меняйте один существенный факт, сохраняйте остальное и измеряйте сдвиг output. Метод проверяет наблюдаемое поведение системы и не требует скрытых рассуждений.
Какой первый тест провести компании?
Выберите одно решение и один класс документов, зафиксируйте baseline, обязательные факты и stop condition. Создайте несколько валидированных пар с изменённым фактом, сравните retrieval, citation fidelity и decision sensitivity в shadow mode.
Как AI рассвет помогает проверить документный ИИ
AI рассвет может связать анализ документов с проверяемым бизнес-решением:
- обследовать процесс, источники, текущий baseline, права и точки человеческого подтверждения;
- спроектировать корпоративную базу знаний или RAG с целевым извлечением и прослеживаемостью до версии документа;
- собрать MVP ИИ-агента или AI-workspace со структурированным decision step, журналом и эскалацией;
- подготовить frozen eval по методу СДВИГ, интегрировать систему, провести тестирование, запуск, обучение команды и поддержку.
Безопасный первый шаг — выбрать один процесс, его baseline, источники, ограничения и критерий приёмки. Затем проверить в shadow mode, меняется ли решение при контролируемом изменении существенного факта. Обсудить задачу.
Вывод
ИИ-аналитик документов нельзя принимать только по поиску, цитатам и красивому summary. Эти признаки показывают, что система читает и объясняет, но не доказывают, что существенный факт получил правильный вес в решении.
Проверяйте полный путь: источник → retrieval → структурированное доказательство → decision → human/action. Метод СДВИГ добавляет недостающий counterfactual: если факт изменился, вывод тоже должен измениться в ожидаемую сторону, а на критической границе — остановиться и передать решение человеку.