Тогда если имеется, то для 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 / другой?
Тогда если имеется, то для 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 / другой?