Спасибо за ответы. Если позволите, то мое предположение/гипотеза по борьбе с зацикливанием (помимо обязательного repeat_penalty>=1.15) с учетом специфики решаемой вами задачи. Т.к.
1) Вы тренируете модель отвечать "into five sections";
2) Модель предназначена не для вывода для людей, а для вывода для другого кода, который требует четкость, стабильность и надежность;
3) На данный момент в различном ПО для инференса LLM уже хорошо/надежно поддерживается Structured Output в JSON;
Возможно ли не использовать спецтокены, а обучать модель выводу используемых вами 5 секций в виде JSON, по строгой JSON схеме с полями эквивалентными используемыми вами "special tokens", а затем, при эксплуатации модели, всегда пользоваться Structured Output для гарантирования формата вывода с целью защиты от зацикливаний, галлюцинаций и, заодно, т.к. ответ в JSON поле, то re.findall(r"<|answer_start|>...)" будет не нужен)? Тогда использование модели будет иметь примерный вид:
import json
import requests
from pydantic import BaseModel, Field, TypeAdapter
class RAGResponseModel(BaseModel):
# ... query_analysis, source_analysis - не понял тип поля, массив ли это и его min,max
# при помощи max_length ограничил "бюджет" полей reasoning и ответа, что также не даст зациклится в этих полях до предела max_model_len
reasoning: str = Field(..., max_length=700)
final_answer: str = Field(..., max_length=10)
so_schema = TypeAdapter(RAGResponseModel).json_schema()
print(so_schema) # Схема в JSON, которую можно использовать без pydantic - {'properties': {'reasoning': {'maxLength': 700, 'title': 'Reasoning', 'type': 'string'}, 'final_answer': {'maxLength': 10, 'title': 'Final Answer', 'type': 'string'}}, 'required': ['reasoning', 'final_answer'], 'title': 'RAGResponseModel', 'type': 'object'}
import json
import requests
import json
import requests
prompt = '''Поможет ли Structured Output (SO) побороть зацикливания?'''
url = 'http://127.0.0.1:8080/v1/chat/completions'
headers = { 'Content-Type': 'application/json' }
q = {
"messages": [
{
"role": "system",
"content": f"Your output should be JSON object with schema {json.dumps(so_schema)}"
},
{
"role": "user",
"content": prompt
}
],
'response_format': {
'type': 'json_schema',
'json_schema': {
'schema': so_schema,
'strict': True,
"name": "RAGResponseModel",
}
},
"chat_template_kwargs": {"enable_thinking": False},
"max_tokens":None,
"stream":False,
"repeat_penalty": 1.1,
"temperature": 0,
"top_p": 0.90,
"top_k": 64,
"min_p": 0.001,
}
response = requests.post(url, json=q, headers=headers)
assert(response.status_code == 200)
response_content = response.json()["choices"][0]["message"]['content']
print(response_content) # или сразу поле final_answer
и последующий код всегда будет получать или строгий ожидаемый валидный json (SO из ПО инференса должно это гарантировать) или сможет при ошибке парсинга .json() сделать повтор запроса с немного измененным содержимым (например, for retry in range(5): documents = shuffle(documents) ... break;
Это просто моя гипотеза на ваше усмотрение, на практике я так не пробовал (и нет подтверждения её реальности на моем практическом опыте тренировки ИИ, однако, сам SO работает все надежнее и ПО инференса охотно принимают issue и чинят его если с ним что-то не так случилось при простом запросе) и точно не знаю возможно ли так сделать и (насколько) это сработает (но, показалось, что с учетом размеров моделей OCC это не очень ресурсозатратно проверить).
Кроме отмеченной в публикации проблемы информационного дрейфа (несовпадения претрейна модели с актуальной информацией из контекста), кажется, что в RAG существует проблема AI alignment, когда ИИ напрочь отказывается или описывает некорректность контекста вместо ответа - интересно, существуют ли уже для этого бенчмарки/лидерборды и метрика в плане RAG и устраняет ли эту проблему OCC-файнтюн, ведь alignment это немного другое чем "считай данные из контекста актуальными" и, если более менее известно, какие данные из претрейна модели устарели в рамках домена, где применяется RAG (и модель можно дообучить на актуальных данных или задать в промпте, что актуально), то заранее совсем неизвестно на что авторы модели сделали alignment (имеется ввиду, что пользователь RAG совершенно не имеет цели узнать или получить от ИИ модели, что-то выходящее за границы дозволенного, а просто задает обычный условный вопрос "новости науки", "новости про остров" и в контекст попадают обычные публичные новости из разных СМИ, среди которых есть те, на которые срабатывает alignment авторов модели - про достижения в разделах науки; про альтернативные точки зрения по каким-то вопросам и т.п. - например, если qwen3 спросить "новости про остров", подав в контекст новости из СМИ этого острова).
Еще раз спасибо за публикацию этого исследования, вопрос того, чтобы ИИ модель (особенно дешевая, маленькая и локальная) не отклонялась от контекста, похоже, имеет место быть не только в области в RAG и метод его решения может пригодиться, например, даже при проверке орфографии https://habr.com/ru/companies/sberdevices/articles/806897/ где ИИ, например, может начать всегда исправлять в актуальных текстах из СМИ корректный год, имена должностных лиц и т.п. на те, что он знал при претрейне (т.е. текущий год или ФИО нового должностного считать за орфографическую ошибку и предлагать замену 2026->2024; или полностью всей текущей ФИО->ФИО прежнего должностного лица...).
С «узколобые» SLM (и частью других проблем) иногда помогает бороться методика Schema-Guided Reasoning https://habr.com/ru/companies/redmadrobot/articles/962236/ (а именно раздел “1. Cascade” https://abdullin.com/schema-guided-reasoning/patterns). Идея метода схожа с идеей reasoning LLM (т.к. LLM потокенно генерирует вероятное продолжение предыдущего текста, то если предыдущий текст содержит больше верных предпосылок, то и вероятность правильного ответа тоже увеличивается (а неопределенность и вероятность того, что неправильный ответ будет логичным продолжением верных предпосылок - уменьшается), поэтому LLM можно обучить на любой промпт до момента вывода конечного ответа сгенерировать искусственное рассуждение, которое увеличит вероятность правильного ответа и, ценой этих вычислений (генерации рассуждений), позволит превзойти предельные возможности этой же LLM без рассуждения) с тем отличием, что процесс/схему reasoning контролируете вы (а не то, как и по какой схеме авторы LLM обучали её рассуждать), да еще это рассуждение/вычисление может быть полезным для вас, если в схеме cascade рассуждения вы задали для LLM шаги рассуждения от простого к сложному (*так всегда должно быть в cascade - вероятность неправильного ответа на простой вопрос меньше чем, на сложный, кроме того ответ на этот вопрос, как ранее описано, сам по себе увеличивает вероятность правильного ответа на сложный вопрос по мере его генерации, поэтому если в cascade идет ряд правильных вопросов от простого к сложному, то даже у SLM шанс правильного конечного ответа ощутимо вырастет, т.к. неправильный ответ (и галлюцинация) постепенно станет очень маловероятным продолжением предыдущего вывода, а Structured Output (SO) не даст SLM отклониться (и сгаллюционировать, зациклиться - что для SLM не редкость) от требуемого формата и последовательности вывода) и каждый этот шаг сам по себе был для вас нужным полем вывода LLM. Из вашего ответа я узнал, что у вас генерация строки и структуры разнесены по разным агентам с разной задачей/контекстом, но, для условного примера, если бы это были два вызова LLM, а не два разных агента, то если таким методом в SLM подать сразу несколько связанных задач от простого к сложному, как я предположил {“short_desc”:одну краткую строку, “table_of_contents”:структуру}, где описание кластера одной строкой более простая задача, а составление его структуры/содержания - более сложная задача, то после шага “вывода его описания одной строкой” SLM ошибиться в структуре будет сложнее и оба этих поля/вывода будут нужны - то так может выйти наоборот, что “сразу несколько задач” SLM будет гарантированно (Structured Output) и совсем не “хуже выполнять их, чем по отдельности” и еще может возникнуть экономия на вызовах LLM и небольшая защита от prompt injection или того, что контекст своим содержанием "перепишет/зацепит" промпт (условно, если лектор задал риторический вопрос слушателю/аудитории: "Назовите мне третий закон Ньютона" затем тишина, достаточная для завершения этим локального кластера и SLM на таком кластере решит проигнорировать всё предыдущее и ответить на этот вопрос, а не вывести, что её просили - то SO не даст SLM отклониться от заданного формата JSON вывода, а заданные в схеме названия полей "short_desc" и "table_of_contents" отклониться от задачи) и многих других неожиданностей (SO позволяет ограничивать длины str, например, если не ожидается строка с описанием кластера в 2000 символов, задавать обязательные min-max размеры массивов и т.п.). То, что для SLM в агентных системах такой подход работает и иногда дает ощутимое увеличение качества (сравнимое с качеством моделей в 10-30 раз больших, чем сама SLM) говорится в проекте “SGR Agent Core” https://habr.com/ru/articles/986828/ на примере бенчмарка SimpleQA.
Спасибо за ответы. Возможно пригодится для будущих исследований/улучшений:
https://habr.com/ru/articles/1025132/ - ИИ большего размера, например, если достаточно оперативной памяти, то gemma-4-26B-A4B-it-UD-Q4_K_M.gguf с параметрами (-cmoe --fit on --fit-target 256 --cache-ram 512) помещается в 6GB VRAM с длиной контекста 71168 или 136704, если дополнительно к перечисленным параметрам включить квантование KV (–cache-type-k q8_0 и --cache-type-v q8_0). Или аналогично Qwen3.5-35B-A3B-Q4_K_M.gguf поместится с длиной контекста 123904 (или 216064 при q8_0 в обоих --cache-type-…; Qwen3.6 актуальнее, но по моим субъективным наблюдениям на задачах по рус. текстам работает хуже, чем 3.5).
https://ianas.fr/en/blog/2026/04/15/chunking-optimal-rag/ - обзор распространенных chunking методик. Интересно, что user_template из prompt_synthesizer.yaml показался схожим с “8. Contextual Retrieval”, где “Do not repeat the chunk content” ~= “Игнорируй все темы из текущего блока” и “ПРЕДЫДУЩИЙ КОНТЕКСТ” повышают качество смыслового разделения (сейчас для надежности чаще рекомендуют в промптах разделять контексты или Markdown - # ПРЕДЫДУЩИЙ КОНТЕКСТ или тегами - <previous_context>…</previous_context>, но T-lite ). Понравилось и то, что описанный вами метод rubert-tiny2+AgglomerativeClustering+connectivity после его модификации под тексты (например, если connectivity не по времени, а по номеру предложения после razdel) тоже мог бы быть одним из них. К вашему ответу отмечу, что и rubert-tiny2 тоже является «чёрным ящиком» и если он не был обучен на домене обрабатываемой лекции (особенно со специфическими терминами - медицина, химия или юридический, где кроме OOV (Out-of-Vocabulary) еще и сами слова могут иметь не общеупотребительное значение), тоже будет слабым местом. И, в целом, происходит переход от ML->ML/AI->AI всё больше к «чёрным ящикам» https://habr.com/ru/articles/1049872/.
Как альтернативы rubert-tiny2 и(или) multilingual-e5-small могут быть полезными: FRIDA (с правильным префиксом categorize_* для повторения логики работы “passage:” у e5) https://habr.com/ru/companies/sberdevices/articles/909924/ или Alibaba-NLP/gte-multilingual-base (быстрые, обходят по качеству e5-small). Если будет проводится масштабное тестирование на задаче, то могут быть также рассмотрены Qwen/Qwen3-Embedding-0.6B, BAAI/bge-m3 или google/embeddinggemma-300m, но они уже нарушат текущий баланс вашего проекта под нетребовательный CPU/скорость/качество (возможно, что даже и в ONNX/GGUF формате), в отличие, от FRIDA и gte.
Как альтернатива large-v3-turbo может быть https://habr.com/ru/companies/sberdevices/articles/973160/ (сравнение с large-v3-turbo и другими https://habr.com/ru/articles/1002260/), но, как и у векторных моделей, на лекциях из специфичных доменов у моделей транскрипции тоже может быть массовый OOV (Out-of-Vocabulary) и по этой причине однозначно лучшего варианта для всех случаев может и не быть. Возможно, что этап верификации транскрипции от разных моделей транскрибирования также помог бы выбирать лучшую транскрипцию, тем более, что https://habr.com/ru/articles/1022628/ для выбора лучшей уже в один промпт возможно подать “фрагмент аудио + текст: <первая_транскрипция> … <вторая_транскрипция> … промт”, а не просто текстовые транскрипции для проверки их адекватности и выбора лучшей только по текстовым признакам.
Не пробовали ли вы сравнивать подход rubert-tiny2+AgglomerativeClustering+connectivity с методами семантического чанкинга (например, https://github.com/mirth/chonky) для разбиения текста на локальные кластеры?
Возможно ли на ваш взгляд модифицировать rubert-tiny2+AgglomerativeClustering+connectivity для определения границ публикаций в pdf сборниках (научных журналах, сборниках работ) где все публикации идут подряд и проблемно разделить его на отдельные публикации ([начало: страница + положение на ней, конец: страница + положение на ней] ... [...])?
Не сильно GlobalPlanner галлюцинирует или часто выдает "оторванные от реальности" шаблонные структуры “Введение, История вопроса, …, Заключение” получая на вход только одну краткую строку с описанием локального кластера и не имея представления ни о его размере (10 предложений или 100 или 500) ни о его фактической структуре/содержании? Не пробовали ли вместо 2х этапов (1. краткая строка и 2. структура) делать это одним - отправлять кластер с условным заданием “Выведи только JSON: {"short_desc":одну краткую строку, "table_of_contents ":структуру} следующего текста:…” (методами Structured Output такой вывод может быть сделан надежным)?
Этап верификации работы Synthesizer опущен умышленно или была причина (экономия вычислений и т.п.)? Synthesizer может галлюцинировать разными способами (зацикливание; отказ синтеза текста про раздел химии/физики по его “этическим соображениям” т.п.) и это можно было бы выявить имея сырой транскрипт, синтезированный текст и условный шаг верификации “[Транскрипт]… [ТЕКСТ]… Выведи только оценку от 0 до 10, насколько текст согласуется с транскриптом.”
Будет ли LongConspectWriter работать на лекциях Социально-гуманитарных/Естественных наук, а не точных наук? Возможна ли его модификация для структурированной аннотации таких лекций/текстов - например, структура и контролируемое сжатое содержание 2х часовой лекции по философии? Насколько я понял в вашей публикации под конспектом понимается очень близкий к оригиналу выход ИИ модели (из содержания убираются лишь “P2. Объективизация и деперсонализация”), т.е. речь не идет о смысловом сжатии, которое могло бы пригодится при обработке лекций не точных наук.
Нет ли к вашей публикации списка литературы на тему методов/способов обработки “невместимого в контекст” текста с целью его качественного описания/сжатия?
Спасибо, очень интересное исследование. Несколько вопросов:
Для этой модели не нужен реранкер “documents=” т.к. при обучении “Обучаем через SFT. Промпт — это вопрос плюс контексты в случайном порядке” и качество ответа не должно сильно зависеть от положения релевантной информации в “documents=”?
Могут быть ли документами поисковые сниппеты, содержащие обрывочные html-теги, css, Markdown или тренировка осуществлялась только на очищенных текстах?
Сколько документов(сниппетов) и какого размера оптимально подавать в “documents=” (возможно при тренировке использовали некоторые базовые количество/размер) или имеет значение только проблема забывания контекста при его увеличении, т.е. для Qwen/Qwen3-1.7B-Base чем ближе к максимальной длине контекста Context Length: 32,768, тем хуже?
Способ подачи документов через “documents=” защищает от опасностей содержания в них prompt-injection?
Время ответов этой модели не постоянно? Т.е. режим рассуждений отключить нельзя (в примерах уже стоит enable_thinking=False,), и учитывая размер модели в <= 1.7B она может быть склонна к зацикливанию, но маленький max_length=512 разумных размеров тоже сделать не получится из-за недерминированного размера “блока рассуждений” в выводе, иначе может конечный ответ обрезаться.
Сохранила ли модель кроссязыковые свойства Qwen3, когда контекст на одном языке, а вопрос на другом и можно ли подавать в “documents=” смешанный набор документов из en и ru?
Каков оптимальный DPI изображений для этой модели (144/200/300…)?
Означает ли “Для v5 это 960 пикселей”, что размер наибольшей стороны изображения во время “Шаг 3. Детекция текстовых блоков” не должен превышать 960px? Т.е. эта модель не сможет распознать текстовые блоки со страниц pdf журналов, например NYT или FT т.к. при сохранении читаемости стороны таких изображений более 2 (или 4) тыс. пикселей.
“модель распознавания ожидает фиксированную высоту H” - т.е. блоки с вырезанным текстом надо всегда преобразовывать в изображение с высотой h = 48 (из заметок в конце публикации), а если блок будет содержать несколько строк друг под другом (когда текст на исходном изображении расположен в колонках)?
Подойдет ли для “Масштабирование изображения с добавлением паддинга для кратности сторон 32” такая функция smart_resize с factor=32?
Будет ли на обычном настольном компьютере/ноутбуке (6-8 ядер по ~4 ГГц и 8-16 Гб RAM) CPU вариант укладываться в 5 секунд на изображение?
Спасибо, очень интересный опыт и познавательная публикация. Интересно, используете ли вы реранкеры (tomaarsen/Qwen3-Reranker-4B-seq-cls неплох по железу/скорости/качеству), пробовали ли другие embedder'ы (Alibaba-NLP/gte-multilingual-base - вдвое быстрее и размерность меньше - 768 (против 1024 у BGE-M3 - получается, что на 25% меньше передавать по сети и хранить в индексе/таблице БД), или google/embeddinggemma-300m, который не быстрее, но также размерности 768, лучше по публичным метрикам качества, умеет разные задачи (через префиксы - QA / retrieval / classification / clustering / semantic similarity) и поддерживает Matryoshka, однако, sparse представлений у обоих нет), какие наиболее удачные по вашему опыту получились методики/параметры чанкера (используете ли RecursiveCharacterTextSplitter из langchain или что-то более специфическое https://habr.com/ru/companies/raft/articles/954158/)? По Qwen'у интересно используете ли system или все в user промпты прописываете и в каком формате (markdown/xml/json), причем применяете ли при работе с MCP упомянутые методики structured output (например, чтобы не было ошибок в вызове mcp инструментов) или SGR (например, чтобы вызывать не mcp tool, a гарантированный, оформленный в виде sgr схемы tool) и подаете ли при этом схему SO/SGR в виде json в самом промте, не пишет ли часто иероглифы/отклоняется от контекста (и какой, в целом, вы считаете основную причину необходимости в 235B, при достигнутом на текущий момент на ваших потребностях балансе ресурсы/качество) и не пробовали ли в сравнении с Qwen-next модель t-tech/T-pro-it-2.1-FP8 (у которой в основе (dense модель) qwen3-32b с изначально более низким hallucination rate https://huggingface.co/spaces/vectara/leaderboard 5.9% против 9.3% у next), но после улучшения авторами модели, предположительно, должно быть меньше проблем с языком/tools/json и с FP8 в комплекте. Отдельно интересны подробности по агентам в плане RAG дополненных агентов (по упомянутому на изображении из раздела "к агентам на MCP" - SearXNG - в каком виде получилось лучше всего в Qwen подавать поисковые сниппеты (title,snipper description,date,url) - KV/XML/TOON/JSON - https://habr.com/ru/articles/955778/) как работает дополнение "критик + валидатор" (в плане используется ли оно в RAG цепочке для факт-чекинга генерации), как осуществляется маршрутизация в поиск (сам ли агент понимает, что данных в контексте недостаточно/нерелевантные и нужен вызов search tool или агент всегда вызывает единый search tool, который ищет в БД, и если ничего не нашлось (rule-based методикой), возвращает результаты не из БД, а из SearXNG), используете ли какие-нибудь Guardians https://habr.com/ru/companies/redmadrobot/articles/971388/ и на каком этапе/какой области - пользователи/RAG/агенты? Если слишком много спросил, вопросы неинтересные или на некоторые неудобно отвечать (по абсолютно любым причинам долго/NDA/ноу-хау/экспертиза/security...), не отвечайте или пропустите, возможно позже, создадите еще одну, такую же прекрасную, как эта, публикацию (или даже серию - от RAG к DeepResearch Агентам, n8n подобным решениям, guard'у и факт-чекингу).
Спасибо за публикацию. Вы не сравнивали качество своего решения с моделями SAGE v1.1.0 (https://www.youtube.com/watch?v=XRp0aGWwz4w)? Не могли бы описать, почему время исправления опечаток (500 миллисекунд ) вы считаете критичным - каково соотношение количества уникальных опечаток ко всем опечаткам в имеющихся у вас наборах данных (логов и т.п.), ведь если за года работы накопилась приличная база опечаток-исправлений (+прогнать синтетическую генерацию-исправление опечаток по критичным для поиска сущностям) и поместить её в кеш (от memcached, redis и т.п.) или прямо в словари mapping'a текстовых полей в elasticsearch (синонимы/поисковые подсказки), то задержки будут минимальны, а качество контролируемо (для кеша/словарей можно будет легко вручную раз в день/неделю/месяц валидировать/вносить/накапливать корректировки, как для ошибочных исправлений, так и для новых, внезапно появившихся популярных понятий (например, "массажеры для тапания хомяка"), на которых модель не училась и не сможет адекватно исправить), при этом, если опечатка окажется уникальной (в очень небольшом % случаев, т.к. в словах возможных опечаток не бесконечно с учетом длины слов и расположения использующихся клавиатуры и со временем кеш будет полнее, а уникальных опечаток меньше), то пользователь получит свой результат поиска, а "лишних 400 миллисекунд подождать" будут не так огорчительны и мотивировать писать правильно.
Спасибо за очередной первоклассный обзорный материал! По желанию в раздел "(10) Гибридный поиск" можно было бы добавить текстовое упоминание еще одного ключевого этапа этого подхода - переранжирования, который графически отражен на картинке как "Cross-Encoder", т.е. при гибридном поиске мы комбинируем результаты обоих подходов и обязательно переранжируем их или специальными алгоритмами (Reciprocal Rank Fusion (RRF); Min-Max score normalization...) или отдельными ИИ моделями для оценки релевантности найденного запросу (Cross-Encoder... вплоть до LLM с вопросами "насколько баллов найденное ... соответствует запросу ...") и получаем улучшенную поисковую выдачу, а без переранживания гибридный поиск скорее всего будет работать хуже, чем просто отдельный лексический или семантический поиск. И, соотвественно, в этот же раздел или в "(5) Оптимизация структуры индекса" упомянуть совместно с алгоритмами еще и пример БД поддерживающих его OpenSearch/Elasticsearch, Milvus, Vespa, Qdrant... Ссылки по теме: https://learn.microsoft.com/en-us/azure/search/hybrid-search-ranking https://qdrant.tech/articles/hybrid-search/ https://opensearch.org/blog/hybrid-search/ https://milvus.io/docs/multi-vector-search.md
Имеет ли при инференсе большой квантованной модели значение для скорости на скольких GPU она запущена, например, на одной 80ГБ A100 или на двух 40ГБ A100 - т.е. участвуют ли при сетапе на N картах вторая...N'тая карты в вычислениях или просто являются расширением GPU Ram для весов/kv-кеша модели не поместившихся на первую карту? Ситуация всегда будет одинакова, или для архитектур как MoE она отличается (часто в новостях пишут, что для запуска надо, например, 4 40Гб A100 имея ввиду потребность модели в 160 Гб GPU Ram, а то, что это 2 карты 80Гб A100 не упоминают - м.б. есть причина)?
При weight-only квантизации что происходит с KV кешем - необходимая под него RAM автоматически уменьшается в соответствии (также кратно) с уменьшением размера квантованных весов относительно изначальных или KV кеш всегда квантуют отдельно при инференсе, например, во многих фреймворках есть опции - 16/8/4-bit KV Cache?
А если речь не о LLM, а о векторной модели, например, int8 quantized intfloat-multilingual-e5-large, то квантованными в ней будут только веса или выходные вектора из модели тоже будут в int8? Сейчас всё больше БД поддерживают разные числовые типы полей с векторами, но как получать вектора в таких типах из общедоступных моделей (optimum'ом можно делать или м.б. есть какие-то специальные инструменты)?
Спасибо, отличный теоретический материал, многое объяснил. А на практике вы какой актуальный общедоступный (в котором выкладывают модели) метод/формат квантизации по балансу в сохранении исходного качества модели/большей скорости/экономии GPU памяти могли бы порекомендовать: GPTQ / GGUF [2, 3, 4, 5, 6 and 8-bit] / AWQ / transformers [fp8/fp16]+bitsandbytes [4, 8-bit] / другой вариант и софт для инференса: transformers / llama.cpp / vLLM / другой?
Спасибо за ответы. Если позволите, то мое предположение/гипотеза по борьбе с зацикливанием (помимо обязательного repeat_penalty>=1.15) с учетом специфики решаемой вами задачи. Т.к.
1) Вы тренируете модель отвечать "into five sections";
2) Модель предназначена не для вывода для людей, а для вывода для другого кода, который требует четкость, стабильность и надежность;
3) На данный момент в различном ПО для инференса LLM уже хорошо/надежно поддерживается Structured Output в JSON;
Возможно ли не использовать спецтокены, а обучать модель выводу используемых вами 5 секций в виде JSON, по строгой JSON схеме с полями эквивалентными используемыми вами "special tokens", а затем, при эксплуатации модели, всегда пользоваться Structured Output для гарантирования формата вывода с целью защиты от зацикливаний, галлюцинаций и, заодно, т.к. ответ в JSON поле, то re.findall(r"<|answer_start|>...)" будет не нужен)? Тогда использование модели будет иметь примерный вид:
и последующий код всегда будет получать или строгий ожидаемый валидный json (SO из ПО инференса должно это гарантировать) или сможет при ошибке парсинга .json() сделать повтор запроса с немного измененным содержимым (например, for retry in range(5): documents = shuffle(documents) ... break;
Это просто моя гипотеза на ваше усмотрение, на практике я так не пробовал (и нет подтверждения её реальности на моем практическом опыте тренировки ИИ, однако, сам SO работает все надежнее и ПО инференса охотно принимают issue и чинят его если с ним что-то не так случилось при простом запросе) и точно не знаю возможно ли так сделать и (насколько) это сработает (но, показалось, что с учетом размеров моделей OCC это не очень ресурсозатратно проверить).
Кроме отмеченной в публикации проблемы информационного дрейфа (несовпадения претрейна модели с актуальной информацией из контекста), кажется, что в RAG существует проблема AI alignment, когда ИИ напрочь отказывается или описывает некорректность контекста вместо ответа - интересно, существуют ли уже для этого бенчмарки/лидерборды и метрика в плане RAG и устраняет ли эту проблему OCC-файнтюн, ведь alignment это немного другое чем "считай данные из контекста актуальными" и, если более менее известно, какие данные из претрейна модели устарели в рамках домена, где применяется RAG (и модель можно дообучить на актуальных данных или задать в промпте, что актуально), то заранее совсем неизвестно на что авторы модели сделали alignment (имеется ввиду, что пользователь RAG совершенно не имеет цели узнать или получить от ИИ модели, что-то выходящее за границы дозволенного, а просто задает обычный условный вопрос "новости науки", "новости про остров" и в контекст попадают обычные публичные новости из разных СМИ, среди которых есть те, на которые срабатывает alignment авторов модели - про достижения в разделах науки; про альтернативные точки зрения по каким-то вопросам и т.п. - например, если qwen3 спросить "новости про остров", подав в контекст новости из СМИ этого острова).
Еще раз спасибо за публикацию этого исследования, вопрос того, чтобы ИИ модель (особенно дешевая, маленькая и локальная) не отклонялась от контекста, похоже, имеет место быть не только в области в RAG и метод его решения может пригодиться, например, даже при проверке орфографии https://habr.com/ru/companies/sberdevices/articles/806897/ где ИИ, например, может начать всегда исправлять в актуальных текстах из СМИ корректный год, имена должностных лиц и т.п. на те, что он знал при претрейне (т.е. текущий год или ФИО нового должностного считать за орфографическую ошибку и предлагать замену 2026->2024; или полностью всей текущей ФИО->ФИО прежнего должностного лица...).
С «узколобые» SLM (и частью других проблем) иногда помогает бороться методика Schema-Guided Reasoning https://habr.com/ru/companies/redmadrobot/articles/962236/ (а именно раздел “1. Cascade” https://abdullin.com/schema-guided-reasoning/patterns). Идея метода схожа с идеей reasoning LLM (т.к. LLM потокенно генерирует вероятное продолжение предыдущего текста, то если предыдущий текст содержит больше верных предпосылок, то и вероятность правильного ответа тоже увеличивается (а неопределенность и вероятность того, что неправильный ответ будет логичным продолжением верных предпосылок - уменьшается), поэтому LLM можно обучить на любой промпт до момента вывода конечного ответа сгенерировать искусственное рассуждение, которое увеличит вероятность правильного ответа и, ценой этих вычислений (генерации рассуждений), позволит превзойти предельные возможности этой же LLM без рассуждения) с тем отличием, что процесс/схему reasoning контролируете вы (а не то, как и по какой схеме авторы LLM обучали её рассуждать), да еще это рассуждение/вычисление может быть полезным для вас, если в схеме cascade рассуждения вы задали для LLM шаги рассуждения от простого к сложному (*так всегда должно быть в cascade - вероятность неправильного ответа на простой вопрос меньше чем, на сложный, кроме того ответ на этот вопрос, как ранее описано, сам по себе увеличивает вероятность правильного ответа на сложный вопрос по мере его генерации, поэтому если в cascade идет ряд правильных вопросов от простого к сложному, то даже у SLM шанс правильного конечного ответа ощутимо вырастет, т.к. неправильный ответ (и галлюцинация) постепенно станет очень маловероятным продолжением предыдущего вывода, а Structured Output (SO) не даст SLM отклониться (и сгаллюционировать, зациклиться - что для SLM не редкость) от требуемого формата и последовательности вывода) и каждый этот шаг сам по себе был для вас нужным полем вывода LLM. Из вашего ответа я узнал, что у вас генерация строки и структуры разнесены по разным агентам с разной задачей/контекстом, но, для условного примера, если бы это были два вызова LLM, а не два разных агента, то если таким методом в SLM подать сразу несколько связанных задач от простого к сложному, как я предположил {“short_desc”:одну краткую строку, “table_of_contents”:структуру}, где описание кластера одной строкой более простая задача, а составление его структуры/содержания - более сложная задача, то после шага “вывода его описания одной строкой” SLM ошибиться в структуре будет сложнее и оба этих поля/вывода будут нужны - то так может выйти наоборот, что “сразу несколько задач” SLM будет гарантированно (Structured Output) и совсем не “хуже выполнять их, чем по отдельности” и еще может возникнуть экономия на вызовах LLM и небольшая защита от prompt injection или того, что контекст своим содержанием "перепишет/зацепит" промпт (условно, если лектор задал риторический вопрос слушателю/аудитории: "Назовите мне третий закон Ньютона" затем тишина, достаточная для завершения этим локального кластера и SLM на таком кластере решит проигнорировать всё предыдущее и ответить на этот вопрос, а не вывести, что её просили - то SO не даст SLM отклониться от заданного формата JSON вывода, а заданные в схеме названия полей "short_desc" и "table_of_contents" отклониться от задачи) и многих других неожиданностей (SO позволяет ограничивать длины str, например, если не ожидается строка с описанием кластера в 2000 символов, задавать обязательные min-max размеры массивов и т.п.). То, что для SLM в агентных системах такой подход работает и иногда дает ощутимое увеличение качества (сравнимое с качеством моделей в 10-30 раз больших, чем сама SLM) говорится в проекте “SGR Agent Core” https://habr.com/ru/articles/986828/ на примере бенчмарка SimpleQA.
Спасибо за ответы. Возможно пригодится для будущих исследований/улучшений:
https://habr.com/ru/articles/1025132/ - ИИ большего размера, например, если достаточно оперативной памяти, то gemma-4-26B-A4B-it-UD-Q4_K_M.gguf с параметрами (-cmoe --fit on --fit-target 256 --cache-ram 512) помещается в 6GB VRAM с длиной контекста 71168 или 136704, если дополнительно к перечисленным параметрам включить квантование KV (–cache-type-k q8_0 и --cache-type-v q8_0). Или аналогично Qwen3.5-35B-A3B-Q4_K_M.gguf поместится с длиной контекста 123904 (или 216064 при q8_0 в обоих --cache-type-…; Qwen3.6 актуальнее, но по моим субъективным наблюдениям на задачах по рус. текстам работает хуже, чем 3.5).
https://ianas.fr/en/blog/2026/04/15/chunking-optimal-rag/ - обзор распространенных chunking методик. Интересно, что user_template из prompt_synthesizer.yaml показался схожим с “8. Contextual Retrieval”, где “Do not repeat the chunk content” ~= “Игнорируй все темы из текущего блока” и “ПРЕДЫДУЩИЙ КОНТЕКСТ” повышают качество смыслового разделения (сейчас для надежности чаще рекомендуют в промптах разделять контексты или Markdown - # ПРЕДЫДУЩИЙ КОНТЕКСТ или тегами - <previous_context>…</previous_context>, но T-lite ). Понравилось и то, что описанный вами метод rubert-tiny2+AgglomerativeClustering+connectivity после его модификации под тексты (например, если connectivity не по времени, а по номеру предложения после razdel) тоже мог бы быть одним из них. К вашему ответу отмечу, что и rubert-tiny2 тоже является «чёрным ящиком» и если он не был обучен на домене обрабатываемой лекции (особенно со специфическими терминами - медицина, химия или юридический, где кроме OOV (Out-of-Vocabulary) еще и сами слова могут иметь не общеупотребительное значение), тоже будет слабым местом. И, в целом, происходит переход от ML->ML/AI->AI всё больше к «чёрным ящикам» https://habr.com/ru/articles/1049872/.
Как альтернативы rubert-tiny2 и(или) multilingual-e5-small могут быть полезными: FRIDA (с правильным префиксом categorize_* для повторения логики работы “passage:” у e5) https://habr.com/ru/companies/sberdevices/articles/909924/ или Alibaba-NLP/gte-multilingual-base (быстрые, обходят по качеству e5-small). Если будет проводится масштабное тестирование на задаче, то могут быть также рассмотрены Qwen/Qwen3-Embedding-0.6B, BAAI/bge-m3 или google/embeddinggemma-300m, но они уже нарушат текущий баланс вашего проекта под нетребовательный CPU/скорость/качество (возможно, что даже и в ONNX/GGUF формате), в отличие, от FRIDA и gte.
Как альтернатива large-v3-turbo может быть https://habr.com/ru/companies/sberdevices/articles/973160/ (сравнение с large-v3-turbo и другими https://habr.com/ru/articles/1002260/), но, как и у векторных моделей, на лекциях из специфичных доменов у моделей транскрипции тоже может быть массовый OOV (Out-of-Vocabulary) и по этой причине однозначно лучшего варианта для всех случаев может и не быть. Возможно, что этап верификации транскрипции от разных моделей транскрибирования также помог бы выбирать лучшую транскрипцию, тем более, что https://habr.com/ru/articles/1022628/ для выбора лучшей уже в один промпт возможно подать “фрагмент аудио + текст: <первая_транскрипция> … <вторая_транскрипция> … промт”, а не просто текстовые транскрипции для проверки их адекватности и выбора лучшей только по текстовым признакам.
Спасибо за интересную публикацию.
Не пробовали ли вы сравнивать подход rubert-tiny2+AgglomerativeClustering+connectivity с методами семантического чанкинга (например, https://github.com/mirth/chonky) для разбиения текста на локальные кластеры?
Возможно ли на ваш взгляд модифицировать rubert-tiny2+AgglomerativeClustering+connectivity для определения границ публикаций в pdf сборниках (научных журналах, сборниках работ) где все публикации идут подряд и проблемно разделить его на отдельные публикации ([начало: страница + положение на ней, конец: страница + положение на ней] ... [...])?
Не сильно GlobalPlanner галлюцинирует или часто выдает "оторванные от реальности" шаблонные структуры “Введение, История вопроса, …, Заключение” получая на вход только одну краткую строку с описанием локального кластера и не имея представления ни о его размере (10 предложений или 100 или 500) ни о его фактической структуре/содержании? Не пробовали ли вместо 2х этапов (1. краткая строка и 2. структура) делать это одним - отправлять кластер с условным заданием “Выведи только JSON: {"short_desc":одну краткую строку, "table_of_contents ":структуру} следующего текста:…” (методами Structured Output такой вывод может быть сделан надежным)?
Этап верификации работы Synthesizer опущен умышленно или была причина (экономия вычислений и т.п.)? Synthesizer может галлюцинировать разными способами (зацикливание; отказ синтеза текста про раздел химии/физики по его “этическим соображениям” т.п.) и это можно было бы выявить имея сырой транскрипт, синтезированный текст и условный шаг верификации “[Транскрипт]… [ТЕКСТ]… Выведи только оценку от 0 до 10, насколько текст согласуется с транскриптом.”
Будет ли LongConspectWriter работать на лекциях Социально-гуманитарных/Естественных наук, а не точных наук? Возможна ли его модификация для структурированной аннотации таких лекций/текстов - например, структура и контролируемое сжатое содержание 2х часовой лекции по философии? Насколько я понял в вашей публикации под конспектом понимается очень близкий к оригиналу выход ИИ модели (из содержания убираются лишь “P2. Объективизация и деперсонализация”), т.е. речь не идет о смысловом сжатии, которое могло бы пригодится при обработке лекций не точных наук.
Нет ли к вашей публикации списка литературы на тему методов/способов обработки “невместимого в контекст” текста с целью его качественного описания/сжатия?
Спасибо, очень интересное исследование. Несколько вопросов:
Для этой модели не нужен реранкер “documents=” т.к. при обучении “Обучаем через SFT. Промпт — это вопрос плюс контексты в случайном порядке” и качество ответа не должно сильно зависеть от положения релевантной информации в “documents=”?
Могут быть ли документами поисковые сниппеты, содержащие обрывочные html-теги, css, Markdown или тренировка осуществлялась только на очищенных текстах?
Сколько документов(сниппетов) и какого размера оптимально подавать в “documents=” (возможно при тренировке использовали некоторые базовые количество/размер) или имеет значение только проблема забывания контекста при его увеличении, т.е. для Qwen/Qwen3-1.7B-Base чем ближе к максимальной длине контекста Context Length: 32,768, тем хуже?
Способ подачи документов через “documents=” защищает от опасностей содержания в них prompt-injection?
Время ответов этой модели не постоянно? Т.е. режим рассуждений отключить нельзя (в примерах уже стоит enable_thinking=False,), и учитывая размер модели в <= 1.7B она может быть склонна к зацикливанию, но маленький max_length=512 разумных размеров тоже сделать не получится из-за недерминированного размера “блока рассуждений” в выводе, иначе может конечный ответ обрезаться.
Сохранила ли модель кроссязыковые свойства Qwen3, когда контекст на одном языке, а вопрос на другом и можно ли подавать в “documents=” смешанный набор документов из en и ru?
Спасибо за публикацию. Несколько вопросов:
Каков оптимальный DPI изображений для этой модели (144/200/300…)?
Означает ли “Для v5 это 960 пикселей”, что размер наибольшей стороны изображения во время “Шаг 3. Детекция текстовых блоков” не должен превышать 960px? Т.е. эта модель не сможет распознать текстовые блоки со страниц pdf журналов, например NYT или FT т.к. при сохранении читаемости стороны таких изображений более 2 (или 4) тыс. пикселей.
“модель распознавания ожидает фиксированную высоту H” - т.е. блоки с вырезанным текстом надо всегда преобразовывать в изображение с высотой h = 48 (из заметок в конце публикации), а если блок будет содержать несколько строк друг под другом (когда текст на исходном изображении расположен в колонках)?
Подойдет ли для “Масштабирование изображения с добавлением паддинга для кратности сторон 32” такая функция smart_resize с factor=32?
Будет ли на обычном настольном компьютере/ноутбуке (6-8 ядер по ~4 ГГц и 8-16 Гб RAM) CPU вариант укладываться в 5 секунд на изображение?
Спасибо, что поделились опытом, буду ждать ваших новых публикаций.
Спасибо, очень интересный опыт и познавательная публикация. Интересно, используете ли вы реранкеры (tomaarsen/Qwen3-Reranker-4B-seq-cls неплох по железу/скорости/качеству), пробовали ли другие embedder'ы (Alibaba-NLP/gte-multilingual-base - вдвое быстрее и размерность меньше - 768 (против 1024 у BGE-M3 - получается, что на 25% меньше передавать по сети и хранить в индексе/таблице БД), или google/embeddinggemma-300m, который не быстрее, но также размерности 768, лучше по публичным метрикам качества, умеет разные задачи (через префиксы - QA / retrieval / classification / clustering / semantic similarity) и поддерживает Matryoshka, однако, sparse представлений у обоих нет), какие наиболее удачные по вашему опыту получились методики/параметры чанкера (используете ли RecursiveCharacterTextSplitter из langchain или что-то более специфическое https://habr.com/ru/companies/raft/articles/954158/)? По Qwen'у интересно используете ли system или все в user промпты прописываете и в каком формате (markdown/xml/json), причем применяете ли при работе с MCP упомянутые методики structured output (например, чтобы не было ошибок в вызове mcp инструментов) или SGR (например, чтобы вызывать не mcp tool, a гарантированный, оформленный в виде sgr схемы tool) и подаете ли при этом схему SO/SGR в виде json в самом промте, не пишет ли часто иероглифы/отклоняется от контекста (и какой, в целом, вы считаете основную причину необходимости в 235B, при достигнутом на текущий момент на ваших потребностях балансе ресурсы/качество) и не пробовали ли в сравнении с Qwen-next модель t-tech/T-pro-it-2.1-FP8 (у которой в основе (dense модель) qwen3-32b с изначально более низким hallucination rate https://huggingface.co/spaces/vectara/leaderboard 5.9% против 9.3% у next), но после улучшения авторами модели, предположительно, должно быть меньше проблем с языком/tools/json и с FP8 в комплекте. Отдельно интересны подробности по агентам в плане RAG дополненных агентов (по упомянутому на изображении из раздела "к агентам на MCP" - SearXNG - в каком виде получилось лучше всего в Qwen подавать поисковые сниппеты (title,snipper description,date,url) - KV/XML/TOON/JSON - https://habr.com/ru/articles/955778/) как работает дополнение "критик + валидатор" (в плане используется ли оно в RAG цепочке для факт-чекинга генерации), как осуществляется маршрутизация в поиск (сам ли агент понимает, что данных в контексте недостаточно/нерелевантные и нужен вызов search tool или агент всегда вызывает единый search tool, который ищет в БД, и если ничего не нашлось (rule-based методикой), возвращает результаты не из БД, а из SearXNG), используете ли какие-нибудь Guardians https://habr.com/ru/companies/redmadrobot/articles/971388/ и на каком этапе/какой области - пользователи/RAG/агенты? Если слишком много спросил, вопросы неинтересные или на некоторые неудобно отвечать (по абсолютно любым причинам долго/NDA/ноу-хау/экспертиза/security...), не отвечайте или пропустите, возможно позже, создадите еще одну, такую же прекрасную, как эта, публикацию (или даже серию - от RAG к DeepResearch Агентам, n8n подобным решениям, guard'у и факт-чекингу).
Спасибо за публикацию. Вы не сравнивали качество своего решения с моделями SAGE v1.1.0 (https://www.youtube.com/watch?v=XRp0aGWwz4w)? Не могли бы описать, почему время исправления опечаток (500 миллисекунд ) вы считаете критичным - каково соотношение количества уникальных опечаток ко всем опечаткам в имеющихся у вас наборах данных (логов и т.п.), ведь если за года работы накопилась приличная база опечаток-исправлений (+прогнать синтетическую генерацию-исправление опечаток по критичным для поиска сущностям) и поместить её в кеш (от memcached, redis и т.п.) или прямо в словари mapping'a текстовых полей в elasticsearch (синонимы/поисковые подсказки), то задержки будут минимальны, а качество контролируемо (для кеша/словарей можно будет легко вручную раз в день/неделю/месяц валидировать/вносить/накапливать корректировки, как для ошибочных исправлений, так и для новых, внезапно появившихся популярных понятий (например, "массажеры для тапания хомяка"), на которых модель не училась и не сможет адекватно исправить), при этом, если опечатка окажется уникальной (в очень небольшом % случаев, т.к. в словах возможных опечаток не бесконечно с учетом длины слов и расположения использующихся клавиатуры и со временем кеш будет полнее, а уникальных опечаток меньше), то пользователь получит свой результат поиска, а "лишних 400 миллисекунд подождать" будут не так огорчительны и мотивировать писать правильно.
Спасибо за очередной первоклассный обзорный материал! По желанию в раздел "(10) Гибридный поиск" можно было бы добавить текстовое упоминание еще одного ключевого этапа этого подхода - переранжирования, который графически отражен на картинке как "Cross-Encoder", т.е. при гибридном поиске мы комбинируем результаты обоих подходов и обязательно переранжируем их или специальными алгоритмами (Reciprocal Rank Fusion (RRF); Min-Max score normalization...) или отдельными ИИ моделями для оценки релевантности найденного запросу (Cross-Encoder... вплоть до LLM с вопросами "насколько баллов найденное ... соответствует запросу ...") и получаем улучшенную поисковую выдачу, а без переранживания гибридный поиск скорее всего будет работать хуже, чем просто отдельный лексический или семантический поиск. И, соотвественно, в этот же раздел или в "(5) Оптимизация структуры индекса" упомянуть совместно с алгоритмами еще и пример БД поддерживающих его OpenSearch/Elasticsearch, Milvus, Vespa, Qdrant... Ссылки по теме:
https://learn.microsoft.com/en-us/azure/search/hybrid-search-ranking
https://qdrant.tech/articles/hybrid-search/
https://opensearch.org/blog/hybrid-search/
https://milvus.io/docs/multi-vector-search.md
Имеет ли при инференсе большой квантованной модели значение для скорости на скольких GPU она запущена, например, на одной 80ГБ A100 или на двух 40ГБ A100 - т.е. участвуют ли при сетапе на N картах вторая...N'тая карты в вычислениях или просто являются расширением GPU Ram для весов/kv-кеша модели не поместившихся на первую карту? Ситуация всегда будет одинакова, или для архитектур как MoE она отличается (часто в новостях пишут, что для запуска надо, например, 4 40Гб A100 имея ввиду потребность модели в 160 Гб GPU Ram, а то, что это 2 карты 80Гб A100 не упоминают - м.б. есть причина)?
При weight-only квантизации что происходит с KV кешем - необходимая под него RAM автоматически уменьшается в соответствии (также кратно) с уменьшением размера квантованных весов относительно изначальных или KV кеш всегда квантуют отдельно при инференсе, например, во многих фреймворках есть опции - 16/8/4-bit KV Cache?
А если речь не о LLM, а о векторной модели, например, int8 quantized intfloat-multilingual-e5-large, то квантованными в ней будут только веса или выходные вектора из модели тоже будут в int8? Сейчас всё больше БД поддерживают разные числовые типы полей с векторами, но как получать вектора в таких типах из общедоступных моделей (optimum'ом можно делать или м.б. есть какие-то специальные инструменты)?
Спасибо, отличный теоретический материал, многое объяснил. А на практике вы какой актуальный общедоступный (в котором выкладывают модели) метод/формат квантизации по балансу в сохранении исходного качества модели/большей скорости/экономии GPU памяти могли бы порекомендовать: GPTQ / GGUF [2, 3, 4, 5, 6 and 8-bit] / AWQ / transformers [fp8/fp16]+bitsandbytes [4, 8-bit] / другой вариант и софт для инференса: transformers / llama.cpp / vLLM / другой?