Базовый минимум. Часть 3: RAG-системы

[denis_iii]

Про подмес в контекст знаний, через запрос в RAG достаточно понятно. Интересно будет узнать про агентов и их работу через создание MCP инструментов (tools) в аналогичном минималистичном примере.

[Sherstpasha]

Да. В следующей части такое планируется) Тоже в Google Colab, чтобы воспроизвести было просто.

[Yurez777]

Самое сложное это если книгу отсканировал ( нельзя выделить текст)

То OCR плохо всю информацию переводит в нормальный текст, и тогда RAG не работает или криво работает , может есть статья как с этим бороться?

[Sherstpasha]

Зависит от OCR-движка. Лучше всего будет сначала перевести страницы в текст, если качества недостаточно, то взять модели лучше или вообще мультимодальную модель или API-сервис. Если текст печатный, обычные OCR обычно справляются без проблем. Есть пример страниц?

[Yurez777]

Я не могу сюда фаил прикрепить

[Sherstpasha]

https://habr.com/ru/articles/1002152/comments/#comment_29580920
Ответил ниже

[Sherstpasha]

Я думал, что вполне можно распознать документы, а потом применить раг. Модель небольшая, но если она не влезет локально, то можно с помощью LM Studio запустить что нибудь квантованное

[Sherstpasha]

https://colab.research.google.com/drive/1o3q4Px5YWGY3vFfWDeVu2fbZtC4XTmAb?usp=sharing
Кажется, что вполне получилось распознать с правильным макетом

[Yurez777]

Я хотел локально развернуть , максимально для ответов выбирал модели 7b.

Для OCR пробовал

RapidOCR ,PaddleOCR, docTR, Surya

Моя цель была Локальный RAG собрать.

Спасибо.)

,

[sergei_ai]

Хорошая систематизация. Из практики добавлю пару вещей, которые всплывают на продакшене:

Re-ranking — на больших базах top-K из векторного поиска часто притаскивает шум. Cross-encoder reranker сильно помогает с релевантностью.

По чанкингу — размер очень зависит от домена. Для юридических документов 800 символов мало (теряется контекст), для FAQ и 300 хватает. Тут только эксперименты.

[Sherstpasha]

Спасибо! Отличное дополнение) Реранкер может значительно повысить релевантность поиска, хотя и вместе с этим значительно увеличить время на извлечение (не так важно, потому что по сравнению инференсом ллм это копейки). Причем, можно извлечь больше, а среди них реранкером отобрать топ N. Есть очень простой пример "поглубже", чем в статье https://github.com/sherstpasha/practicum_yandex_retrieval

[gavexe]

Что за модели вы оба используете? Проблемы шума давно нет. Добавление дополнительных (непротиворечивых, конечно) данных не снижает качество модели. Единственный минус - количество токенов. А так хоть забивай весь мегабитный контекст чанками топ-100 - качество не упадет. А то, что размер чанков зависит от предметной области - это точно подмечено. Еще завист от функционала системы: если это чат-бот - одно. Если агент, пишущий код - другое. Лучшие практики - parental retrievement. Размер большого чанка - абзац/таблица. Маленького - размер среднего входного текста. Если чат бот - предложение. Пользователи обычно не пишут больше одного предложения чат боту.