Контекст 128к на бумаге а на деле модель теряет середину промпта

[levis]

Жалоба и предупреждение разом: не верьте цифрам контекста в описании модели, заявленные 128к токенов почти никогда не работают как полноценные 128к. Закинул в Qwen2.5-14B большой документ примерно на 90к токенов и попросил найти конкретный факт который лежал где-то в середине. Модель уверенно нашла то что в начале и в конце, а середину просто проигнорировала, будто её и не было. Это классический lost in the middle, про который все знают в теории но напарываются на практике. Реально полезный контекст у большинства локалок это 16-32к, дальше внимание размазывается и качество ответов по тому что в глубине промпта падает. Так что когда в карточке модели пишут 128к, читайте это как до 128к влезет в память, но думать по всему этому она не будет.

[leewardms]

плюс многие локальные сборки контекст растягивают через rope scaling и yarn, а это уже не родной контекст на котором тренировали. растянули с 32к до 128к множителем, формально работает, а качество в растянутой зоне просядает. в gguf это часто включено по дефолту и народ не в курсе

[rabbit8]

ну а что ты хотел от 14B. оно и на 8к не блещет

[arch_coder]

реально полезный контекст у большинства локалок это 16-32к

тут соглашусь с оговоркой. зависит от модели и задачи. для извлечения одного факта (needle in haystack) топовые модели держат и 100к+ прилично, специально под это тюнят. а вот для рассуждения ПО всему длинному контексту, когда надо связать факты из начала и из конца, там да, всё разваливается уже к 32к. так что 16-32к это не про влезет а про сможет связно думать, и это правильная цифра. нужно разделять поиск иголки и реальное понимание длинного текста

[kend212]

@leewardms, по делу что с этим делать, а то одни жалобы.
Первое и главное: не пихай всё подряд в контекст. Если у тебя документ на 90к и нужен факт, сделай RAG, нарежь на чанки, найди релевантные эмбеддингами и скорми модели только нужные 4-8к. Качество ответа взлетит, потому что модель смотрит на маленький релевантный кусок а не размазывает внимание по простыне.
Второе: если RAG не вариант и нужно именно по всему тексту, бей задачу на проходы. Map-reduce: прогони документ кусками по 16к, с каждого собери выжимку, потом по выжимкам финальный ответ. Медленнее, но не теряет середину.
Третье по позиционированию: то что важно клади ближе к концу промпта, перед самим вопросом. Модели свежее помнят конец. Инструкции в начало, ключевые данные ближе к вопросу.
Четвёртое проверь не растянут ли контекст через yarn в твоём gguf, если родной у модели 32к а тебе впарили 128к скейлингом, в растянутой зоне будет хуже чем если бы ты остался в родном окне. Иногда лучше взять модель с честным длинным контекстом чем растянутую.
И замерь свою модель сам, тест needle in haystack гоняется за полчаса, узнаешь где конкретно у твоей сборки начинается деградация и не будешь гадать.

[pleki]

@ОП а на чём гонял, llama.cpp? проверь что ты вообще n_ctx выставил под нужный размер а не оставил дефолт. бывает что человек грузит 90к токенов а контекст у сервера 8к стоит и всё что сверху просто обрезается с начала. тогда середина пропадает не из-за внимания а потому что её физически выкинули. банально но проверь первым делом

[Omoto]

то что важно клади ближе к концу промпта, перед самим вопросом

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

[secret7260]

короче 128к это маркетинг, понятно. как обычно