Всем привет! Меня зовут Наталья Бруй, я промпт-инженер в MWS AI. Вместе с моей коллегой  Анастасией Тищенковой мы решили ответить на вопрос, который мучает нашего пиарщика многих — почему больше токенов не равно лучше и как заставить LLM работать адекватно на длинном контексте. 

Если вы создаете ИИ-решения для работы с большим объемом документов и хотите, чтобы LLM вам в этом помогала ( отвечала на вопросы по содержанию, генерировала запросы и заявления на их основе, делала резюме и и пр.) не абы как, а опираясь на выданные ей данные, тогда эта статья вам может пригодиться. 

Оговорочка: эта статья для тех, кто находится на первых этапах освоения темы работы с длинным контекстом и вовлечен в создание каких-нибудь новых ИИ-продуктов на основе языковых моделей. Если вы уже две диссертации об этом написали, тогда можете сразу в комментариях ссылки оставить — мы почитаем. 

Введение в контекст для тех, кто не в контексте

Контекст — это входные данные, которые пользователь передаёт модели. Эти данные модель до этого «не видела», то есть они не использовались при ее обучении. LLM перерабатывает их и после уже может применять для ответов на вопросы. 

Раньше модели работали с ограничением контекста. Так, GPT-2 умел обрабатывать лишь до 1 024 токенов, а GPT-3  – до 2 048. Уже к 2024–2025 годам размер контекстных окон LLM вырос на порядки: GPT-4o, Claude 3 и Gemini Pro поддерживают от сотни тысяч до миллиона токенов, Llama 4 Scout* – до 10 миллионов. 

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

Вы загружаете в модель 200-страничный документ. Этот документ становится входными данными для модели — контекстом. Делаете простой запрос типа «вот тебе текст, ответь на вопросы <огромный текст>». В ответ — пересказ вступления, пара красивых обобщений и уверенное «как следует из первой главы…». Знакомо?

Пользовательская интуиция подсказывает: «Если окно позволяет, просто засуну всё целиком». 

Инженерная практика отвечает: «Так вы кормите модель шумом в надежде на чудо». Работает не «больше текста и информации», а лучше отобранный, «чистый» текст и правильный промпт.

Еще немного теории для тех, кто о проблеме контекста знал, но мало

Познавательные ограничения моделей

При увеличении контекстного окна мы сталкиваемся не только с вычислительными, но и с познавательными ограничениями модели. Свежие исследования выявили, что качество работы LLM значительно падает, если нужная информация находится не в начале или конце, а в середине длинного ввода. Этот эффект ученые из Стэнфорда и Калифорнийского университета в Беркли назвали lost in the middle («потерянный в середине»). В их эксперименте модель должна была отвечать на вопросы по нескольким документам или искать ключ-значение в длинном списке. Оказалось, что пока релевантный фрагмент стоял ближе к началу или концу контекста, ответы были правильнее, а при размещении важной части в середине развернутого промпта качество резко ухудшалось. Это проявилось даже у моделей, специально обученных на длинных последовательностях. Например, Claude с окном 100K тоже «терялся» в фактах, закопанных в середине текста. Иными словами, у LLM наблюдается смещение внимания к началу и концу контекста: ввод в начале они воспринимают как установку задачи, концовку помнят из-за близости к генерации, а вот информация посередине легко выпадает из фокуса.

Более того, не все модели реально используют свой максимальный контекст, о чем свидетельствует, в частности, прошлогоднее исследование NVidia. Ученые протестировали 17 моделей с заявленными контекстными окнами 32K–1M на разнообразных задачах: retrieval, multi-hop tracing, aggregation and question answering. Результаты показали, что у всех моделей качество снижалось по мере роста длины ввода. Формально многие поддерживали 32K+, но фактически заявленная длина контекста и эффективная (рабочая) у многих моделей (за редким исключением) отличаются в разы. Анализ выявил два характерных сбоя при экстремально длинном вводе: 

1. Модель всё чаще полагается на собственные параметрические знания вместо текста (проще говоря, начинает «отвечать по памяти»). 

2. Модель склонна копировать большие куски исходного текста, не справляясь на должном уровне с задачами обобщения.

