3,583 papers
arXiv:2507.07847 75 10 июля 2025 г. FREE

Проблема: даёшь LLM длинный текст — получаешь путаные ответы.

КЛЮЧЕВАЯ СУТЬ
Проблема: даёшь LLM длинный текст — получаешь путаные ответы. Виноваты местоимения, а не модель. Метод кореференции позволяет убрать неоднозначные ссылки до того, как текст попадёт в обработку. Дело вот в чём: система с поиском по базе знаний режет документ на куски по 500-1000 слов. Фрагмент «Он основал SpaceX» приходит к модели без контекста — кто такой «Он»? Замени каждое местоимение на существительное прямо в исходнике — «он» станет «Илон Маск», «это решение» станет «решение об увольнении». Модель перестаёт гадать и начинает отвечать точно.
Адаптировать под запрос

Исследование показывает, что большие языковые модели часто ошибаются, когда в анализируемом тексте много местоимений ("он", "она", "это", "они") и отсылок, потому что модель путается, к какому объекту они относятся. Авторы доказывают, что если предварительно обработать текст, заменив все местоимения на конкретные существительные, которые они обозначают (например, "он" → "Илон Маск"), то точность поиска информации и качество ответов LLM значительно возрастают.

Ключевой результат: Устранение неоднозначности местоимений в исходном тексте — это эффективный способ повысить точность и надежность LLM, особенно в задачах, требующих анализа фактов.

Суть метода, который можно извлечь из исследования для практического применения, заключается в принципе максимальной явности (Explicitness Principle). LLM, особенно в системах с поиском по базе знаний (RAG), обрабатывают текст небольшими фрагментами (чанками). Если в одном фрагменте написано "Он основал компанию SpaceX", а в другом "Илон Маск — известный предприниматель", модель может не всегда уверенно связать "Он" и "Илон Маск".

Проблема усугубляется, когда в тексте несколько действующих лиц. Фраза "Билл Гейтс поговорил со Стивом Джобсом. Он был визионером" — абсолютно неоднозначна. Кто был визионером? Человек легко догадается из контекста, а для LLM это лотерея.

🔬

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

Анализ практической применимости:

  • Прямая применимость: Высокая для пользователей, работающих с анализом текста. Когда вы вставляете в чат статью, отчет, email-переписку или любой другой документ для анализа, суммаризации или извлечения фактов, вы можете (и должны) применить этот принцип. Вместо простого копирования-вставки, потратьте 1-2 минуты на то, чтобы заменить ключевые неоднозначные местоимения ("it", "they", "this finding") на конкретные термины ("the marketing campaign", "the sales team", "the finding that profits increased").

  • Концептуальная ценность: Огромная. Исследование дает пользователю четкую "ментальную модель" слабости LLM. Оно учит не воспринимать модель как всезнающего собеседника, а как мощный, но очень буквальный инструмент, который легко запутать неоднозначностью. Понимание этого помогает формулировать все промпты более четко, а не только при анализе текста.

* Потенциал для адаптации: Метод легко адаптируется. Вместо сложного скрипта, который использовали исследователи, пользователь может сделать это вручную. Более продвинутый способ — попросить саму LLM сделать это первым шагом: "Сначала перепиши этот текст, заменив все местоимения на существительные, к которым они относятся. Затем выполни мой основной запрос на основе исправленного текста".

Практически пример применения:

Представим, что менеджер по продукту хочет проанализировать отзывы пользователей, чтобы составить план улучшений.

Ты — опытный менеджер по продукту. Твоя задача — проанализировать отзывы пользователей о нашем приложении "PhotoMagic" и составить краткий план действий для команды разработки.

**Контекст (отзывы пользователей с разрешенными кореференциями):**

---
**Отзыв 1:** "Я скачал приложение **PhotoMagic** вчера. **PhotoMagic** работает быстро, но интерфейс показался мне запутанным. Особенно сложно было найти функцию ретуши. **Эта функция** (ретушь) спрятана слишком глубоко в меню."

