Обновление #3 в бенче ContextTrap : FractalGPT, T-lite, Gemma2, Mistral-Nemo, Claude Haiku, GLM4, GPT-4o-mini, DeepSeek-Coder-V2, GPT-3.5, Jamba-instruct, Nemotron-4-340b-instruct
Продолжаю публиковать новые результаты моего бенчмарка ContextTrap, специализированного на оценке способностей LLM работать с русским контекстом. Всего протестировано 46 моделей в разных конфигурациях. Ниже будут некоторые комментарии к новым моделям в списке.
Привет, спасибо за тест, это как глоток свежей воды, на русском очень мало бенчмарков.
Добавлю пару нюансов, который в основном касаются методологии тестирования.
1. В целом верно, что не полностью корректно сравнивать RAG систему и голые модели. Тут может быть два эффекта:
а) результат RAG системы может быть лучше, при более слабой модели потому, что внутри эмбеддер и поиск уменьшают контекст, поэтому модели нужно отвечать уже по тексту, где точно есть ответ и он очень сжатый. Конечно голая модель вынуждена отвечать по всему контексту, от этого результат может быть хуже.
б) вообще потенциал RAG раскрывается на длинных документах, более 4000 токенов, по сути ограничения на длину нет. То есть RAG система и дешевле и качественнее работает с большими документами.
Например, если даже брать модель с огромным контекстом типа 200к(и более) то стоимость одного запроса может быть и $0.5 долл и вырасти до 1 долл, и все равно этого не хватит, тк у бизнеса документы длиной миллиарды токенов, и все равно их надо как-то нарезать. А вот у RAG системы стоимость не зависит от длины базы знаний компании и составляет порядка $0.2-0.3, даже для гигабайтного документа.
И вся соль в алгоритмах RAG - если они плохие, то качество упадет, а если хорошие, типа графового подхода от Microsoft https://github.com/microsoft/graphrag (похож на FractalGPT) то вырастет.
В общем сервисы можно выделить в отдельную категорию, а там и chatpdf, docsbotai, опен-сорс либы.
2. А могли бы вы рассказать, как реализован пункт Ensemble 8 models ?
Думаю многим это интересно, т.к. сейчас же тренд на агентность - и как раз агенты, каждый из которых решает свою задачу могут супер повышать качество всего продукта. Например более сложный вопрос может направляться на бОльшую модель, а простой - на легкую, зачем тратить деньги, если он простой и мы уверены, что получим ответ и на 3b модели.
В будущем бенчмарк круто было бы расширить и на всякие модальности: то что я знаю бизнес прям плачет и просит работу с таблицами и картинками, там много проблем.
Спасибо за комментарий. Поскольку я протестировал десятки моделей вручную и прочитал все их ответы на вопросы бенчмарка, постепенно у меня сложилось наблюдение, что каждая модель хорошо отвечает на одну часть вопросов, но плохо на другую. Так возникла идея просто свести в единую таблицу все правильные ответы от моделей 7-9Б. Оказалось, что они покрыли правильными ответами почти все вопросы. Другими словами, я не использовал никакой хитрый роутер это просто сводная таблица правильных ответов от каждой модели.
Здесь я более подробно разобрал тему
https://vc.ru/dev/1278594-otkrovenie-mesyaca-ansambl-iz-8-otdelnyh-modelei-7-9b-v-benche-contexttrap-dostigayut-urovnya-cloud-3-opus
>>результат RAG системы может быть лучше, при более слабой модели потому, что внутри эмбеддер и поиск уменьшают контекст,
Конечно, если к пункту:
"Пункт 23. Штраф - 100 тысяч, а перечень нарушений указаны в пункте 15. "
добавить вверх содержание пункта 15,
Пункт 15. Перечень нарушений: распитие алкоголя, курение в неположенном месте, нахождение не объекте в нетрезвом виде или без спецодежды...
то более слабая модель легче ответит на вопрос "есть ли штраф за алкоголь". Такие обработки должны возлагаться на RAG систему. Более мощная модель также может споткнуться на ссылки внутри документов. Причем сам документ может быть всего 2К токенов. Само собой если пункт 15 находится на 3 странице, а пункт 23 уже на 20 странице, за пределами длины контекста модели - то RAG просто необходим.