Первый ведёт к галлюцинациям, второй – к фактическому цитированию без понимания. Просто увеличить контекст недостаточно — LLM не умеют надёжно фокусироваться на релевантном внутри очень длинного ввода.

Размывание релевантности и галлюцинации

Даже когда модель технически способна «переварить» 100 тысяч токенов, возникает вопрос: как выделить из них знания для ответа? Чем больше в промпте несущественной информации, тем сложнее модели понять суть. Лишний контекст буквально размывает внимание модели. Она может упустить ключевой факт среди длинного описания или, напротив, выдать нечто, опираясь на детали, не связанные с вопросом. Практические исследования абстрактной суммаризации показывают, что нейросети склонны придумывать детали, отсутствующие в исходном тексте. Порядка 30% фактов в их пересказах могут быть галлюцинациями, не подтверждёнными источником (больше в статье Faithful to the Original: Fact Aware Neural Abstractive Summarization). 

Похожее наблюдается и в диалогах: если задать вопрос с огромным контекстом, модель может ответить уверенно, опираясь на собственные знания, даже если пропустила нужные сведения внутри длинного промпта. В работе Survey of Hallucination in Natural Language Generation (2022) отмечается, что одним из ключевых факторов галлюцинаций является именно «шум» во входных данных — избыточный или нерелевантный контекст, в котором модель начинает фантазировать, пытаясь выдать связный ответ.

В статье NoLiMa: Long-Context Evaluation Beyond Literal Matching рассматривается метод оценки способности моделей обрабатывать длинный контекст под названием «Иголка в стоге сена», где иголка — это ответ на вопрос, а стог сена — это нерелевантная информация. Исследователи создали бенчмарк NoLiMa, содержащий пары вопрос-контекст. Ниже на графике показаны оценки разных моделей по этому бенчмарку. Видно, что с увеличением контекста качество ответов моделей снижается.

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

К таким спецмерам «сдерживания» LLM относятся RAG, динамические промпты, chanking и их комбинация. У каждого подхода есть свои сильные и слабые стороны. Мы провели эксперименты на нескольких версиях нашей собственной модели Cotype – с контекстом от 4К до 32К тоненов, и делимся результатами, какие из этих мер сработали лучше, а какие хуже. 

Эксперименты

Условия 

В экспериментах использовался единый составной документ (~25k токенов), включающий шесть тематически близких, но разнородных по стилю фрагментов (биографии, описания телешоу, производственные заметки, критические обзоры). Текст намеренно содержит множество близких сущностей и пересечений (тематика выживания, однотипные формулировки биографий, упоминания одних и тех же шоу), что создает реалистичную нагрузку на извлечение релевантного контента и снижает вероятность ответа «по памяти» модели. 

Контрольный вопрос: «Откуда родом ведущий американского реалити-шоу "Остров" Беар Гриллс?» 

Ответ на этот вопрос присутствует в этом отрывке текста (он взят отсюда): 

Беар Гриллс (Эдвард Майкл "Беар" Гриллс, родился 7 июня 1974) — британский авантюрист, писатель, телеведущий и бизнесмен. Впервые он привлек к себе внимание после того, как пустился в ряд приключений, а затем стал широко известен благодаря своему телесериалу "Человек против природы" (2006-2011). Он также участвует в ряде телесериалов о выживании в дикой природе в Великобритании и США, таких как "В дикой природе с Беаром Гриллсом" и "Остров с Беаром Гриллсом". В июле 2009 года Гриллс был назначен самым молодым в истории Ассоциации скаутов главным скаутом Соединенного Королевства и заморских территорий в возрасте 35 лет, этот пост он занимал и второй срок — с 2015 года. Личная жизнь: Гриллс родился в Москве, Россия, 7 июня 1974 года… 

В тексте выше есть ошибка — Гриллс родился не в Москве. Мы это придумали и добавили намеренно, чтобы можно было выявить применение моделью фоновых знаний. По этому ответу мы поймем, использует ли ИИ знания только из контекста.