**Отзыв 2:** "Мой друг посоветовал **PhotoMagic**, и я решил попробовать. **Приложение** (PhotoMagic) отлично справляется с цветокоррекцией. Однако, после последнего обновления **PhotoMagic** стало часто вылетать на моем старом телефоне. **Это вылетание** происходит при сохранении фото."

**Отзыв 3:** "Использую **PhotoMagic** для работы. Платная подписка стоит своих денег. **Подписка** открывает доступ к облачному хранилищу. **Оно** (облачное хранилище) очень удобное, но хотелось бы больше бесплатного места."
---

**Задание:**
На основе этих отзывов, создай таблицу из трех колонок:
1.  **Проблема:** Краткое описание проблемы, с которой столкнулся пользователь.
2.  **Источник:** Из какого отзыва (1, 2 или 3) взята проблема.
3.  **Предлагаемое решение:** Конкретное действие для команды разработки.

Почему это работает:

Этот промпт эффективен, потому что он полностью устраняет когнитивную нагрузку на LLM по разрешению ссылок.

  • Механика 1 (Явное именование): Вместо "оно", "приложение", "он" в каждом отзыве явно указано "PhotoMagic". Это гарантирует, что модель не перепутает свойства приложения с чем-то другим.
  • Механика 2 (Разрешение неоднозначности действия): Фраза "Это происходит при сохранении" заменена на "Это вылетание происходит при сохранении". Теперь причина и следствие четко связаны.
  • Механика 3 (Уточнение в скобках): Вместо "Оно очень удобное" написано "Оно (облачное хранилище) очень удобное". Это прямой способ указать модели, к чему относится местоимение, сохраняя при этом естественность речи.
📌

В результате LLM получает набор четких, атомарных фактов, из которых легко извлечь проблемы и сгенерировать точные, релевантные решения, не рискуя приписать вылетание облачному хранилищу или запутанный интерфейс — подписке.

Другой пример практического применения

Сценарий: студент пишет реферат по истории и просит LLM помочь составить хронологию событий на основе отрывка из учебника.

Ты — ассистент по истории. Помоги мне составить хронологию ключевых событий в карьере Наполеона Бонапарта на основе предоставленного текста.

**Контекст (отрывок из учебника с разрешенными кореференциями):**

---
"Наполеон Бонапарт пришел к власти в результате переворота 18 брюмера (9 ноября 1799 года). **Этот переворот** установил режим консульства. В 1804 году **Наполеон** провозгласил себя императором. **Это событие** (провозглашение себя императором) ознаменовало конец Французской республики и начало Первой империи.

Одним из главных достижений **Наполеона** было создание Гражданского кодекса в 1804 году. **Этот кодекс** (Гражданский кодекс) закрепил многие завоевания революции. Однако внешняя политика **Наполеона** была агрессивной. **Его** (Наполеона) вторжение в Россию в 1812 году стало катастрофой. **Это вторжение** (в Россию) привело к огромным потерям в Великой армии и стало началом конца **его** (Наполеона) правления."
---

**Задание:**
Представь информацию в виде списка, где каждый пункт — это дата (или год) и ключевое событие, связанное с Наполеоном.

Объяснение механизма почему этот пример работает.

Этот промпт работает за счет превентивного устранения любой двусмысленности в историческом тексте, который часто изобилует ссылками на личности и события.

  • Механика 1 (Четкая привязка к субъекту): Вместо "Его вторжение" используется "Его (Наполеона) вторжение". Это исключает любую возможность, что модель припишет вторжение кому-то другому, кто мог бы упоминаться в более широком контексте (например, русскому императору).
  • Механика 2 (Конкретизация событий): Абстрактные фразы вроде "Это событие" или "Этот переворот" немедленно расшифровываются в скобках: "Это событие (провозглашение себя императором)". Модель получает не просто ссылку, а конкретный факт, который легко поместить на временную шкалу.
  • Механика 3 (Повторение имен собственных): Вместо того чтобы полагаться на понимание моделью контекста, имя "Наполеон" повторяется там, где в оригинальном тексте могло бы стоять "он" или "император".

