В этом подробном гайд‑видео я раскрываю всё, что нужно знать о RAG (Retrieval Augmented Generation) — передовом подходе, который выводит большие языковые модели (LLM, GPT‑4, ChatGPT и др.) на новый уровень, добавляя к их генеративным возможностям живую, актуальную базу знаний.
Вы увидите, как на практике связать эмбеддинги, векторное хранилище, retriever и generator, чтобы буквально «подпитать» модель свежим контентом и получить точные, аргументированные ответы без «галлюцинаций».
Я пошагово показываю архитектуру, объясняю ключевые нюансы (latency, стоимость, обновление данных), визуально скетчу процесс, разбираю реальные сценарии применения: чат‑бот поддержки, интеллектуальный поиск по корпоративным документам, персонализированный ассистент и многое другое.
Параллельно я делюсь лайфхаками, где RAG приносит максимальную пользу, а где лучше отказаться от него в пользу классических решений.
После просмотра у вас будет чёткая дорожная карта: как спроектировать, собрать и оптимизировать собственную RAG‑систему под ваш use case.
*Прямая ссылка на видео https://www.youtube.com/watch?v=22tkx79icy4
Расшифровка видео
Поиск по видео
0:00
Рак. Retrieval augmented generation. Что
0:03
это такое? Как это работает? Зачем это
0:05
нужно? Приветствую. Сегодня я объясню
0:07
вам, что же такое рак. Простыми словами,
0:10
я наглядно покажу, как всё это работает,
0:12
какие проблемы рак решает и зачем это
0:14
вообще надо. Рак — это приём, при
0:16
котором перед каждым вызовом lm мы
0:18
достаём, так скажем, релевантные чанс
0:21
куски внешних данных. Внешние данные
0:23
могут храниться в dataта базе. И
0:25
добавляем их в augmented prompt. Сейчас
0:28
чуть попозже я вам всё это объясню,
0:30
покажу весь workflow, как это работает.
0:32
Но сейчас поймите, что рак — это просто
0:34
приём, при котором перед каждым вызовом
0:36
неронки, перед каждым промтом, который
0:39
мы даём в LLM, мы сначала достаём просто
0:42
дату из датабазы, соответственно, потом
0:44
её просто скармливаем в нейронку в виде
0:47
контекста. Это такое очень high-level
0:50
представление о RК системе. Уm есть пару
0:53
открытых проблем. Первое- контекстное
0:55
окно. contex window. Соответственно,
0:58
контекстные окна ещё не настолько
1:00
большие, чтобы запихивать туда кучу
1:02
информации. И из-за этого неронка
1:04
начинает как бы теряться, забывать, и
1:06
происходит, соответственно, этот затуп,
1:08
и мы не можем поместить огромную,
1:09
допустим, дату-базу в наш промт. Это
1:12
первая проблема. Вторая проблема — это
1:14
no source или же нет достоверного
1:16
источника, откуда, соответственно, брать
1:18
правильную информацию, которая нужна
1:20
именно в вашем случае, например, из
1:22
вашей дата-базы. Может быть так, что
1:24
тематика, которая вам нужна, не была в
1:26
датасете при тренировке LLM в виде GPT
1:29
или там Deepsek, неважно. И ещё одна
1:32
проблема — это out of date. Зачастую
1:34
бывает, что информация в LLM уже
1:37
устаревшая, потому что её тренировали
1:39
там, допустим, полгода назад, и
1:42
информация уже устарела, и она является
1:44
неверной из-за этого. Поэтому у нас вот
1:46
есть такие три основные проблемы.
1:48
Контекстное окно, no source. нету
1:51
достоверного источника, откуда берётся
1:52
информация, и, соответственно,
1:54
устаревшая информация. Рак системы рак.
1:58
Они решают эти три проблемы. И сейчас я
2:00
вам расскажу, как это всё работает
2:02
дальше. Сначала рассмотрим ситуацию
2:04
взаимодействия юзера просто с LLM, без
2:06
всяких датабазз, без всяких раксистем. У
2:09
нас есть usер. Вот здесь у нас есть
2:11
usеer lm. Как происходит взаимодействие
2:13
между usером и large language models? У
2:16
юзера есть какой-то вопрос, он пишет это
2:18
в prompt. То есть у нас есть promptт. Он
2:20
отправляет prompt в launch clugage
2:22
models. В промпте может быть всё, что
2:23
угодно, например, какая самая близкая
2:25
планета к солнцу. Дальше lm получает на
2:28
input этот промт, то есть получает этот
2:30
запрос, через небольшое количество
2:32
времени отвечает на этот запрос, исходя
2:34
из тех данных, на которых она была
2:36
натренирована, не ссылаясь на источник,
2:39
не подтверждая, что эта информация
2:40
обновлена, она просто даёт ответ. Дальше
2:43
перейдём к тому, как работают
2:44
Раксистемы, потому что это сильно
2:46
отличается от простого взаимодействия
2:48
юзера с lm. Рассмотрим пример, где юзер
2:51
пишет промт. То есть у нас опять же есть
2:52
юзер, он пишет какой-либо промт. Вот
2:55
здесь промт, например. Это может быть
2:56
опять же какая планета самая близкая к
2:59
солнцу, но здесь и начинается отличие. В
3:02
игру входит Small Embeded Model. Сейчас
3:04
я вам объясню, что это такое. Как
3:06
правило, это такая маленькая модель,
3:08
которая просто конвертит ваш промт, а
3:10
именно текст, в вектора. То есть
3:12
трансформирует ваш текст в численные
3:15
вектора. Их ещё называет embededors. Это
3:18
обычно очень маленькие модели, состоящие
3:20
из Encoder. Encoder — это часть
3:22
трансформера. Для тех, кто не знает,
3:24
LGECH Language Models построены на
3:25
архитектуре трансформеров. Это если
3:27
прямо сильно упрощать. То есть у нас
3:29
есть Transformers и на них построено
3:31
LLM. Сами трансформеры состоят из
3:34
encoder, части и декоoder.
3:36
Соответственно, эти маленькие smalled
3:38
models построены именно на базе
3:41
энкоodдера, то есть состоят из
3:42
энкоodдера. Это нужно для того, чтобы
3:44
обычные слова, обычный текст
3:46
трансформировать в vectors. Как правило,
3:49
эти small embededs — это bird style
3:52
encoder. Вы подробно можете прочитать
3:54
про эту архитектуру в интернете. Всё
3:56
подробно расписано. Сейчас я застрять на
3:58
этом своё внимание не буду. Дальше, в
4:00
чём самая главная фишка RАК? В том, что
4:02
у нас есть какая-то дата-база. Это может
4:04
быть всё, что угодно. Это может быть
4:06
PDF, файл, какая-то книга, но обычно это
4:09
просто дата-база с информацией,
4:11
допустим, информация о вашем продукте,
4:14
описание, спецификация и так далее. Эта
4:17
датабаза делится на маленькие чанс, то
4:20
есть на маленькие куски. Власть
4:21
информации делится просто на маленькие
4:24
куски. Дальше эти куски трансформируются
4:27
уже в вектора. Это всё нужно для
4:29
быстрого поиска. То есть эти чанс, они
4:31
трансформируются в вектора.
4:33
Соответственно, вся датабаза у нас
4:35
трансформирована в vectors. Так, на
4:37
данный момент мы имеем проomptтвектор,
4:39
то есть вектор, который состоит из
4:41
промта юзера, и датабазу, которая уже
4:43
разделена на вектора. Дальше у нас
4:45
происходит сравнение промт вектора с
4:48
вектором, который из датабазы, то есть
4:51
DB вектор. Как вообще эти вектора
4:53
выглядят? Давайте я сейчас немного
4:54
заскетчу это быстренько. Вектора могут
4:56
выглядеть как угодно. Так, так, так.
5:00
Просто набор цифр, грубо говоря. Давайте
5:03
представим, что вот этот вектор — это
5:04
промтвектор. И на этом этапе вектор
5:07
search Engine, они сравнивают эти
5:10
вектора. Пример searchна — это F
5:13
AS. Тоже можете почитать информации в
5:16
интернете очень много на эту тему.
5:17
Вектора сравниваются с помощью,
5:19
соответственно, этого эндна. И если в
5:22
каком-либо чанке, то есть в этом
5:24
маленьком кусочке есть ответ на вопрос
5:26
юзера, либо есть какая-то информация,
5:28
связанная с промтом юзера, она будет
5:31
добавлена в контекст далее, но это чуть
5:33
попозже. Допустим, вот у нас есть схожие
5:35
вектора. Вот эти два вектора — это
5:37
database вектор. После сравнения, когда
5:40
engine уже нашёл схожие вектора, вот эти
5:42
вектора из датабазыются в контекст.
5:45
После вот этого сравнения у нас уже
5:47
формируется так называемый augmented
5:50
prompt. Давайте я напишу, из чего
5:52
состоит этот augmented prompt. Он
5:54
состоит из инструкции. Это может быть
5:56
всё, что угодно по типу helpful
5:58
assistant, то есть просто инструкция для
6:00
lm, как ей надо работать. Дальше у нас
6:03
идёт, соответственно, этот контекст.
6:05
Контекст мы получили из вашей датабазы,
6:07
заточенную на ваш tasк. Там может быть
6:09
спецификация вашего продукта, всё, что
6:11
угодно. И этот контекст мы получили,
6:14
соответственно, из датабазы с помощью
6:16
сравнения векторов, которые состоят из
6:19
промпта юзера и из чанков в датабазе.
6:22
Эти вектора сравнили, нам появился
6:24
контекст, который даётся в augmented
6:26
промте. Третьем у нас идёт сам промт,
6:29
который юзер писал в нашем случае, какая
6:31
планета самая близкая к солнцу. весь
6:33
augmented prompt даётся на input в lm
6:37
это может быть chat
6:39
gpt g mini это может быть любая large
6:42
language models может быть олаama в
6:43
общем их сотня это всё не имеет значения
6:46
lm в запросе имеет уже контекст и ll в
6:50
запросе имеет соответствую инструкцию
6:52
как и взаимодействовать она имеет промт
6:54
юзера то есть его вопрос и она уже имеет
6:56
контекст это будет либо ответ на вопрос
6:59
из датабазы либо информация которая
7:01
связана с этим этим вопросом. И исходя
7:03
из этих трёх пунктов, она уже формирует
7:06
ответ, присылает его обратно юзеру.
7:09
Важный момент, если юзер даёт какой-либо
7:11
промт и ответа либо смежной информации с
7:13
этим промотом нету в датабазе, lm выдаст
7:16
обратно, что она не знает ответ на
7:18
данный вопрос. На самом деле, это
7:19
намного лучше, чем lm просто будет вам
7:21
нести чушь, давать ложные факты и
7:23
сведения. В целом, так и работают
7:25
раксистемы. Вы можете использовать их в
7:27
большом количестве случаев. Например,
7:28
вам нужно, чтобы ваша LLM, а именно это
7:31
уже будет AI agent, консультировал
7:33
клиента по вашему товару. Это может быть
7:35
какой-то софт, ещё что-то, там, айпды и
7:38
так далее. Создаёте дата-базу, носите
7:40
всю информацию о продукте, о вашем
7:42
продукте, о вашем софте, всю
7:44
спецификацию, все тонкости вашего
7:46
товара, всё прописывать в дата-базу. И
7:48
теперь AI agent при общении с клиента
7:51
будет давать достоверные сведения о
7:52
вашем товаре. Получается промт,
7:54
допустим, это ваш клиент, он будет
7:56
давать промт. Это всё будет
7:57
переводиться, трансформироваться в
7:58
вектора. Вектора будут сравниваться с
8:00
вашей дата-базой и будут даваться
8:02
augmented prom в lm с контекстом о вашем
8:05
специфическом товаре. И уже будет ответ
8:09
для клиента со всеми тонкостями вашего
8:11
товара. Рак — это вообще суперкрутая
8:13
вещь. Она фиксит проблему, что у LM
8:16
достаточно маленькое контекстное окно.
8:18
Применение этому рак очень много. Всё
8:20
ограничивается только, как всегда вашей
8:22
фантазией. В следующих видео мы можем
8:24
разобрать разновидности рак. такие как
8:26
CG, KG и так далее. Их достаточно много.
8:29
Я хочу показать, как создать свою
8:31
раксистему. Я очень надеюсь, что я
8:33
понятно объяснил рак, что у вас теперь
8:35
не вызывает вопросов эта аббревиатура и
8:38
вам полностью понятна данная тема. Если
8:40
вам понравился данный видеоролик,
8:42
пожалуйста, поставьте лайк. Это помогает
8:44
в продвижении данного контента. И
8:46
напишите комментарии, что вы хотите
8:48
увидеть дальше. Всех благодарю за
8:50
просмотр. Всем удачи. Скоро увидимся. y