К слову, кажется, что место рождения Гриллса покрыто какой-то тайной. В разных местах интернета указывается, что он родился то на о. Уайт, то в Северной Ирландии, то еще где. Даже в Википедии на англ. версии значится Донахади, а на русскоязычной — Лондон. Вот мы и подумали добавить в число возможных мест еще и Москву.

Для обеспечения воспроизводимости результатов во всех экспериментах фиксировались параметры генерации: temperature = 0, seed = 12347. Это позволило исключить влияние стохастических факторов и гарантировать, что различия в ответах определяются исключительно стратегиями организации контекста, а не случайностью модели.

Мы решили не вводить формальные метрики, так как результатов не так много и они кажутся избыточными, поэтому все ответы мы проверяли вручную. Ответ модели оценивался на совпадение с «правильным» ответом – Москва, Россия.

Эксперимент 1. Базовая стратегия (Baseline) 

В качестве базовой стратегии модель получала исходный текст целиком (без дополнительных механизмов отбора и адаптации). Для проверки влияния размера входа использовались четыре варианта: 4k, 8k, 16k и 32k токенов.

4k: модель дала развернутый ответ с уточнениями («британец, родился в Москве, Россия, но рос в Северной Ирландии»). Факт о Москве был заимствован из искаженного контекста, что подтверждает зависимость от локальной информации.

8k: ответ стал ещё более прямолинейным: «родом из Москвы, Россия». Модель чётко зафиксировала подмененный факт, проигнорировав фоновые знания.

16k: модель частично сместила акцент, начав с отрицания («Беар Гриллс не является ведущим американского реалити-шоу»), а далее уходит в рассуждение о том, кто ведёт шоу, без указания места происхождения.

32k: при почти максимальной длине контекста модель «сломала» инструкцию: вместо ответа на вопрос она сгенерировала энциклопедическую справку на английском языке, ссылаясь на внешние знания о Беаре Гриллсе.

При небольших входах (4k–8k) модель надёжно извлекает факт из локального контекста (включая намеренно подмененный «Москва, Россия»). При увеличении входа до 16k возникает сдвиг фокуса, а при 32k наблюдается дрейф к энциклопедической биографии и игнорированию инструкции. Это подчеркивает, что рост контекста повышает нагрузку на механизм внимания и увеличивает риск отклонения от вопроса.

Эксперимент 2. Генерация с дополненной выборкой (RAG) 

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

В нашем эксперименте документ (~25k токенов) был разбит на сегменты фиксированной длины (~700 токенов) с перекрытием 100 токенов. Для каждого сегмента построены эмбеддинги. Индексация и поиск релевантных фрагментов выполнялись через FAISS. На запрос «Откуда родом ведущий американского реалити-шоу "Остров" Беар Гриллс?» извлекалось до 5 ближайших сегментов. Эти сегменты объединялись в контекст, к которому добавлялась инструкция «Ответь на вопрос, опираясь только на предоставленный контекст, а не на свои знания».

Модель вернула корректный ответ, ссылаясь на искажённый факт из текста:

«Беар Гриллс родом из Москвы, Россия»

Плюсы:

RAG позволил эффективно извлечь именно тот фрагмент, где содержалась релевантная информация, несмотря на большой объем документа.

Модель не продемонстрировала «дрейфа» к внешним знаниям (в отличие от baseline при 32k).

Ответ лаконичный и полностью соответствует намеренному искажению, что подтверждает зависимость от поданного контекста.

Минусы / риски:

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

При большом числе кандидатов возможно дублирование или «зашумление» контекста.

Для сложных вопросов с распределенными фактами (не в одном куске) RAG в чистом виде может давать неполные ответы.

Вывод по RAG

По сравнению с baseline стратегия RAG продемонстрировала более устойчивое поведение на длинном тексте: модель использовала только релевантные сегменты и дала точный ответ, не отклоняясь к фоновым знаниям. Это подтверждает, что RAG — надежный способ контроля над фокусом внимания модели в условиях больших документов.

Эксперимент 3. Динамические промпты (адаптивная подача контекста)

Адаптивные или динамические  промпты (Dynamic prompting) — это стратегия, при которой контекст формируется не статично, а подстраивается под конкретный вопрос. Подробнее тут. 