В результате LLM не тратит ресурсы на интерпретацию и не рискует ошибиться. Модель получает "очищенные" данные, готовые к структурированию, что ведет к созданию точной и фактически верной хронологии.

Оценка полезности: 75

📌

Основные критерии оценки

  • Предварительный фильтр: Исследование полностью сфокусировано на обработке текстовых данных, промптах для разрешения кореференций и улучшении RAG-систем. Фильтр пройден.
  • A. Релевантность техникам промтинга: Да, исследование предоставляет конкретный шаблон промпта (Table 5) для выполнения задачи разрешения кореференций. Хотя это и является техникой предварительной обработки данных, а не прямым промптом для конечной задачи, это все равно ценный паттерн.
  • B. Улучшение качества диалоговых ответов: Да, исследование напрямую демонстрирует улучшение качества ответов на вопросы (QA tasks) после применения метода (Table 2).
  • C. Прямая практическая применимость: Применимость для обычного пользователя непрямая, но возможная. Пользователь не может изменить бэкенд RAG-системы, но может применить принцип разрешения кореференций к контексту, который он сам подает в промпте (например, при анализе вставленного текста). Это требует дополнительных усилий, но выполнимо без кода.
  • D. Концептуальная ценность: Очень высокая. Исследование блестяще объясняет одну из фундаментальных причин, почему LLM "тупят" при работе с длинными текстами — неоднозначность местоимений и ссылок (кореферентная сложность). Это дает пользователю ключевое понимание: "LLM не всегда понимает, к чему относится 'он', 'она' или 'это'".
  • E. Новая полезная практика (кластеры): Работа попадает в несколько кластеров:
    • Кластер 2 (Поведенческие закономерности LLM): Раскрывает, как неоднозначность ссылок ухудшает понимание контекста.
    • Кластер 6 (Контекст и память): Предлагает конкретный метод улучшения качества контекста, подаваемого в модель.
    • Кластер 7 (Надежность и стабильность): Метод напрямую нацелен на снижение ошибок и повышение фактической точности ответов.
  • Чек-лист практичности (+15 баллов):
    • Дает готовые фразы/конструкции для промптов? (Да, для задачи разрешения кореференций).
    • Раскрывает неочевидные особенности поведения LLM? (Да, уязвимость к неоднозначности местоимений).
    • Предлагает способы улучшить consistency/точность ответов? (Да, это основная цель исследования).
    • Итог: Получает бонус +15 баллов.
📌

Цифровая оценка полезности

Изначально работа могла бы получить около 60-65 баллов, так как ее основной фокус — улучшение RAG-систем, что является задачей для разработчиков. Однако концептуальная ценность для пользователя огромна, а сам принцип легко адаптируется для ручного применения. С учетом бонуса за практичность (+15), итоговая оценка 75 является справедливой.

Контраргументы: * Почему оценка могла быть выше? Для продвинутых пользователей (аналитиков, юристов, исследователей), которые постоянно работают с анализом больших объемов текста в чате, этот инсайт — чистое золото. Понимание необходимости "разжевывать" для LLM ссылки в тексте может кардинально повысить качество их работы. Для этой аудитории ценность приближается к 85-90 баллам. * Почему оценка могла быть ниже? Для казуального пользователя, который задает LLM простые бытовые вопросы, исследование почти бесполезно. Оно требует осознанных усилий по редактированию текста, что выходит за рамки обычного взаимодействия. С этой точки зрения, оценка могла бы быть и 50-60.

📌

Оценка 75 — это компромисс, который высоко оценивает прорывную концептуальную ясность и возможность применения для всех, кто работает с анализом текста, но учитывает, что это не "простой трюк" для всех подряд.

