GIGACHAT MAX vs GPT4o (Гигачат победил?) 😎
Кажется, про RAG написали уже все, кому не лень. Но я хочу показать один из корнер-кейсов, которых уже в сети не так уж и много.
Начнём с архитектуры. Есть стандартная схема — Hybrid Search, где совмещается лексический поиск (BM25Retriever, знакомый каждому по простому Ctrl+F) и семантический поиск (тот самый умный, на embedding-моделях). Из каждой системы берутся топ-25 документов, а затем на сцену выходит reranker-модель (cross-encoder), которая внимательно смотрит и на запрос пользователя, и на документы, выбирая только топ-5 самых полезных и релевантных.
Чтобы улучшить качество поиска, используется query expansion — по сути, это «переписывание запроса». Пользователь часто ошибается, пишет транслитом, путается в формулировках. Но стоит лишь попросить LLM аккуратно переформулировать запрос для поиска — и дело сделано. Но всегда ли?
Итак, две системы. Они совершенно идентичны: те же embedder, тот же reranker, те же промпты. Единственная разница — в LLM (одна модель - отечественная: GigaChat MAX, а вторая - GPT4o), и вот тут начинается самое интересное.
САМ КЕЙС: 😵💫
Системы проходят проверку на простом запросе: «Что такое разбрасыватель?» (имеется в виду сельскохозяйственная техника).
GPT4o внезапно ведёт себя крайне нестабильно (при температуре всего 0.2!): то в ответе появляются непонятные цифры, то сухие строчки из Википедии без конкретики. Что показатель явных галлюцинаций модели, чего бы очень хотелось избежать!
А вот GigaChat MAX поражает своей стабильностью и четкостью, всегда выдавая конкретный, развернутый, полезный ответ.
Но почему же так происходит? 😳
В поисках ответа я взял под лупу каждый компонент системы. Документы о тракторах разных компаний, вроде всё понятно. Но вдруг — странность! При использовании GPT4o запрос пользователя каждый раз расширяется дополнительно названием компании («Что такое разбрасыватель Kverneland?»), хотя GigaChat MAX оставляет запрос нетронутым. [название компании обеим ллм известны заранее. И поиск делается по каждой компании в отдельной коллекции Milvus и в отдельном индексе OpenSearch]
Казалось бы, GPT4o делает лучше, точнее уточняет запрос, качество поиска должно быть ого-го, но...
Разгадка загадки скрывалась в одном простом факте: слово «Kverneland» встречается крайне редко. Как известно из статей, attention-механизм особенно чувствителен к редким словам (аналогично и BM25). Документов с упоминанием компании много, и внимание системы невольно переключается именно на упоминание компании, а не на главный предмет вопроса — «разбрасыватель». Итог — мусор в выдаче и нестабильность ответов.
А вот GigaChat MAX, не добавляя лишних деталей, сохраняет стабильность выдачи и всегда отвечает четко, конкретно и по делу.
Такой вот неожиданный поворот — иногда чем проще, тем лучше!
Технические детали:
- Embedder: bge-m3 (chunk_size=1200, overlap=300).
- Reranker: bge-reranker-v2-m3.
Это сочетание дало лучшие результаты именно в моём домене (естественно, они взяты не на обум и проводились сотни экспериментов (и сотни тысяч рублей), чтобы это вычислить на моих документах). Были перепробованы все опенсорс эмбеддеры, реранкеры (в том числе на основе декодеров), обученные на русский и английский язык
Документы в основном на русском и английском языке.
RAG - сам по себе прост, но очень много нюансов нужно решить в своём домене. Я уж не говорю про парсинг документов / таблиц / графиков, использование SO + CoT и т.д.
Напишите в комментах, работали ли с RAG, какие у вас были забавные случаи?
Картинки к посту будут в комментах 👇
Кажется, про RAG написали уже все, кому не лень. Но я хочу показать один из корнер-кейсов, которых уже в сети не так уж и много.
Начнём с архитектуры. Есть стандартная схема — Hybrid Search, где совмещается лексический поиск (BM25Retriever, знакомый каждому по простому Ctrl+F) и семантический поиск (тот самый умный, на embedding-моделях). Из каждой системы берутся топ-25 документов, а затем на сцену выходит reranker-модель (cross-encoder), которая внимательно смотрит и на запрос пользователя, и на документы, выбирая только топ-5 самых полезных и релевантных.
Чтобы улучшить качество поиска, используется query expansion — по сути, это «переписывание запроса». Пользователь часто ошибается, пишет транслитом, путается в формулировках. Но стоит лишь попросить LLM аккуратно переформулировать запрос для поиска — и дело сделано. Но всегда ли?
Итак, две системы. Они совершенно идентичны: те же embedder, тот же reranker, те же промпты. Единственная разница — в LLM (одна модель - отечественная: GigaChat MAX, а вторая - GPT4o), и вот тут начинается самое интересное.
САМ КЕЙС: 😵💫
Системы проходят проверку на простом запросе: «Что такое разбрасыватель?» (имеется в виду сельскохозяйственная техника).
GPT4o внезапно ведёт себя крайне нестабильно (при температуре всего 0.2!): то в ответе появляются непонятные цифры, то сухие строчки из Википедии без конкретики. Что показатель явных галлюцинаций модели, чего бы очень хотелось избежать!
А вот GigaChat MAX поражает своей стабильностью и четкостью, всегда выдавая конкретный, развернутый, полезный ответ.
Но почему же так происходит? 😳
В поисках ответа я взял под лупу каждый компонент системы. Документы о тракторах разных компаний, вроде всё понятно. Но вдруг — странность! При использовании GPT4o запрос пользователя каждый раз расширяется дополнительно названием компании («Что такое разбрасыватель Kverneland?»), хотя GigaChat MAX оставляет запрос нетронутым. [название компании обеим ллм известны заранее. И поиск делается по каждой компании в отдельной коллекции Milvus и в отдельном индексе OpenSearch]
Казалось бы, GPT4o делает лучше, точнее уточняет запрос, качество поиска должно быть ого-го, но...
Разгадка загадки скрывалась в одном простом факте: слово «Kverneland» встречается крайне редко. Как известно из статей, attention-механизм особенно чувствителен к редким словам (аналогично и BM25). Документов с упоминанием компании много, и внимание системы невольно переключается именно на упоминание компании, а не на главный предмет вопроса — «разбрасыватель». Итог — мусор в выдаче и нестабильность ответов.
А вот GigaChat MAX, не добавляя лишних деталей, сохраняет стабильность выдачи и всегда отвечает четко, конкретно и по делу.
Такой вот неожиданный поворот — иногда чем проще, тем лучше!
Технические детали:
- Embedder: bge-m3 (chunk_size=1200, overlap=300).
- Reranker: bge-reranker-v2-m3.
Это сочетание дало лучшие результаты именно в моём домене (естественно, они взяты не на обум и проводились сотни экспериментов (и сотни тысяч рублей), чтобы это вычислить на моих документах). Были перепробованы все опенсорс эмбеддеры, реранкеры (в том числе на основе декодеров), обученные на русский и английский язык
Документы в основном на русском и английском языке.
RAG - сам по себе прост, но очень много нюансов нужно решить в своём домене. Я уж не говорю про парсинг документов / таблиц / графиков, использование SO + CoT и т.д.
Напишите в комментах, работали ли с RAG, какие у вас были забавные случаи?
Картинки к посту будут в комментах 👇