Свежий пост от Anthropic про интересную технику контекстуализации чанков для улучшения RAG.

Напомню на всякий случай, RAG (retrieval augmented generation) - это когда мы помогаем нашей LLM лучше ответить на пользовательский запрос, "обогащая" его релевантной информацией из базы знаний. Примерно так: берём запрос, находим семантически близкие к нему фрагменты из базы знаний, просим LLM использовать их в ответе на запрос. Но это совсем на пальцах, а чуть подробнее про RAG можно почитать, например, тут.

В теории идея RAG звучит красиво, но на практике куски информации, вырванные из контекста, могут не только не помогать, но и мешать модели отвечать на вопросы. Вот разработчики из Anthropic и предлагают добавить в каждый чанк немного контекста:

Выручка компании выросла на 3% относительно предыдущего квартала.
->
Выдержка из отчета за второй квартал 2023 года компании "Иванов и партнёры". Выручка в предыдущем квартале составила 314 млн долларов. Выручка компании выросла на 3% относительно предыдущего квартала.

Интуитивно понятная идея, но... А как это сделать? Не вручную же? 🥰 Разумеется, нет. Антропики использовали для написания контекстов свою же недорогую модель Claude 3 Haiku с примерно таким промптом (мой вольный перевод):

<документ>
{{подставляем сюда ПОЛНЫЙ текст документа}}
</документ>
Вот фрагмент, для которого нам нужен краткий контекст из документа:
<фрагмент>
{{подставляем сюда текст фрагмента}}
</фрагмент>
Дай краткий контекст для этого фрагмента на основе всего документа, так чтобы потом можно было легко понять, про что этот фрагмент и как он соотносится с документом в целом. В ответе напиши только краткий контекст, без повторения фрагмента.

[Я, кстати, немного потестировал ровно этот промпт с локальными Mistral-Small-Instruct-2409 и Gemma2-9b на русскоязычных текстах, и вроде бы даже работает]

Вы скажете, что слишком дорого каждый раз заставлять модель читать весь документ - ведь у нас для рерайтинга каждого чанка полный текст документа подставляется в промпт. Но у Антропиков есть кеширование документов, поэтому им не дорого. 😎

Как можно было ожидать - не просто же так Антропики решили поведать миру о contextual retrieval - метод дал ощутимый прирост к качеству поиска релевантных фрагментов для ответа на запросы. В каком-то смысле, мы просто обмениваем большое количество компьюта (в данном случае - переписывание чанков моделью, пусть и относительно лёгкой) на улучшение данных и, как следствие, рост метрик. Если база знаний не слишком часто обновляется, то наверное, игра стоит свеч. Но, как вы понимаете, от кейса к кейсу эффективность может разниться, надо брать и экспериментировать. Тем более, что в блогпосте особо не пишут о влиянии этой техники на конечную задачу - собственно ответы на пользовательские запросы. 💃

P.S. Ещё авторы говорят, что техника хорошо сочетается с гибридным индексом (эмбеддинги + BM25), реранкингом и подачей аж топ-20 чанков в финальный промпт.

Интересный доклад про B-Tree (plus) (Би плюс дерево) структуру в индексах PostgreSQL.

- как индекс в целом устроен и для чего нужен
- почему так устроен, как хранит данные и что/как внутри самого индекса
- чем хороша сама структура B-Tree plus
- базовые знания про : вставка vs чтение (в контекста индексов), GUID vs BigINT в качестве ключа, индексы по primary key (?)
- как оптимизировать запросы если тупят +пара хаков с примерами
- индексы по нескольким полям
- какие есть проблемы с удалением данных (ну и апдейтами тоже)
- чуть про кластеризацию индексов в постгресе и как так получилось 😁

Ссылочка с доклада : https://use-the-index-luke.com/

Уровень : middle+.
Советасьон

https://www.youtube.com/watch?v=OBSx9NDG-X0