#RAG #retriever
BM25 - это алгоритм векторного представления документов на основе одного конкретного документа и всей коллекции документов в целом. На выходе BM25 для каждого документа (параграфа/чанка) выдает разреженный вектор (который можно использовать для сравнения его с другими векторами). BM25 довольно старая и относительно простая технология. На фоне более популярных "эмбедингов" она должна была уже отмереть. Но нет, она живее всех живых :)
Все дело в том, что BM25 обучается (и применяется) непосредственно на ваших данных. В то время как эмбединги обучаются заранее на определенном корпусе документов, а затем применяются к ваши данным. Поэтому BM25 идеален для документов, в которых встречаются редкие слова: термины, коды, названия или специфичные фразы (например, в юридической или технической документации). Семантический же поиск (на эмбедингах) фокусируется на смысле и может пропустить узкоспециализированные термины и редкие слова, если они не встречались (или редко встречались) при обучении модели.
Как следствие, BM25 оказалась довольно эффективным для RAG. Его можно использовать либо отдельно, либо вместе с семантическим поиском - это называется гибридный поиск.
Но есть у BM25 одна проблема, и имя ей - IDF.
Технически BM25 — это эволюция алгоритма TF-IDF (который вы, надеюсь, проходили в школе дата сайнса :). Напомню, что расчет TF-IDF состоит из двух частей TF и IDF. Если очень упрощенно: это отношение TF к IDF, где TF это частота слов в текущем документ, а IDF это частота всех слов во всех документах (отличие BM25 от TF-IDF в том, что он еще учитывает длину подаваемых в него документов).
Так вот, если TF-часть зависит (и считается) только на том, что вы подаете на вход BM25, то IDF-часть должна считаться на всей коллекции документов. И если эта коллекция пополняется/изменяется (как часто бывает с RAG), то вместе с ней должна меняться и IDF-часть, после чего необходимо заново пересчитываться все вектора в коллекции.
Как с этим можно работать:
1. Решение в лоб: хранить отдельно все документы коллекции и при их изменении/пополнении постоянно пересчитывать все вектора.
2. Использовать предобученные модели. Например, bge-m3. Они умеют выдавать разреженные вектора. Но в отличие от классического BM25, они были обучены заранее на своем датасете и, как следствие, их IDF часть не надо пересчитывать - она у них константа. Это некий промежуточный вариант между точностью и сложностью поддержки решения.
3. Использовать специализированные векторные БД, которые берут расчет IDF части на себя и автоматически пересчитывают все вектора при изменении коллекции документов. Например, такой функционал есть в Qdrant: https://qdrant.tech/blog/qdrant-1.10.x/
И запомните самое главное: BM расшифровывается как Best Match, а 25 это номер эксперимента, которые привел к изобретению формулы :)
BM25 - это алгоритм векторного представления документов на основе одного конкретного документа и всей коллекции документов в целом. На выходе BM25 для каждого документа (параграфа/чанка) выдает разреженный вектор (который можно использовать для сравнения его с другими векторами). BM25 довольно старая и относительно простая технология. На фоне более популярных "эмбедингов" она должна была уже отмереть. Но нет, она живее всех живых :)
Все дело в том, что BM25 обучается (и применяется) непосредственно на ваших данных. В то время как эмбединги обучаются заранее на определенном корпусе документов, а затем применяются к ваши данным. Поэтому BM25 идеален для документов, в которых встречаются редкие слова: термины, коды, названия или специфичные фразы (например, в юридической или технической документации). Семантический же поиск (на эмбедингах) фокусируется на смысле и может пропустить узкоспециализированные термины и редкие слова, если они не встречались (или редко встречались) при обучении модели.
Как следствие, BM25 оказалась довольно эффективным для RAG. Его можно использовать либо отдельно, либо вместе с семантическим поиском - это называется гибридный поиск.
Но есть у BM25 одна проблема, и имя ей - IDF.
Технически BM25 — это эволюция алгоритма TF-IDF (который вы, надеюсь, проходили в школе дата сайнса :). Напомню, что расчет TF-IDF состоит из двух частей TF и IDF. Если очень упрощенно: это отношение TF к IDF, где TF это частота слов в текущем документ, а IDF это частота всех слов во всех документах (отличие BM25 от TF-IDF в том, что он еще учитывает длину подаваемых в него документов).
Так вот, если TF-часть зависит (и считается) только на том, что вы подаете на вход BM25, то IDF-часть должна считаться на всей коллекции документов. И если эта коллекция пополняется/изменяется (как часто бывает с RAG), то вместе с ней должна меняться и IDF-часть, после чего необходимо заново пересчитываться все вектора в коллекции.
Как с этим можно работать:
1. Решение в лоб: хранить отдельно все документы коллекции и при их изменении/пополнении постоянно пересчитывать все вектора.
2. Использовать предобученные модели. Например, bge-m3. Они умеют выдавать разреженные вектора. Но в отличие от классического BM25, они были обучены заранее на своем датасете и, как следствие, их IDF часть не надо пересчитывать - она у них константа. Это некий промежуточный вариант между точностью и сложностью поддержки решения.
3. Использовать специализированные векторные БД, которые берут расчет IDF части на себя и автоматически пересчитывают все вектора при изменении коллекции документов. Например, такой функционал есть в Qdrant: https://qdrant.tech/blog/qdrant-1.10.x/
И запомните самое главное: BM расшифровывается как Best Match, а 25 это номер эксперимента, которые привел к изобретению формулы :)
❤8👍4
Релизнулась одна из самых замечательных опенсорс моделей на русском языке - Qwen 3:
- Есть обычные версии: 0.6B, 1.7B, 8B, 14B, 32B.
- И есть MOE-версии: 30B-A3B, 235B-A22B.
- Контекст: 32K для моделей 0.6B-4B и 128K для остальных.
- Есть функция размышления (reasoning). Включается прямо в промте.
- Поддерживает 109 языков (включая русский).
- Лицензия: Apache 2.0.
Производительность на уровне топовых моделей (в том числе проприетарных).
Уже доступны в официальном чате: https://chat.qwen.ai/
Скчать: huggingface или modelscope
- Есть обычные версии: 0.6B, 1.7B, 8B, 14B, 32B.
- И есть MOE-версии: 30B-A3B, 235B-A22B.
- Контекст: 32K для моделей 0.6B-4B и 128K для остальных.
- Есть функция размышления (reasoning). Включается прямо в промте.
- Поддерживает 109 языков (включая русский).
- Лицензия: Apache 2.0.
Производительность на уровне топовых моделей (в том числе проприетарных).
Уже доступны в официальном чате: https://chat.qwen.ai/
Скчать: huggingface или modelscope
👍4
This media is not supported in your browser
VIEW IN TELEGRAM
#API #inference
RAG состоит из двух основных частей - ретривера и генератора (LLM). И самая дорогая по времени часть это LLM. Причем дорогая с большим отрывом. Например, DeepSeek R1 в среднем генерирует ответ 3-4 минуты. Это довольно долго. Пользователь может заскучать :)
Но есть способ частично скрасить это ожидание. LLM по своей природе работают в режиме авторегресии и на каждой итерации выдают ровно одно слово (токен). И так пока не закончат печатать весь текст.
Streaming это функция, которая позволяет выводит текст по мере его генерации, а не ждать пока LLM весь его напишет. Вы ее могли встречать в различных AI-чатах - там она включена по-умолчанию.
Но ее также можно задействовать и для локальных развертываний. В разных библиотеках она работает примерно одинаково. Вот как ее можно задействовать в связке с vLLM:
1. Запускаем сервис vLLM (например, как рассказано тут)
2. С помощью библиотеки openai стрим вызывается так:
З.Ы. Аналогично можно сделать и с помощью стандартны request и некоторых других инструментов.
RAG состоит из двух основных частей - ретривера и генератора (LLM). И самая дорогая по времени часть это LLM. Причем дорогая с большим отрывом. Например, DeepSeek R1 в среднем генерирует ответ 3-4 минуты. Это довольно долго. Пользователь может заскучать :)
Но есть способ частично скрасить это ожидание. LLM по своей природе работают в режиме авторегресии и на каждой итерации выдают ровно одно слово (токен). И так пока не закончат печатать весь текст.
Streaming это функция, которая позволяет выводит текст по мере его генерации, а не ждать пока LLM весь его напишет. Вы ее могли встречать в различных AI-чатах - там она включена по-умолчанию.
Но ее также можно задействовать и для локальных развертываний. В разных библиотеках она работает примерно одинаково. Вот как ее можно задействовать в связке с vLLM:
1. Запускаем сервис vLLM (например, как рассказано тут)
2. С помощью библиотеки openai стрим вызывается так:
from openai import OpenAI
client = OpenAI(base_url="https://192.168.0.107:8000/v1", api_key="any")
stream = client.chat.completions.create(
model = "/model",
messages = [
{"role": "system", "content": "Ты полезный ассистент."},
{"role": "user", "content": "Сколько весит Луна?"}
],
temperature = 0.1,
stream = True # Включаем потоковый режим
)
# Обрабатываем потоковый ответ
for chunk in stream:
if chunk.choices[0].delta.content is not None:
print(chunk.choices[0].delta.content, end="", flush=True)
З.Ы. Аналогично можно сделать и с помощью стандартны request и некоторых других инструментов.
👍2🔥2
#RAG
Допустим у нас есть RAG-система. И нам нужно ответить на вопрос по книжке "Дети капитана Гранта": как дети спасли капитана? Но ответ на этот вопрос это вся книжка. Обычный RAG с такой задачей не справится. Поэтому встречайте раг необычный - RAPTOR (Recursive Abstractive Processing for Tree-organized Retrieval). Как оно работает...
Формирование чанков:
1. Делим документ на чанки. Формируем для них вектора.
2. Берем всю кучу чанков и кластеризуем их по векторам. Причем кластеризуем мягким способом - один и тот же чанк может попасть в разные класетра.
3. С помощью LLM суммаризуем все кластера. Результат становится новым уровнем чанков.
4. Процесс повторяется рекурсивно, пока не сгенерируем нужно количество уровней (или не доберемся до корня).
В итоге у нас получается пирамида, на нижем уровне которого исходные чанка. На втором - кластеры из исходных чанков. На третьем - кластеры из кластеров второго уровня и т.д. И чем выше к вершине, тем больше в них содержится обощенной информации по всему документу.
Дальше нам нужно отобрать чанки для LLM. Для этого авторы придумали два способа:
1. Выбираем top-k наиболее подходящих (по косинусному расстоянию) корневых узлов. Затем к выборке добавляются их дочерние узлы и вновь выбираются наиболее подходящие из этого нового пула узлов. Процесс продолжается до тех пор, пока не дойдём до листьев.
2. Чанки всех уровней рассматриваются как равноправные и производится простой поиск по ним всем одновременно. З.Ы. И этот способ вроде как лучше.
Авторы проверили метод на нескольких датасетах (NarrativeQA, QuALITY, QASPER) и результаты превзошли другие методы.
Реализация метода от авторов: https://github.com/parthsarthi03/raptor
3.Ы. Можно фильтровать уровни чанков если вам для ответа на вопрос нужны исходные факты.
Допустим у нас есть RAG-система. И нам нужно ответить на вопрос по книжке "Дети капитана Гранта": как дети спасли капитана? Но ответ на этот вопрос это вся книжка. Обычный RAG с такой задачей не справится. Поэтому встречайте раг необычный - RAPTOR (Recursive Abstractive Processing for Tree-organized Retrieval). Как оно работает...
Формирование чанков:
1. Делим документ на чанки. Формируем для них вектора.
2. Берем всю кучу чанков и кластеризуем их по векторам. Причем кластеризуем мягким способом - один и тот же чанк может попасть в разные класетра.
3. С помощью LLM суммаризуем все кластера. Результат становится новым уровнем чанков.
4. Процесс повторяется рекурсивно, пока не сгенерируем нужно количество уровней (или не доберемся до корня).
В итоге у нас получается пирамида, на нижем уровне которого исходные чанка. На втором - кластеры из исходных чанков. На третьем - кластеры из кластеров второго уровня и т.д. И чем выше к вершине, тем больше в них содержится обощенной информации по всему документу.
Дальше нам нужно отобрать чанки для LLM. Для этого авторы придумали два способа:
1. Выбираем top-k наиболее подходящих (по косинусному расстоянию) корневых узлов. Затем к выборке добавляются их дочерние узлы и вновь выбираются наиболее подходящие из этого нового пула узлов. Процесс продолжается до тех пор, пока не дойдём до листьев.
2. Чанки всех уровней рассматриваются как равноправные и производится простой поиск по ним всем одновременно. З.Ы. И этот способ вроде как лучше.
Авторы проверили метод на нескольких датасетах (NarrativeQA, QuALITY, QASPER) и результаты превзошли другие методы.
Реализация метода от авторов: https://github.com/parthsarthi03/raptor
3.Ы. Можно фильтровать уровни чанков если вам для ответа на вопрос нужны исходные факты.
👍6❤1
#RAG #retriever
Query expansion (расширение запроса) - техника улучшения ретривера в RAG-системе. Заключается в добавления синонимов, связанных терминов или скрытых смыслов к исходному запросу.
Работает следующим образом:
1. На вход к нам поступает запрос пользователя.
2. Просим LLM расширить запрос:
2.1. Напрямую:
2.2. Или можем отдельно составить ключевые слова, а затем соединить их с исходным запросом вручную:
3. Далее осуществляем поиск чанков как обычно.
Пример:
- Исходный запрос:
- Расширенный запрос:
По задумке это должно увеличить количество релевантных документов, которое вернет ретривер, если исходный запрос скудный на детали или не совсем точный.
Query expansion (расширение запроса) - техника улучшения ретривера в RAG-системе. Заключается в добавления синонимов, связанных терминов или скрытых смыслов к исходному запросу.
Работает следующим образом:
1. На вход к нам поступает запрос пользователя.
2. Просим LLM расширить запрос:
2.1. Напрямую:
Добавь к следующему запросу ключевые слова или синонимы, которые помогут найти больше информации: {query}
2.2. Или можем отдельно составить ключевые слова, а затем соединить их с исходным запросом вручную:
Приведи 5 ключевых слов или фраз, которые семантически связаны с запросом: {query}. Ответ выдай в виде списка через запятую.
3. Далее осуществляем поиск чанков как обычно.
Пример:
- Исходный запрос:
Лечение головной боли
- Расширенный запрос:
Лечение головной боли, мигрень, анальгетики, таблетки от боли
По задумке это должно увеличить количество релевантных документов, которое вернет ретривер, если исходный запрос скудный на детали или не совсем точный.
👍6
Запилил на Степике курс - Разработка LLM с нуля
В курсе вам предстоит с нуля реализовать все основные компоненты LLM:
- Токенизатор (BPE)
- Эмбеддинги (Токенов и Позиционные)
- Блок Декодера:
- Multi-Head Attention
- FeedForward-слои
- Остаточные связи
- Вероятностная генерация
После чего мы соберем и подготовим датасет и обучим свою LLM (pre-train).
Разработка будет вестиcь на Python и низкоуровневых компонентах PyTorch.
Курс платный. По промокоду ALL предоставляется скидка 10%.
В курсе вам предстоит с нуля реализовать все основные компоненты LLM:
- Токенизатор (BPE)
- Эмбеддинги (Токенов и Позиционные)
- Блок Декодера:
- Multi-Head Attention
- FeedForward-слои
- Остаточные связи
- Вероятностная генерация
После чего мы соберем и подготовим датасет и обучим свою LLM (pre-train).
Разработка будет вестиcь на Python и низкоуровневых компонентах PyTorch.
Курс платный. По промокоду ALL предоставляется скидка 10%.
🔥16👏2
#RAG #retriever
Выше я написал способ (query expansion), который позволяет обогатить запрос поданный в RAG-систему. Нужен он потому, что исходный запрос может быть неинформативным, нечётким или слишком коротким, что затрудняет поиск релевантных документов (чанков). А query expansion позволяет это исправить. Способ простой и явный. Но есть более интересный способ добиться примерно похожего результата - называется HyDE (Hypothetical Document Embeddings).
Как он работает:
1. Получаем запрос пользователя.
2. Подаем его в LLM как есть и просим ответить на него как есть (без всякого контекста).
3. Получаем ответ от LLM. Переводим его в вектор и уже по этому вектору ищем чанки (в вашем случае ретривер может отработать и более сложным образом).
4. Найденные чанки вместе с исходным запросом подаем в LLM для формирования финального ответа.
Пример:
Запрос:
Гипотетический ответ:
Как результат гипотетический ответ содержит больше контекста (более семантически насыщенный), чем исходный запрос, что улучшает качество поиска.
Выше я написал способ (query expansion), который позволяет обогатить запрос поданный в RAG-систему. Нужен он потому, что исходный запрос может быть неинформативным, нечётким или слишком коротким, что затрудняет поиск релевантных документов (чанков). А query expansion позволяет это исправить. Способ простой и явный. Но есть более интересный способ добиться примерно похожего результата - называется HyDE (Hypothetical Document Embeddings).
Как он работает:
1. Получаем запрос пользователя.
2. Подаем его в LLM как есть и просим ответить на него как есть (без всякого контекста).
3. Получаем ответ от LLM. Переводим его в вектор и уже по этому вектору ищем чанки (в вашем случае ретривер может отработать и более сложным образом).
4. Найденные чанки вместе с исходным запросом подаем в LLM для формирования финального ответа.
Пример:
Запрос:
Как работают квантовые компьютеры?
Гипотетический ответ:
Квантовые компьютеры используют принципы квантовой механики, такие как суперпозиция и запутанность, чтобы выполнять вычисления. В отличие от классических битов, кубиты могут находиться в нескольких состояниях одновременно...
Как результат гипотетический ответ содержит больше контекста (более семантически насыщенный), чем исходный запрос, что улучшает качество поиска.
👍4
#benchmark #chunk
С популярностью RAG (и LLM в целом) свою популярность обрели и специализированные векторные БД.
Их используют для хранения различных текстов и векторов к ним. И развелось их прям очень много. Есть как отдельные приложения, так и дополнения к популярным "классическим" БД. Из наиболее известных: Qdrant, Milvus, Weaviate, Marqo, Lancedb и т.д.
А этот сайтик поможет вам выбрать подходящую векторную БД по куче параметров: https://superlinked.com/vector-db-comparison
Еще есть бенчмарки по векторным БД. Вроде этого: https://ann-benchmarks.com/index.html
Есть еще бенчмарки от самих производителей векторных БД. Но относится к ним нужно с некоторой долей скептицизма:
- https://zilliz.com/vector-database-benchmark-tool
- https://qdrant.tech/benchmarks/
С популярностью RAG (и LLM в целом) свою популярность обрели и специализированные векторные БД.
Их используют для хранения различных текстов и векторов к ним. И развелось их прям очень много. Есть как отдельные приложения, так и дополнения к популярным "классическим" БД. Из наиболее известных: Qdrant, Milvus, Weaviate, Marqo, Lancedb и т.д.
А этот сайтик поможет вам выбрать подходящую векторную БД по куче параметров: https://superlinked.com/vector-db-comparison
Еще есть бенчмарки по векторным БД. Вроде этого: https://ann-benchmarks.com/index.html
Есть еще бенчмарки от самих производителей векторных БД. Но относится к ним нужно с некоторой долей скептицизма:
- https://zilliz.com/vector-database-benchmark-tool
- https://qdrant.tech/benchmarks/
🔥5
Structured output (SO) это различные способ заставить LLM выдавать строго нужный ответ в строго определенном формате. Например в формате JSON. SO довольно большая тема, в ней есть много техник и подходов. Начнем ее рассмотрение с нескольких простых задач и самой простой реализации с помощью vLLM.
1. Сначала запустим vLLM сервер, как описано тут.
2. Подлючаимся к серверу:
А дальше...
Кейс 1
Допустим вам нужно с помощью LLM классифицировать какой-либо текст. И у вас есть набор строго определенных классов. Если вы просто промтом поставите перед LLM задачу и попросите написать только один из классов, то с некоторой вероятность LLM докинет к ответу еще какого-нибудь текста. И вам придется дополнительно проводить постобработку.
Вместо этого можно, можно сделать так:
Кейс 2
Нам нужно сгенерировать фейковые адреса электронной почты (для шаблона сайта, например). На выходе нам нужен только адрес в правильной форме.
Кейс 3
Мы хотим вытащить из какого-либо текста (например, объявления) определенные данные в формате JSON.
Более подробно можно почитать тут: https://docs.vllm.ai/en/stable/features/structured_outputs.html?h
1. Сначала запустим vLLM сервер, как описано тут.
2. Подлючаимся к серверу:
from openai import OpenAI
client = OpenAI(
base_url="https://192.168.0.108:8000/v1",
api_key="any"
)
А дальше...
Кейс 1
Допустим вам нужно с помощью LLM классифицировать какой-либо текст. И у вас есть набор строго определенных классов. Если вы просто промтом поставите перед LLM задачу и попросите написать только один из классов, то с некоторой вероятность LLM докинет к ответу еще какого-нибудь текста. И вам придется дополнительно проводить постобработку.
Вместо этого можно, можно сделать так:
completion = client.chat.completions.create(
model="/model",
messages=[
{"role": "system", "content": "Ты полезный ассистент."},
{"role": "user", "content": "Классифицируй этот отзыв: С удовольствием и интересом посмотрел этот фильм. "}
],
extra_body={"guided_choice": ["positive", "negative"]}
)
print(completion.choices[0].message.content)
Кейс 2
Нам нужно сгенерировать фейковые адреса электронной почты (для шаблона сайта, например). На выходе нам нужен только адрес в правильной форме.
completion = client.chat.completions.create(
model="/model",
messages=[
{"role": "system", "content": "Ты полезный ассистент."},
{"role": "user", "content": "Сгенерируй адрес электронной почты."}
],
extra_body={"guided_regex": r"\w+@\w+\.com"},
)
print(completion.choices[0].message.content)
Кейс 3
Мы хотим вытащить из какого-либо текста (например, объявления) определенные данные в формате JSON.
from pydantic import BaseModel
from enum import Enum
class EstateType(str, Enum):
house = "дом"
apartment = "квартира"
class CarDescription(BaseModel):
price: int
square: int
area: int
estate_type: EstateType
json_schema = CarDescription.model_json_schema()
completion = client.chat.completions.create(
model="/model",
messages=[
{"role": "system", "content": "Ты полезный ассистент."},
{
"role": "user",
"content": """Вытащи из следующего объявления инфомрмацию в формате JSON:
{
price: цена в рублях,
square: площадь дома в кв. м.,
area: площадь участка в сотках,
estate_type: дом или квартира
}
=== Объявление ===
Предлагаем купить теплый двухэтажный кирпичный коттедж площадью 225 кв. м. для круглогодичного проживания дружной семьи, предпочитающей уют и свободу.
На первом этаже – просторная уютная гостиная с камином, шикарным диваном, кухня, отделенная от столовой барной стойкой, кладовая, санузел.
Два выхода – центральный и на задний дворик. На втором этаже – три спальни с балконами, два санузла с ванными.
В каждой комнате установлены радиаторы. Все комнаты меблированы. Новый, стильный ремонт.
Перед входом – парковка для двух автомобилей. Участок – 5 соток, есть зона для барбекю, веранда, баня.
До ближайшей автобусной остановки – 300 м. В пешей доступности есть продуктовый магазин, аптека, детская площадка.
Дом сдан в эксплуатацию. Документы для продажи готовы.
Цена: 10 млн.р."""
}
],
extra_body={"guided_json": json_schema},
)
print(completion.choices[0].message.content)
Более подробно можно почитать тут: https://docs.vllm.ai/en/stable/features/structured_outputs.html?h
👍8❤1🐳1
#free
Вчера вышла модель Kimi K2. Судя по анонсу, модель сильно заточена на программирование: на бенчмарке SWE-bench Verified превосходит такие модели как Claude Sonnet 4 и GPT-4.1.
Модель опенсорсная: https://huggingface.co/moonshotai/Kimi-K2-Instruct
Но есть нюанс: у нее 1 трлн параметров :) А значит дома ее не погонять. Казалось бы на этом можно и заканчивать, но есть кое-что поинтереснее.
У нас появился новый чатик: https://www.kimi.com/
Бегло поигрался с ним. Вроде пишет неплохо. На уровне чатов DeepSeek и Qwen. И также не нужен никакой ВПН.
Вчера вышла модель Kimi K2. Судя по анонсу, модель сильно заточена на программирование: на бенчмарке SWE-bench Verified превосходит такие модели как Claude Sonnet 4 и GPT-4.1.
Модель опенсорсная: https://huggingface.co/moonshotai/Kimi-K2-Instruct
Но есть нюанс: у нее 1 трлн параметров :) А значит дома ее не погонять. Казалось бы на этом можно и заканчивать, но есть кое-что поинтереснее.
У нас появился новый чатик: https://www.kimi.com/
Бегло поигрался с ним. Вроде пишет неплохо. На уровне чатов DeepSeek и Qwen. И также не нужен никакой ВПН.
❤1👍1🔥1
#free
Больше чатиков богу чатиков :)
Сегодня вышли две новые MOE модели:
- GLM‑4.5: 355B параметров (32B активных)
- GLM‑4.5‑Air: 106B параметров (12B активных)
З.Ы. Веса опубликованы только для базовых моделей.
Показатели бенчмарков на уровне SOTA-моделей. MIT‑лицензия.
Но самое интересное... У нас появился новый чатик (на уровне чатов квена, дипсика и пр.) - https://chat.z.ai
Больше чатиков богу чатиков :)
Сегодня вышли две новые MOE модели:
- GLM‑4.5: 355B параметров (32B активных)
- GLM‑4.5‑Air: 106B параметров (12B активных)
З.Ы. Веса опубликованы только для базовых моделей.
Показатели бенчмарков на уровне SOTA-моделей. MIT‑лицензия.
Но самое интересное... У нас появился новый чатик (на уровне чатов квена, дипсика и пр.) - https://chat.z.ai
👍4
#RAG #retriever
Multi-query - еще одна техника улучшения ретривера в RAG-системе.
Когда пользователи пишут вопросы (в RAG) они часто допускают ошибки, пишут транслитом, путаются в формулировках и т.д. А это не хорошо для энкодера, и очень не хорошо для BM25 (и других компонентов ретривера). Multi-query позволяет это исправить за счёт разных формулировок одного и того же вопроса.
Как это работает:
1. Получаем исходный запрос.
2. Просим LLM написать несколько вариантов исходного запроса.
3. Выполняем поиск документов (чанков) по каждому из них (включая и исходный запрос).
4. Результаты всех поисков объединяем или переаранжируем.
Например: пользователь вводит: "Как испечь торт?"
LLM на это может сгенерировать:
- "Рецепт торта"
- "Как приготовить торт в духовке?"
- "Ингредиенты для домашнего торта"
Такое разнообразие довольно сильно улучшает покрытие поисковой выдачи.
Дополнительно:
1. Можно попросить переформулировать запрос в каком-либо стиле. Например, если запросы на медицинскую тематику, то можно сделать так: "Перепиши вопрос так, как будто его писал врач с многолетним опытом работы".
2. Отдельно можно попросить перевести запрос на английский.
Multi-query - еще одна техника улучшения ретривера в RAG-системе.
Когда пользователи пишут вопросы (в RAG) они часто допускают ошибки, пишут транслитом, путаются в формулировках и т.д. А это не хорошо для энкодера, и очень не хорошо для BM25 (и других компонентов ретривера). Multi-query позволяет это исправить за счёт разных формулировок одного и того же вопроса.
Как это работает:
1. Получаем исходный запрос.
2. Просим LLM написать несколько вариантов исходного запроса.
3. Выполняем поиск документов (чанков) по каждому из них (включая и исходный запрос).
4. Результаты всех поисков объединяем или переаранжируем.
Например: пользователь вводит: "Как испечь торт?"
LLM на это может сгенерировать:
- "Рецепт торта"
- "Как приготовить торт в духовке?"
- "Ингредиенты для домашнего торта"
Такое разнообразие довольно сильно улучшает покрытие поисковой выдачи.
Дополнительно:
1. Можно попросить переформулировать запрос в каком-либо стиле. Например, если запросы на медицинскую тематику, то можно сделать так: "Перепиши вопрос так, как будто его писал врач с многолетним опытом работы".
2. Отдельно можно попросить перевести запрос на английский.
👍4