📋 Дайджест исследования

Ключевая суть

Проблема: даёшь LLM длинный текст — получаешь путаные ответы. Виноваты местоимения, а не модель. Метод кореференции позволяет убрать неоднозначные ссылки до того, как текст попадёт в обработку. Дело вот в чём: система с поиском по базе знаний режет документ на куски по 500-1000 слов. Фрагмент «Он основал SpaceX» приходит к модели без контекста — кто такой «Он»? Замени каждое местоимение на существительное прямо в исходнике — «он» станет «Илон Маск», «это решение» станет «решение об увольнении». Модель перестаёт гадать и начинает отвечать точно.

Принцип работы

Система с поиском по базе знаний не читает документ целиком. Она режет его на куски и обрабатывает каждый отдельно. Местоимение «Он» во фрагменте 3 ссылается на имя из фрагмента 1 — и модель их не видит вместе. Замена местоимений — это как поставить таблички с именами на каждый стул перед конференцией. Больше не нужно угадывать кто есть кто. Каждый фрагмент становится самодостаточным. Дополнительный трюк: не хочется делать это вручную — попроси саму LLM сделать очистку первым шагом, а уже потом выполнить основной запрос.

Почему работает

«Билл Гейтс поговорил со Стивом Джобсом. Он был визионером» — человек догадывается из контекста. Для модели, которая видит только этот фрагмент — лотерея. Кореференция убирает лотерею: каждый факт несёт имя своего владельца прямо в теле фрагмента. Модель не тратит ресурсы на интерпретацию — и тратит их на ответ. Особенно критично там, где несколько действующих лиц или несколько событий идут подряд: контракты, протоколы, переписка, исторические тексты.

Когда применять

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

Мини-рецепт

1. Найди местоимения: пробегись по тексту и подчеркни все «он», «она», «оно», «они», «это», «то», «которое». Особое внимание — когда рядом несколько персонажей или объектов.
2. Замени вручную: «Он основал SpaceX» → «Илон Маск основал SpaceX». «Это решение» → «решение о смене поставщика». Ключевые факты — в первую очередь.
3. Уточни в скобках там, где переписывать неудобно: «Оно (облачное хранилище) работает быстро» — быстро и без потери читаемости.
4. Автоматизируй через саму LLM: сначала отправь запрос Перепиши текст, заменив все местоимения на существительные, к которым они относятся: [вставь текст]. Дождись результата. Потом задай основной вопрос уже по очищенному тексту.

Примеры

[ПЛОХО] : Проанализируй отзывы и скажи что улучшить в приложении [вставить сырой текст с «оно», «это», «он улучшил», «она пожаловалась»] — модель будет путаться чьи жалобы, про что «оно» и что именно улучшил «он».
[ХОРОШО] : Два шага. Шаг 1: Перепиши этот текст, заменив каждое местоимение на существительное, к которому оно относится. Текст: [вставить оригинал]. Шаг 2 (на основе очищенного текста): Теперь выдели три главные проблемы с приложением PhotoMagic из отзывов и предложи конкретное действие команды разработки для каждой
Источник: From Ambiguity to Accuracy: The Transformative Effect of Coreference Resolution on Retrieval-Augmented Generation systems
ArXiv ID: 2507.07847 | Сгенерировано: 2026-03-02 16:57

Проблемы LLM

ПроблемаСутьКак обойти
Местоимения в тексте путают модельКогда анализируешь длинный текст, модель обрабатывает его по кускам. Местоимение "он" в одном куске может потерять связь с именем из другого куска. Особенно плохо когда в тексте несколько персонажей: "Билл поговорил с Джоном. Он был прав" — модель угадывает кто прав. Это касается любого анализа: статьи, переписки, отчёта, учебникаПеред подачей текста замени ключевые местоимения на существительные. "Он основал компанию" "Маск основал компанию". Можно добавить уточнение в скобках прямо в тексте: "Оно (облачное хранилище) удобное"

