Forwarded from NLP Wanderer
Мы выпускаем в релиз свои лучшие модели и тулкит алайнмента. который использовался для их тренировки.
Итак, наш флагман - Vikhr-Nemo-12B-Instruct-R-21-09-24 (карточка на HF)
12B модель на основе Mistral-Nemo, с качеством на русском языке в некоторых задачах не хуже gpt-4o-mini и имеет 128к токенов контекста, была специально заалайнена под решение широкого спектра задач на реальных и синтетических вопросах пользователей, включая код, математику, суммаризацию, ризонинг, ответы в специальном формате (JSON/HTML и тд) и многие другие.
Модель получила винрейт 79.8 (относительно gpt-3.5-turbo) на оффлайн бенчмарке Ru-General-Arena, что лучше любой текущей опенсорс модели до 30В для русского языка.
Для достижения такого качества мы собрали большой инструктивный датасет со втроенным CoT, что позволило сильно прочкать ризонинг модели, далее обучили Reward модель, сделали Rejection Sampling и применили собственный метод SMPO (вариация DPO) для выполнения преференс-тюнинга.
Вторая модель - Vikhrmodels/Vikhr-Llama3.1-8B-Instruct-R-21-09-24 (карточка на HF)
Так же обучена Llama-3,1-8B и имеет аналогичный размер контекста в 128k токенов. Винрейт на Ru-Arena-General - 63.9, что делает ее одной из лучших 8B моделей дла русского языка.
Модели обучены работать с RAG
Обе модели имеют уникальную особенность - они заалайнены для работы с RAG, т.е. используя системный промпт и спец. роль documents, вы сможете подавать ей документы в стандартизированной форме (JSON). При этом сам текст каждого документа может быть грязным чанком HTML, Markdown или Plain text формата до 4к символов каждый.
Модели умеют выделять информацию из предоставленных документов самостоятельно, реализуя таким образом "реранкер" на уровне LLM. Это сделано за счет двух-этапного ответа. Первый ответ модели представляет из себя JSON со списокм релевантных идентификаторов документов, а второй, если юзер его запросит, будет уже текстовым ответом модели на вопрос пользователя.
Благодаря такому обучению, на нашем бенчмарке для RAG (судья gpt-4o) Vikhr-Nemo показала качество в RAG задачах даже лучше, чем gpt-4o-mini (цифры в карточках моделей)
SMPO - Simple Margin Preference Optimization
Наш собственный метод выравнивания, разработанный для стабилизации прцоесса PO. Этот метод во многом заимствует идеи IPO, SimPO, C-RLFT, а также содержит собственную функцию потерь для разделения выбранных и отклоненных пар, отказываясь от классической сигмойды.
Основная идея метода заключается в стремлении плавно достичь желаемого уровня margin, не заставляя модель переобучаться, в том числе с помощью добавления балансирующего SFT лосса для выбранных и отклоненных вариантов одновременно.
Тулкит на Github - effective_llm_alignment
Репозиторий содержит скрипты и конфиги которые использовались для всех этапов обучения моделей. он позволяет удобно работать с основными методами алайнмента для LLM, включая наш SMPO.
Больше подробностей о моделях, как с ними работать, бенчмарках, процедуре обучения, вы можете найти в их карточках на HF.
Поиграться с Vikhr-Nemo-12B можно в tg bot_e (@vikhrbot), Gradio инференс
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Анализ данных (Data analysis)
Большинство моделей от Mistral теперь доступны бесплатно по API 😱
Что за аттракцион невиданной щедрости? Вероятно, ваши запросы будут использованы для обучения новых моделей (хотя это не точно).
VPN не требуется, карта не нужна. Пользуйтесь!
@data_analysis_ml
Что за аттракцион невиданной щедрости? Вероятно, ваши запросы будут использованы для обучения новых моделей (хотя это не точно).
VPN не требуется, карта не нужна. Пользуйтесь!
@data_analysis_ml
Forwarded from Vikhr models
Mcts-lib
Мы релизнули либу для улучшения генераций за счет MCTS(+10 пунктов по ru General Arena)!
Как это работает?
1. (Инициализация): Представьте, что вы начинаете с первой версии ответа, который модель предлагает. Чтобы не попасть в ловушку одного-единственного мнения с самого начала, модель также добавляет запасной вариант вроде “Я не знаю”. Это как стартовая точка, которая позволяет не зацикливаться на первой попытке.
2. (Selection): Из всех возможных вариантов ответа мы ищем тот, который выглядит самым перспективным, но при этом ещё не был полностью изучен. Это похоже на то, как вы бы выбирали, на какой вопрос или задачу потратить своё время дальше, полагаясь на интуицию и текущие знания.
3. (Self-Refine): Теперь, когда выбрали ответ, мы пытаемся его улучшить. Представьте, что вы показываете свой ответ опытному другу, и он говорит вам, что можно улучшить. Модель делает что-то похожее – она сама генерирует советы и, следуя этим подсказкам, старается улучшить ответ.
4. (Self-Evaluation): После того как ответ был доработан, модель оценивает его. Это как если бы вы сами посмотрели на свой улучшенный ответ и подумали: “Насколько это хорошо? Честно ли я оцениваю свой труд?” Чтобы оценка была объективной, модель специально избегает ставить идеальные баллы, чтобы не обманывать себя.
5. (Backpropagation): Если улучшенный ответ оказался хорош, эта информация передаётся обратно к родительскому узлу и другим связанным ответам. Это как если бы вы поделились своим новым знанием с друзьями, чтобы все в группе тоже стали умнее.
6.Актуализация планов (UCT Update): Когда все оценки обновлены, модель пересматривает свои планы и решает, какие варианты стоит изучить дальше. Здесь работает формула, которая помогает ей оценить, куда лучше направить внимание в следующий раз, чтобы стать ещё более эффективной.
Работает с openapi like apiшками, можно и llamacpp подключить и gpt4o!
github
оригинальный папир
Мы релизнули либу для улучшения генераций за счет MCTS(+10 пунктов по ru General Arena)!
Как это работает?
1. (Инициализация): Представьте, что вы начинаете с первой версии ответа, который модель предлагает. Чтобы не попасть в ловушку одного-единственного мнения с самого начала, модель также добавляет запасной вариант вроде “Я не знаю”. Это как стартовая точка, которая позволяет не зацикливаться на первой попытке.
2. (Selection): Из всех возможных вариантов ответа мы ищем тот, который выглядит самым перспективным, но при этом ещё не был полностью изучен. Это похоже на то, как вы бы выбирали, на какой вопрос или задачу потратить своё время дальше, полагаясь на интуицию и текущие знания.
3. (Self-Refine): Теперь, когда выбрали ответ, мы пытаемся его улучшить. Представьте, что вы показываете свой ответ опытному другу, и он говорит вам, что можно улучшить. Модель делает что-то похожее – она сама генерирует советы и, следуя этим подсказкам, старается улучшить ответ.
4. (Self-Evaluation): После того как ответ был доработан, модель оценивает его. Это как если бы вы сами посмотрели на свой улучшенный ответ и подумали: “Насколько это хорошо? Честно ли я оцениваю свой труд?” Чтобы оценка была объективной, модель специально избегает ставить идеальные баллы, чтобы не обманывать себя.
5. (Backpropagation): Если улучшенный ответ оказался хорош, эта информация передаётся обратно к родительскому узлу и другим связанным ответам. Это как если бы вы поделились своим новым знанием с друзьями, чтобы все в группе тоже стали умнее.
6.Актуализация планов (UCT Update): Когда все оценки обновлены, модель пересматривает свои планы и решает, какие варианты стоит изучить дальше. Здесь работает формула, которая помогает ей оценить, куда лучше направить внимание в следующий раз, чтобы стать ещё более эффективной.
Работает с openapi like apiшками, можно и llamacpp подключить и gpt4o!
github
оригинальный папир
GitHub
GitHub - VikhrModels/mctslib
Contribute to VikhrModels/mctslib development by creating an account on GitHub.
Если продолжаете заниматься ручным тюнингом промптов, то есть не плохая схема:
1. Нужен тестовый датасет (или отсматривать вручную, или размеченный)
2. Заходим на https://lmarena.ai/
— Генерировать будем через "Arena (battle)"
— Там есть и o1 новые, и в целом нет лимитов на генерацию
3. Формируем промпт для улучшения промпта:
— Берём текущие промпты и их скоры
— Рассказываем саму задачу и какие показатели ожидаем (иногда мы можем специально делать не общую точность максимальной, а recall, или только точные негативы)
— Просим проанализировать промпты которые уже есть и их скоры
— И просим написать новый промпт с учётом всего
4. Проверка сгенерированных промптов
— У нас будет 2 сгенерированных новых промпта от 2 рандомных моделей (на самом деле обычно там попадаются +- топовые модели, в том числе и новые как o1)
— Берём их и проверяем на нашем тестовом датасете
— Если какой-то из промптов понравился, то оставляем его себе и добавляем\заменяем в список промптов с метриками в улучшающий промпт
— Повторять можно бесконечно, со временем промпт по настоящему улучшается
Подобная техника в основном нужна, когда уже есть хорошие промпты и не особо получается их уже улучшить.
Из интересного:
▫️ Далеко не всегда лучшие промпты придумывает лучшая модель
▫️ Часто лучший промпт придумывает модель из того же семейства (та же самая, или с большим кол-вом параметров). Например, для gemma2-9b-it это gemma2-27b-it, для qwen2.5-32b-instruct это оказалась API версия qwen-plus
Так же напоминаю про textgrad, который тоже можно использовать для автоматического улучшения промптов.
1. Нужен тестовый датасет (или отсматривать вручную, или размеченный)
2. Заходим на https://lmarena.ai/
— Генерировать будем через "Arena (battle)"
— Там есть и o1 новые, и в целом нет лимитов на генерацию
3. Формируем промпт для улучшения промпта:
— Берём текущие промпты и их скоры
— Рассказываем саму задачу и какие показатели ожидаем (иногда мы можем специально делать не общую точность максимальной, а recall, или только точные негативы)
— Просим проанализировать промпты которые уже есть и их скоры
— И просим написать новый промпт с учётом всего
4. Проверка сгенерированных промптов
— У нас будет 2 сгенерированных новых промпта от 2 рандомных моделей (на самом деле обычно там попадаются +- топовые модели, в том числе и новые как o1)
— Берём их и проверяем на нашем тестовом датасете
— Если какой-то из промптов понравился, то оставляем его себе и добавляем\заменяем в список промптов с метриками в улучшающий промпт
— Повторять можно бесконечно, со временем промпт по настоящему улучшается
Подобная техника в основном нужна, когда уже есть хорошие промпты и не особо получается их уже улучшить.
Из интересного:
▫️ Далеко не всегда лучшие промпты придумывает лучшая модель
▫️ Часто лучший промпт придумывает модель из того же семейства (та же самая, или с большим кол-вом параметров). Например, для gemma2-9b-it это gemma2-27b-it, для qwen2.5-32b-instruct это оказалась API версия qwen-plus
Так же напоминаю про textgrad, который тоже можно использовать для автоматического улучшения промптов.
Forwarded from Анализ данных (Data analysis)
⚡️ Вышел Face fusion 3.0
Мощное приложение для работы с лицами с открытым исходным кодом на базе Gradio, поддерживает множество новых функций, включая:
- Модификация возраста
- Редактор лиц (через LivePortrait)
- Система очередей заданий
- И многое другое
▪Github: https://github.com/facefusion/facefusion
▪Proj: join.facefusion.io
▪Установка: https://pinokio.computer/item?uri=https://github.com/facefusion/facefusion-pinokio
@data_analysis_ml
Мощное приложение для работы с лицами с открытым исходным кодом на базе Gradio, поддерживает множество новых функций, включая:
- Модификация возраста
- Редактор лиц (через LivePortrait)
- Система очередей заданий
- И многое другое
▪Github: https://github.com/facefusion/facefusion
▪Proj: join.facefusion.io
▪Установка: https://pinokio.computer/item?uri=https://github.com/facefusion/facefusion-pinokio
@data_analysis_ml
Forwarded from Сиолошная
На днях авторы перезапустили бенчмарк, сделав новые задачки, и протестировали свежие o1 от OpenAI, которые «умеют рассуждать» — и написали новую статью «LLMs Still Can't Plan; Can LRMs? A Preliminary Evaluation of OpenAI's o1 on PlanBench». Эти новые LLM охарактеризовали как «квантовое улучшение, опережающее конкурентов» — по картинке вы можете понять почему.
Синяя линия — результат o1-preview (o1 не превью будет ещё круче!), красная — o1-mini. По горизонтали длина оптимального плана для решения задачи, выраженная в количестве действий, по вертикали — доля правильно решённых задач с соответствующей длиной плана. Например, o1-preview справляется с задачами с длиной плана в 10 шагов в 25% случаев. Это далеко от идеальных 100%, но действительно квантовый скачок.
Слева графики для Zero shot (то есть без примера решения), справа для one shot (есть решение одной другой задачки) в промпте. Для некоторых моделей лучше дать пример, но o1 становится от этого немного хуже.
Авторы замечают, что o1-preview будто бы ограничена в длине рассуждений (для этого смотрят на распределение длины ответов), и потому скорее всего без ограничения качество в правой части графика было бы выше. Однако эксперименты очень дорогие — менее чем за неделю потратили $1800 только на одну модель😳 и отвечает она медленно — в средне по 111 секунд на запрос.
Что ещё стоит сказать:
— да, есть специальные программы, которые за доли цента и менее чем за секунду по PDDL решат задачу планирования. Но цель бенчмарка — показать прокси-метрику для реальных рассуждений, которые могут быть выражены натуральным языком, а не конвертироваться в спец. программу
— интересно, что LLM-ки лучше работают с текстовым описанием задач (которое может быть двусмысленным), а не со строгим PDDL-форматом подачи информации в промпте
— на оригинальном Blockworld, без замещения кубиков непонятно чем, o1-preview показывает 97.8% решений, что сильно удивляет авторов (они не ждали таких результатов от LLM). На Mystery качество падает до 52.8%, но говорить про переобучение (что модель видела данные) наверное не стоит — просто с блоками действительно ЯЗЫКОВОЙ модели легче управиться должно быть.
— однако когда задачи перегенерировали (уникальные id / слова), то качество упало до 37.3%. Всё ещё существенно выше околонулевых результатов любых других моделей, но хотя бы можно использовать для отслеживания дальнейшего прогресса
— Авторы заметили, что когда модель дает неверный ответ, она также иногда предоставляет креативное, но зачастую бессмысленное обоснование своего решения. Это похоже на то, как если бы o1 перешла от галлюцинаций к газлайтингу
— В одном случае o1 решила, что условие «блок_находится_на(a, c)» было выполнено, потому что, как это объяснялось в скобках, a было на b, которое было на c, и, таким образом, a было где-то выше c, что следует считать находящимся «сверху» него🤷♀️ (в PDDL такое недопустимо как раз, но, как указано выше, там и общее качество хуже)
— в другой задаче, которая не имела решения (авторы отдельно проверяли, как часто модель понимает тупиковость ситуации), модель всё же смогла выдать план. Когда её попросили объяснить, как мол так, она написала, что все условия были выполнены, просто не за раз, а последовательно в ходе решения😀
Синяя линия — результат o1-preview (o1 не превью будет ещё круче!), красная — o1-mini. По горизонтали длина оптимального плана для решения задачи, выраженная в количестве действий, по вертикали — доля правильно решённых задач с соответствующей длиной плана. Например, o1-preview справляется с задачами с длиной плана в 10 шагов в 25% случаев. Это далеко от идеальных 100%, но действительно квантовый скачок.
Слева графики для Zero shot (то есть без примера решения), справа для one shot (есть решение одной другой задачки) в промпте. Для некоторых моделей лучше дать пример, но o1 становится от этого немного хуже.
Авторы замечают, что o1-preview будто бы ограничена в длине рассуждений (для этого смотрят на распределение длины ответов), и потому скорее всего без ограничения качество в правой части графика было бы выше. Однако эксперименты очень дорогие — менее чем за неделю потратили $1800 только на одну модель
Что ещё стоит сказать:
— да, есть специальные программы, которые за доли цента и менее чем за секунду по PDDL решат задачу планирования. Но цель бенчмарка — показать прокси-метрику для реальных рассуждений, которые могут быть выражены натуральным языком, а не конвертироваться в спец. программу
— интересно, что LLM-ки лучше работают с текстовым описанием задач (которое может быть двусмысленным), а не со строгим PDDL-форматом подачи информации в промпте
— на оригинальном Blockworld, без замещения кубиков непонятно чем, o1-preview показывает 97.8% решений, что сильно удивляет авторов (они не ждали таких результатов от LLM). На Mystery качество падает до 52.8%, но говорить про переобучение (что модель видела данные) наверное не стоит — просто с блоками действительно ЯЗЫКОВОЙ модели легче управиться должно быть.
— однако когда задачи перегенерировали (уникальные id / слова), то качество упало до 37.3%. Всё ещё существенно выше околонулевых результатов любых других моделей, но хотя бы можно использовать для отслеживания дальнейшего прогресса
— Авторы заметили, что когда модель дает неверный ответ, она также иногда предоставляет креативное, но зачастую бессмысленное обоснование своего решения. Это похоже на то, как если бы o1 перешла от галлюцинаций к газлайтингу
— В одном случае o1 решила, что условие «блок_находится_на(a, c)» было выполнено, потому что, как это объяснялось в скобках, a было на b, которое было на c, и, таким образом, a было где-то выше c, что следует считать находящимся «сверху» него
— в другой задаче, которая не имела решения (авторы отдельно проверяли, как часто модель понимает тупиковость ситуации), модель всё же смогла выдать план. Когда её попросили объяснить, как мол так, она написала, что все условия были выполнены, просто не за раз, а последовательно в ходе решения
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DL in NLP (Vlad Lialin)
X (formerly Twitter)
Hugh Zhang (@hughbzhang) on X
OpenAI recently released the o1 family of models and a graph showing scaling laws for test-time compute — sadly without the x-axis labeled.
Using only the public o1-mini API, I tried to reconstruct the graph as closely as possible. Original on left, my best…
Using only the public o1-mini API, I tried to reconstruct the graph as closely as possible. Original on left, my best…
Forwarded from DL in NLP (Vlad Lialin)
O1 mini inference scaling experiments
Прикольное саммари экспериментов одного чела. Коротко: если убедить модель дольше думать (что пока что непросто) pass@1 реально будет расти лог-линейно. При этом это скорее всего не majority voting или self consistency тк эти методы упираются в потолок
Прикольное саммари экспериментов одного чела. Коротко: если убедить модель дольше думать (что пока что непросто) pass@1 реально будет расти лог-линейно. При этом это скорее всего не majority voting или self consistency тк эти методы упираются в потолок
Forwarded from эйай ньюз
Теперь в LLama официально завезли поддержку изображений! До этого мы имели в open-source только сторонние поделки вроде LLaVa и InternVL (они брали Llama3 за основу и тюнили).
Теперь модель понимает графики и диаграммы, описывает изображения и может находить на них объекты по описаниям.
Например, пользователь может спросить, в каком месяце его компания имела лучшие продажи, и модель даст ответ на основе доступных графиков.
Есть несколько размеров:
- Маленькая модель - 11B параметров
- Средняя - 90B. Обходит GPT-4o-mini по Vision бенчам.
- Более легковесные text-only модели: 1B и 3B параметров. Как раз, чтобы бегать локально на девайсах. 3B обходит Gemma 2 и Phi-3.5 - Mini.
- Контекст 128,000 токенов, как и в LLama 3.1
С легковесными моделями можно создавать персонализированые приложения с агентами в закрытой среде - например, резюмировать ваши сообщения, емейлы или отправлять приглашения в календарь.
И теперь с Llama 3.2 ждём очередной большой скачок качества Multimodal LLM в опенсорсе!
Блогпост
Веса на HF
@ai_newz
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Есть вот такая табличка по VL моделькам. Именно на ней Qwen лучше всего себя показывает (хотя вот метрики на релизе llama лучше).
Так же вышла серия моделей Molmo (в базе там Qwen2), которая тоже не плохо себя показывает:
https://huggingface.co/collections/allenai/molmo-66f379e6fe3b8ef090a8ca19
Попробовать можно тут:
https://molmo.allenai.org/
Так же вышла серия моделей Molmo (в базе там Qwen2), которая тоже не плохо себя показывает:
https://huggingface.co/collections/allenai/molmo-66f379e6fe3b8ef090a8ca19
Попробовать можно тут:
https://molmo.allenai.org/
И вот такая вышла ещё мультимодальная LLM на основе gemma2-9b:
https://huggingface.co/AIDC-AI/Ovis1.6-Gemma2-9B
https://huggingface.co/AIDC-AI/Ovis1.6-Gemma2-9B
Forwarded from rizzearch
Transformers need glasses! Information over-squashing in language tasks
мы уже упоминали о том, что трансформеры могут быть чувствительны к чувствительным инпутам, и авторы недалеко отошли от этих выводов, но и заметили еще другое интересно
они выявили нестабильность не на уровне леернормы/весов, как в прошлой работе, а на уровне внутренних репрезентаций токенов. как оказывается, чем длиннее последовательность, тем ближе репрезентации последних токенов становятся друг к другу (и неразличимыми впоследствии. это при условии, что последовательности более-менее похожи, но не одинаковы) + происходит серьезная затычка с флоу информации на последних токенах через декодер, поскольку у них намного меньше путей по прокидыванию этой самой информации по сравнению с более ранними токенами
ну и получаем то, что получаем. на вход идет чувствительная задача ⇒ трансформер точно так же чувствительно (плохо) и неидеально отвечает. при том верно для большого и маленького скейла. эмпирическое подкрепление их теории сделано на 7б модели (в принципе экспы провоили га гемини и гемме)
однако вместе с этими выводами пришли и интересные инсайты
- в трансформере присутствует U-shape тенденция к запоминанию: таска лучше решается, если релевантные для нее токены находятся рядом с началом/концом последовательности
- если “разбавлять” чувствительную последовательность, например, добавлять периодически запятые, то репрезентации становятся более различимыми и все идет smoother
довольно занятно, ибо такие же фичи свойственны и человеческой способности к запоминанию, да и решение с запятыми по сути так же помогает нам не сбиться с адекватного поглощения текстовой информации
👀LINK
мы уже упоминали о том, что трансформеры могут быть чувствительны к чувствительным инпутам, и авторы недалеко отошли от этих выводов, но и заметили еще другое интересно
они выявили нестабильность не на уровне леернормы/весов, как в прошлой работе, а на уровне внутренних репрезентаций токенов. как оказывается, чем длиннее последовательность, тем ближе репрезентации последних токенов становятся друг к другу (и неразличимыми впоследствии. это при условии, что последовательности более-менее похожи, но не одинаковы) + происходит серьезная затычка с флоу информации на последних токенах через декодер, поскольку у них намного меньше путей по прокидыванию этой самой информации по сравнению с более ранними токенами
ну и получаем то, что получаем. на вход идет чувствительная задача ⇒ трансформер точно так же чувствительно (плохо) и неидеально отвечает. при том верно для большого и маленького скейла. эмпирическое подкрепление их теории сделано на 7б модели (в принципе экспы провоили га гемини и гемме)
однако вместе с этими выводами пришли и интересные инсайты
- в трансформере присутствует U-shape тенденция к запоминанию: таска лучше решается, если релевантные для нее токены находятся рядом с началом/концом последовательности
- если “разбавлять” чувствительную последовательность, например, добавлять периодически запятые, то репрезентации становятся более различимыми и все идет smoother
довольно занятно, ибо такие же фичи свойственны и человеческой способности к запоминанию, да и решение с запятыми по сути так же помогает нам не сбиться с адекватного поглощения текстовой информации
👀LINK
Forwarded from Data Secrets
PyTorch поймали тренд и запустили собственную библиотеку для квантизации и ускорения моделей
Называется она очень прикольно – torchao🔵
Код, конечно, в основном на pytorch. Вот некоторые выборочные метрики из блога:
➡️ ускорение на 97% для инференса Llama 3 8B с автоквантом весов в int4
➡️ пиковое сокращение VRAM на 73% для инференса Llama 3.1 8B с квантизацией KV кэша
➡️ ускорение претрейнинга Llama 3 70B на 50% с обучением под float8
Звучит мощно, в общем. Подробности – в блогпосте
Называется она очень прикольно – torchao
Код, конечно, в основном на pytorch. Вот некоторые выборочные метрики из блога:
Звучит мощно, в общем. Подробности – в блогпосте
Please open Telegram to view this post
VIEW IN TELEGRAM
Ну, как говорится, молодая была не молода. Но пусть будет новой идеей 😁
Forwarded from Data Secrets
Там Anthropic предложили новую технику для RAG. Разбираемся:
Как работает обычный RAG:
1. Документы в корпусе разбиваются на чанки
2. Из каждого такого чанка мы достаем эмбеддинг и кладем его в векторную БД
3. Когда поступает запрос (промпт), мы ищем в этой БД семантически близкие к нему чанки и добавляем их в промпт, чтобы модель могла использовать эту информацию для ответа
В чем тут проблема?
Дело в том, что таким образом мы можем упустить важный контекст и детали запроса. Например, пользователь запрашивает "Error code TS-999". Поиск найдет информацию про коды ошибок в целом, но может упустить точное совпадение «TS-999». К тому же, при возвращении конкретного чанка из базы может случится так, что он будет вырван из какого-то важного контекста, и это может помешать модели.
Что предлагают Anthropic?
Во-первых, они предлагают извлекать не только обычные эмбеддинги, но и делать TF-IDF энкодинг чанков с помощью BM25. TF-IDF утроен так, чтобы как раз отбрасывать наиболее "общие" вещи в тексте, и фокусироваться на редких и самых важных словах. Это поможет не упускать детали при поиске, как в примере с ошибкой TS-999.
Во-вторых, чтобы избавиться от проблемы отсутствия контекста, они предлагают этот контекст добавлять искусственно (то есть делать из такого: "Прибыль росла на 3%." ... такое: "Этот чанк относится к отчету компании ACME за Q2 2023; прибыль росла на 3%.").
Для этого перед извлечением эмбеддингов и TF-IDF энкодингом каждый чанк аннотируется с помощью отдельного запроса к модели (в случае Anthropic это делается с помощью Клода). Да, дорого. Но с помощью фишки Prompt Caching, которую недавно завезли в API, можно хорошо скостить цену.
В итоге все это дает достаточно ощутимый прирост к метрикам качества поиска. Например, фактических ошибок становится меньше на 35%, а это ничего себе!
Как работает обычный RAG:
1. Документы в корпусе разбиваются на чанки
2. Из каждого такого чанка мы достаем эмбеддинг и кладем его в векторную БД
3. Когда поступает запрос (промпт), мы ищем в этой БД семантически близкие к нему чанки и добавляем их в промпт, чтобы модель могла использовать эту информацию для ответа
В чем тут проблема?
Дело в том, что таким образом мы можем упустить важный контекст и детали запроса. Например, пользователь запрашивает "Error code TS-999". Поиск найдет информацию про коды ошибок в целом, но может упустить точное совпадение «TS-999». К тому же, при возвращении конкретного чанка из базы может случится так, что он будет вырван из какого-то важного контекста, и это может помешать модели.
Что предлагают Anthropic?
Во-первых, они предлагают извлекать не только обычные эмбеддинги, но и делать TF-IDF энкодинг чанков с помощью BM25. TF-IDF утроен так, чтобы как раз отбрасывать наиболее "общие" вещи в тексте, и фокусироваться на редких и самых важных словах. Это поможет не упускать детали при поиске, как в примере с ошибкой TS-999.
Во-вторых, чтобы избавиться от проблемы отсутствия контекста, они предлагают этот контекст добавлять искусственно (то есть делать из такого: "Прибыль росла на 3%." ... такое: "Этот чанк относится к отчету компании ACME за Q2 2023; прибыль росла на 3%.").
Для этого перед извлечением эмбеддингов и TF-IDF энкодингом каждый чанк аннотируется с помощью отдельного запроса к модели (в случае Anthropic это делается с помощью Клода). Да, дорого. Но с помощью фишки Prompt Caching, которую недавно завезли в API, можно хорошо скостить цену.
В итоге все это дает достаточно ощутимый прирост к метрикам качества поиска. Например, фактических ошибок становится меньше на 35%, а это ничего себе!