Спасибо, очень интересный опыт и познавательная публикация. Интересно, используете ли вы реранкеры (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'у и факт-чекингу).
Тогда если имеется, то для Unsloth не прикрепите к статье notebook/colab? В статье указано, что 4 bit Unsloth сильно отстает, но, судя по упоминанию собственного фреймворка на его основе - он неплохой, а значит ли это, что по возможности просто не рекомендуется их 4 бит модели использовать или может быть еще какие то замечания к нему есть? Например, сильно ли будет код для Instruct модели от base отличаться, а то у них только для base модели пример есть и непонятно как его на рекомендуемую в статье instruct модель переписать.
Есть ли причины, по которым выбор пал на Llama-3 и axolotl - не пробовали другие фреймворки(trl, ...)/модели (Mistral, Qwen, ...)? Можно ли было в качестве базовой модели для sft использовать Suzume? 2 карты A100 используются для ускорения обучения или на одну карту для тренировки базовая модель не влезала?
Спасибо за публикацию. Вы не сравнивали качество своего решения с моделями 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 / другой?
Спасибо, очень интересный опыт и познавательная публикация. Интересно, используете ли вы реранкеры (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'у и факт-чекингу).
Тогда если имеется, то для Unsloth не прикрепите к статье notebook/colab? В статье указано, что 4 bit Unsloth сильно отстает, но, судя по упоминанию собственного фреймворка на его основе - он неплохой, а значит ли это, что по возможности просто не рекомендуется их 4 бит модели использовать или может быть еще какие то замечания к нему есть? Например, сильно ли будет код для Instruct модели от base отличаться, а то у них только для base модели пример есть и непонятно как его на рекомендуемую в статье instruct модель переписать.
Есть ли причины, по которым выбор пал на Llama-3 и axolotl - не пробовали другие фреймворки(trl, ...)/модели (Mistral, Qwen, ...)? Можно ли было в качестве базовой модели для sft использовать Suzume? 2 карты A100 используются для ускорения обучения или на одну карту для тренировки базовая модель не влезала?
Спасибо за публикацию. Вы не сравнивали качество своего решения с моделями 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 / другой?