Интересное что-то
518 subscribers
2.72K photos
253 videos
140 files
4.53K links
Материалы и мысли, понадерганные отовсюду
Блог: https://t.me/asisakov_channel
Чат: https://t.me/youknowds_chat
Download Telegram
Свежий пост от 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 чанков в финальный промпт.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DevFM
Боль от распухающей базы данных

Интересный кейс от ребят из Figma. Некоторое время назад они сидели на одной жирной Postgres.

Чтобы дать себе время на разработку целевого решения, ребята сначала подстелили сначала соломку:
– Накинули железа (ну конечно, а что ещё остается делать)
– Создали несколько read реплик
– Добавили PgBouncer в свою архитектуру
– Для новых фичей стали стараться использовать отдельные базы

Шардирование оказалось очень трудоёмким, так как требовало значительных изменений в архитектуре. Поэтому ребята двинули в сторону партицирования, когда таблицы с высокой нагрузкой выносятся в отдельные базы.

Самая интересная задача тут – мигрировать данные без даунтайма.
Сделано это было в несколько шагов:
1. Подготовили клиентские приложения для работы с несколькими базами данных.
2. Настроили логическую репликацию таблиц для копирования данных из одной базы в другую. Тут, кстати, ещё интересный нюанс, логическая репликация может занимать ооооочень продолжительное время из-за долгого обновления индексов, поэтому на целевой бд индексы были удалены перед началом копирования и восстановлены после завершения копирования.
3. Короткая пауза активности на основной бд для полной синхронизации данных.
4. Назначение целевой бд как основной и перенаправление запросов к ней.

В общем, отличная статья в копилку насмотренности технологических решений.

На тему миграций без даунтайма у нас был отдельный практический пост.

#skills #database
Forwarded from Айтигребец
Интересный доклад про 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
Please open Telegram to view this post
VIEW IN TELEGRAM
Я принес. Гуманизм против «эффективного менеджмента». Почему заботиться о людях выгодно

Вы знаете, что я тот еще гуманист 🙂 Поэтому не мог пройти мимо этого лонгрида https://habr.com/ru/articles/816545/
Текст большой, так что наливайте чай-кофе, заводите один таймер pomodoro и погружайтесь.

Я хоть и гуманист, но не идеалист. Понимаю, что во взрослой капиталистической жизни на высоком уровне управления почти всегда будет то, на что статья ругается. Однако, мы же в тимлидском канале. А позиция тимлида как раз может себе позволить обеспечивать гуманизм и комфорт в своей команде. На уровне руководителей тимлидов я подобного видел реже, а еще выше, так и зачастую – деньги, ресурсы, безобразно, но однообразно.

Так что, граждане тимлиды, этот контент вам точно будет полезен.
Forwarded from Life isData
Официально: это самая большая шпаргалка по Python, которую я видел.

Коротко про весь ЯП в 10 скринах.

Полная версия в формате PDF — тут
Статья "У нас закончились столбцы" - лучшая худшая кодовая база

О, таблица merchants2? Да, у нас закончились столбцы в merchants, поэтому мы сделали merchants2.


Потрясающая статья для утреннего чтива. Одновременно хочется и смеяться, и плакать. Удивительно странные и нелепые истории про организацию одной большой базы данных, про процессы в компании и про жесткие диски Гилфойла. Крайне рекомендую☕️

https://habr.com/ru/articles/833916/
Please open Telegram to view this post
VIEW IN TELEGRAM