Методы

МетодСуть
Двухшаговый анализ — сначала очисти, потом анализируйПопроси модель выполнить два шага последовательно. Шаг 1: "Перепиши этот текст, заменив все местоимения на существительные, к которым они относятся." Шаг 2: "Теперь выполни основное задание на основе исправленного текста." Почему работает: Модель сама устраняет неоднозначность до того как начинает думать по существу. Не путает факты с источниками. Когда применять: текст длиннее 3-4 абзацев, несколько действующих лиц, нужно извлечь факты точно. Когда не нужно: короткий текст с одним субъектом — лишний шаг
📖 Простыми словами

От неоднозначности к точности: преобразующий эффект разрешения кореференции на системы генерации с дополненным поиском

arXiv: 2507.07847

Суть проблемы в том, что AI, несмотря на всю свою мощь, часто тупит на уровне пятиклассника, когда встречает в тексте местоимения. Для нас «он», «это» или «тот самый случай» — очевидные вещи, но для RAG-систем это превращается в кашу. Когда база знаний нарезается на куски, связь между «Иваном Ивановичем» в первом абзаце и «им» в пятом теряется. В итоге модель выдергивает кусок текста, где написано, что «он совершил ошибку», и гадает на кофейной гуще, о ком вообще речь. Разрешение кореференций (Coreference Resolution) — это процесс, который заменяет все эти мутные «он/она/они» на конкретные имена и названия еще до того, как данные попадут в нейронку.

Это как если бы ты пришел в поликлинику, а там все медкарты разрезаны на конфетти. На одном клочке написано «назначить лечение», а на другом — «пациент Сидоров». Без клея и контекста врач просто выпишет таблетки пустоте. Coreference Resolution — это тот самый клей, который подписывает каждый клочок бумаги именем пациента. Формально данные те же, но теперь системе не нужно играть в Шерлока Холмса, чтобы понять, к чему относится конкретный глагол.

Возьмем реальный кейс: менеджер по продукту анализирует гору отзывов. В одном написано: «Приложение крутое, но оно постоянно вылетает при загрузке фото». Если просто скормить это поиску, слово «оно» ничего не значит. Метод Coreference Resolution переписывает это в: «Приложение крутое, но [Приложение] постоянно вылетает». Теперь, когда ты спросишь AI: «Какие проблемы у приложения?», он мгновенно найдет ответ, потому что связь между объектом и проблемой зафиксирована жестко и без двусмысленностей. Точность ответов в таких сценариях взлетает, потому что мы убираем когнитивную нагрузку с модели — ей больше не нужно додумывать контекст.

Хотя исследование гоняли на отзывах и документации, принцип универсален для любой работы с большими данными. Это критично для юристов, анализирующих договоры на 100 страниц, или для техподдержки, где в логах «ошибка в этом модуле» встречается чаще, чем название самого модуля. Везде, где есть длинные цепочки рассуждений и куча местоимений, замена ссылок на сущности превращает бесполезный шум в структурированную базу знаний. RAG без кореференции — это лотерея, с ней — точный инструмент.

Короче: если хочешь, чтобы твой AI перестал галлюцинировать и путать персонажей, не надейся на его «сообразительность». Нужно чистить входные данные и явно прописывать, кто на ком стоял. Точность извлечения информации напрямую зависит от того, насколько однозначно написан текст. Либо ты тратишь ресурсы на предобработку текста, либо получаешь ответы в стиле «кто-то что-то сделал, но это неточно». Кто внедрит этот этап в свой пайплайн, получит работающий инструмент, остальные продолжат жаловаться на «тупость» нейросетей.

Работа с исследованием

Адаптируйте исследование под ваши задачи или создайте готовый промпт на основе техник из исследования.

0 / 2000
~0.5-2 N-токенов ~10-30с
~0.3-1 N-токенов ~5-15с