В нашем случае документ (~25k токенов) предварительно делился на сегменты (700 токенов с перекрытием 100). Далее выполнялся разведочный шаг: модель генерировала список ключевых слов и лексем, связанных с целевой сущностью:

"entity": ["Беар Гриллс", "Bear Grylls"],

"fact": ["родом", "origin"],

"auxiliary": ["откуда", "from", "where"] 

Затем с помощью этих маркеров отбирались только те сегменты, где они встречались, включая соседние чанки для сохранения контекста. В случае, если релевантных фрагментов не хватало, словарь расширялся (например, добавлялись новые варианты написания), и процесс повторялся.

Результат эксперимента

Адаптивная подача контекста отобрала релевантные фрагменты по автоматически сгенерированным ключевым словам. Модель ответила корректно, ссылаясь на факт из контекста: «Беар Гриллс родом из Москвы, Россия». Подход позволил уменьшить объем входных данных по сравнению с baseline и избежать дрейфа к внешним знаниям.

Вывод

Динамический промптинг по функционалу близок к RAG: обе стратегии отбирают только часть документа для подачи в модель. Отличие заключается в механизме отбора: вместо векторного поиска здесь используется адаптивный словарный фильтр, уточняемый по ходу работы. Это делает метод проще для реализации и независимым от внешних сервисов для создания эмбеддингов, но менее устойчивым при работе с неявными или сильно перефразированными фактами.

Какие еще стратегии можно рассмотреть

Дробление (Chunking) – базовая альтернатива поиску релевантных фрагментов. Эта стратегия на первый взгляд может напоминать RAG. Документ также делится на фрагменты фиксированной длины (чанки), которые подаются в модель вместе с вопросом, но последовательно и без отбора по релевантности. То есть модель отвечает на вопрос, имея доступ только к одному непрерывному отрывку текста за раз. Еще одно отличие в том, что в RAG релевантные чанки выбираются с помощью векторного поиска, chunking предполагает перебор всех частей документа. 

Такой подход обеспечивает простоту реализации, но приводит к ряду ограничений:

• требуется многократное обращение к модели (по числу чанков), ответы могут дублироваться или расходиться;

• если информация «размазана» по разным фрагментам, итоговый результат может оказаться неполным.

В нашем эксперименте эта стратегия не применялась на практике, так как исходный текст целиком помещался в контекстное окно модели (25k < 32k). Однако chunking важно учитывать в качестве контрольного метода: он демонстрирует нижнюю границу качества и наглядно показывает, почему простой перебор уступает RAG и динамическим стратегиям подачи контекста.

На практике применяются и комбинированные методы, которые объединяют преимущества разных стратегий.

Примеры:

• RAG + Dynamic prompting (сначала векторный поиск отбирает широкий набор фрагментов, затем динамическая фильтрация по ключевым словам сужает выбор). 

• Summarization + RAG (сжатие текста для уменьшения шума перед поиском) 

• Map-Reduce + фильтрация (локальные ответы по сегментам с последующей агрегацией). 

Такие гибридные подходы повышают устойчивость при работе с объёмными или «шумными» документами.

В дополнение к базовым и комбинированным методам предлагаются более сложные подходы:

•  re-ranking (двухступенчатый RAG, где сначала отбирается широкий пул фрагментов, а затем оставляются только наиболее релевантные), 

• question decomposition (разбиение сложного вопроса на подвопросы и отдельный поиск ответов по ним), 

•  summarization-first (предварительное сжатие документа для уменьшения объёма перед поиском).

Заключение 

Сейчас идёт активное развитие LLM, постоянно выходят новые версии известных моделей, и к этим изменениям нужно научиться адаптироваться. С одной стороны, больше контекста — лучше, но с другой — большой контекст может путать модель и ухудшать качество ответа. А обработка большого объёма данных сейчас необходима — с помощью этого можно извлекать важное из расшифровок встреч, юридических документов и т.д. Надеемся, что эта статья поможет вам попробовать разные подходы и выбрать подходящий. 

*В статье упоминается большая языковая модель LLaMA, выпущенная компанией Meta AI, принадлежащей Meta Platforms, признанной экстремистской и запрещенной в РФ.