однажды в коменты пришёл читатель Семён и пошутил что-то про RAG. Я тогда ничего не понял, но на всякий случай молча кивнул типа «да-да, я в курсе! во дают!1»
чтобы в следующий раз не попасть впросак, решил таки сделать домашку и погуглить что за зверь этот ваш раг. В интернетах нашёл красиво свёрстаное (аж захотелось купить что они там продают) и главное доступное объяснение:
https://gradient.ai/blog/rag-101-for-enterprise
⌘⌘⌘
что нужно, чтобы сделать своего чатбота на ллм? помимо самой ллм, конечно.
я так понял*, ллм из коробки будет знать много чего из общего мира, но конкретно про вашу специфику — неоч
* для экономии места я не буду перед каждым абзацем вставлять «я так понял», но представьте, что оно там есть и это будет справедливо показывать уровень моего знания о предмете
RAG — это сокращение от retrieval-augmented generation, типа генерация ответа с обогащением релевантной информацией; т.е. помимо общего знания в ллм добавляется релевантного контекста: например, вики компании.
⌘⌘⌘
плюшки:
→ добавляет свежие факты и документы, появившиеся после горизонта обучения модели
→ с дополнительным контекстом модель меньше галлюцинирует
→ косты меньше, чем у файн-тюнинга; причём как по деньгам, так и по времени и технической экспертизе
⌘⌘⌘
примеры, когда RAG будет полезен:
- чатбот сапорта: будет знать последний статус заказа и чётко расскажет про варианты доставки;
- поиск по базе знаний: например, по вики компании — что там по удалённой работе
- рекомендации: выдать самые последние статьи в соответствие с персональными характеристиками.
⌘⌘⌘
как можно улучшить ответы ллм? товарищи в статье приводят три метода:
1. prompt engineering
2. fine-tuning
3. и, собственно, RAG
prompt engineering — дёшево и сердито, низкий порог входа. Не нужны ресурсы на до-обучение.
fine-tuning — нужны ресурсы, время и корпус для до-обучения (?). Как результат более глубокие знания доменной области (например, медицина или финансы)
RAG — нужны ресурсы и специальная подготовка данных в векторной базе данных. На выходе обогащение ответов последними обновлениями и релевантным внутренним контекстом
⌘⌘⌘
чтобы RAG смог «читать» дополнительный контекст, его предварительно надо перевести в вектора (эмбединги, да?), эти вектора хранятся в специализированных базах данных.
целевой процесс обогащения сгенерированного ответа выглядит примерно так:
- (подразумевается, что уже) есть векторная база, заполненная подготовленными эмбедингами
- запрос пользователя переводится в вектора и в векторной базе ищутся семантически похожие данные
- эти релевантные данные добавляются в исходный запрос как дополнительный контекст
- на основе запроса и контекста генерируется ответ пользователю
если вы дошли до этого уровня то
⌘⌘⌘
буду рад, если покажете где я наврал — век учись!
что меня привлекло в подходе: среди всех приведённых вариантов допиливания моделей RAG выглядит как чисто дата-инженерская задача.
получается, надо взять какие-то данные, как-то их трансформировать, где-то похранить и потом предоставить для удобного пользования. И, естественно, нужно как можно чаще, по́лно и без ошибок! Ничего не напоминает?)
