*https://www.youtube.com/watch?v=5P001o1NDig
**https://300.ya.ru/v_dAgJPiiT
Таймкоды
00:00:00 Введение в augmented generation
- Обсуждение подхода к передаче знаний большой языковой модели.
- Упоминание техник retrial augmented generation и cache augmented generation.
00:00:37 Принцип работы retrial augmented generation
- Модель запрашивает внешнюю базу знаний для получения релевантных частей документов.
- Контекст подаётся в модель, обновляя её знания.
00:01:36 Принцип работы cache augmented generation
- Загрузка всей базы знаний в контекстное окно модели заранее.
- Модель использует все загруженные данные для ответа на запросы.
00:02:25 Фазы работы retrial augmented generation
- Офлайн фаза: разбиение документов на чанки и создание векторных имбедингов.
- Онлайн фаза: векторный поиск по базе данных, передача релевантных фрагментов в модель.
- Модульность системы: возможность изменения базы, модели имбедингов или языковой модели без пересборки системы.
00:03:21 Фазы работы cache augmented generation
- Создание огромного промта из документов, который помещается в контекстное окно модели.
- Обработка промта моделью и формирование внутреннего состояния.
- Использование кэша для ответа на запросы без повторной обработки данных.
00:05:24 Сравнение точности и задержки
- Точность retrial зависит от работы ретривера.
- Задержка retrial выше из-за дополнительного этапа извлечения данных.
- Задержка cache ниже благодаря предобработанному кэшу.
00:06:46 Масштабируемость и актуальность данных
- Масштабируемость retrial ограничена размером векторной базы.
- Масштабируемость cache ограничена размером контекстного окна.
- Обновление данных в retrial происходит быстро, в cache — медленнее.
00:07:49 Примеры применения
- Сценарий 1: чат-бот для IT-поддержки, руководство по продукту обновляется редко.
- Сценарий 2: ассистент для юридической фирмы, поиск по тысячам судебных дел.
- Сценарий 3: поддержка принятия клинических решений в больницах.
00:09:43 Гибридный подход
- Использование retrial для извлечения сведений из большой базы.
- Загрузка извлечённых данных в контекст с помощью cache для дальнейших уточнений.
00:10:08 Заключение
- Подведение итогов: retrial подходит для больших и часто меняющихся наборов данных.
- Cache подходит для фиксированных наборов знаний, низкой задержки и упрощения решения.
- Приглашение к дальнейшему взаимодействию через телеграм-канал.
Расшифровка видео
Поиск по видео
0:00
И вновь приветствую вас на канале AI
0:02
Dialogs. Мы продолжаем серию наших видео
0:05
по разработке AI систем Agentic AI.
0:08
Сегодня поговорим о, пожалуй, самом
0:10
распространённом, но и доступном подходе
0:12
к передаче большой языковой модели новых
0:15
знаний, а именно об аугментированной или
0:18
дополненной генерации. Ну или, как это
0:21
всем привычнее слушать по-английски,
0:24
augmented generation. У этого подхода,
0:27
на самом деле, существует несколько
0:28
вариаций или техник.
0:30
Первая техника называется Retrieval
0:32
Augmented Generation или сокращённая
0:34
regн. Ну, как она работает, давайте
0:37
напомню. У нас есть модель, а, и модель
0:40
делает запрос к внешней поисковой базе
0:42
знаний, где хранится вся нужная
0:44
информация и оттуда возвращаются
0:45
релевантные части документов, чтобы дать
0:47
дополнительный контекст. Мы берём эти
0:50
документы, берём вот этот контекст и
0:52
подаём всё в большую языковую модель,
0:54
как бы обновляя её знания. И уже с
0:56
учётом этого контекста модель формирует
0:58
ответ.
1:00
Но Retrieval не единственный способ
1:02
расширить возможности генерации нашей
1:04
модели. Есть ещё и метод, который
1:06
называется CAS Augmented Generation или
1:11
Cle. Это альтернативный метод. Ведь
1:14
вместо того, чтобы каждый раз обращаться
1:16
к базе, мы заранее загружаем всю базу
1:18
знаний в окно контекста модели. Ну прямо
1:21
целиком и полностью. И вместо того,
1:23
чтобы давать модели только информацию,
1:25
которую мы сочлий, которую извлекли, мы
1:29
даём ей вообще
1:31
всё, а не только то, что кажется
1:33
релевантным для текущего
1:35
запроса. Итак, к или к? Давайте
1:38
разберёмся, как именно они работают,
1:40
какие у них возможности и как
1:42
определить, какой метод использовать.
1:44
Начнём с РК. К — это система из двух
1:48
фаз. Фаза оффлайн подготовительная и
1:51
фаза онлайн. в оффлайн-режиме, в
1:53
подготовительном мы берём все свои
1:55
документы, там могут быть Word-файлы,
1:57
PDФы, ну и так далее, разбиваем их на
2:00
кусочки чанки и создаём векторные
2:03
имбединги для каждого такого куска с
2:06
помощью специальной модели имбедингов.
2:08
Эта модель превращает каждый фрагмент в
2:12
вектор. И всё это сохраняется в базе
2:15
данных векторов, так
2:16
называемом пространстве векторов вектор
2:21
DB.
2:22
Получается поисковый индекс
2:24
знаний. Когда пользователь задаёт
2:27
вопрос, начинается онлайн фаза. Сначала
2:31
идёт обращение к извлекателю, к
2:34
ретриверу. Он преобразует вопрос
2:36
пользователя вектор, используя ту же
2:39
самую модель имбедингов и затем делает
2:42
векторный поиск по базе. Ну, в
2:45
результате возвращается там какой-то
2:46
топкат документов наиболее релевантных,
2:49
даже не документов, а чанков, а эти
2:52
фрагменты передаются в контекст ЛМ
2:55
вместе с исходным вопросом пользователя.
2:57
Модель видит и вопрос, и нужные куски
3:00
контента, и выдаёт ответ. То есть мы как
3:03
бы говорим модели: «Вот этот запрос
3:05
пользователя, вот подходящая информация
3:07
из базы, используй её». При этом к очень
3:10
модульная сама по себе можно поменять
3:13
базу. можно поменять
3:16
модельбедингов или саму большую языковую
3:18
модель без пересборки всей системы. А
3:21
теперь давайте посмотрим на альтернативу
3:24
на
3:26
кход, который использует кш. К идёт, как
3:30
мы уже поняли, совершенно по-другому
3:31
пути. Вместо того, чтобы запрашивать
3:34
информацию по мере надобности, мы
3:36
заранее загружаем всё и сразу в контекст
3:40
модели. Допустим, у нас есть все
3:42
документы, да, это всё, что мы знаем, и
3:44
мы делаем из них огромный промт, который
3:46
умещается в контекстное окно модели. Это
3:49
может быть десятки или там даже сотни
3:51
тысяч токенов. Затем большая языковая
3:53
модель обрабатывает этот огромный кусок
3:56
текста за один проход вперёд и формирует
4:00
внутреннее состояние, так называемое
4:03
Kvalue CF. Это внутреннее представление
4:07
всех ваших документов. модель как бы уже
4:09
их прочитала и запомнила. Когда
4:12
пользователь задаёт вопрос, мы берём вот
4:15
этот K value CAS, то
4:17
есть преобразованный в специальную
4:20
структуру кэша языковой модели, наш
4:22
исходный набор документов текстовых, и
4:25
добавляем этот K value CAS, а вместе с
4:28
запросом на вход модели.
4:31
Поскольку в кэше уже есть все
4:33
загруженные данные, модель может
4:34
использовать всё, что ей нужно, чтобы
4:36
ответить без повторной
4:38
обработки. То есть, ещё раз, главное
4:41
различие между и к в том, когда и как
4:44
происходит обработка знаний. Вк мы
4:46
выбираем только то, что нам пригодится,
4:49
а в К мы загружаем сразу всё, что у нас
4:51
есть, и потом в случае необходимости
4:53
модель сама извлекает нужные детали из
4:55
своей памяти.
4:58
СРК, ваша база знаний может быть,
5:00
конечно, очень большой, ну, там тонна
5:03
документов, потому что модель в каждый
5:05
момент видит только небольшой
5:06
релевантный
5:07
фрагмент, а ск, конечно, всё упирается в
5:11
размер контекстного окна модели, который
5:14
обычно составляет 32.000, 100.000
5:17
токенов, иногда чуть больше. Туда нужно
5:19
уместить все документы, а это
5:22
ограничение.
5:24
Ну, давайте поговорим чуть более
5:26
подробно о
5:27
возможностях, местах применения каждого
5:30
из подходов. Начнём с точности
5:34
accuracy. Ук точность во многом зависит
5:36
от того, как работает ретривер. Если он
5:39
не найдёт важный документ, модель не
5:40
сможет дать верный ответ. Если ретривер
5:43
сработает хорошо, то он защитит модель
5:45
от лишних данных.
5:47
А ск мы заранее помещаем все данные,
5:49
поэтому нужна информация точно нужная
5:52
информация точно там есть, если ну была
5:55
загружена. Но теперь модель должна сама
5:57
выбрать из всей вот этой кучи данных то,
6:00
что нужно, может запутаться или включить
6:02
в ответ несвязанную информацию. Эти
6:04
нюансы, конечно,
6:06
остаются. А дальше
6:09
задержка, ну или скорость. Ук есть
6:12
дополнительный этап. Сам процесс
6:14
извлечения данных нужно ещё
6:16
векторизовать запрос, искать в базе и
6:19
потом обрабатывать на один текст.
6:21
Поэтому это, конечно, чуть дольше,
6:24
нежели к а поскольку у него всё
6:27
загружено в кэш, чтобы ответить на
6:28
вопрос. Там кэш пишем, да, уже это
6:30
предобработанный K value CASШ, то есть
6:33
распаршены исходные тексты самой
6:36
моделью. Модели достаточно одного
6:38
прохода плюс генерация ответа. Нет
6:41
поиска.
6:43
Так что с точки зрения задержки, как
6:45
обычно
6:46
быстрее. Давайте рассмотрим
6:48
масштабируемость Skyability. Урак. Она
6:51
по сути ограничена лишь размером
6:53
векторной базы. Можно хранить миллионы
6:55
документов и доставать только те, что
6:58
нужны. У Кисстабированность напрямую
7:00
связана, как мы уже говорили, с окном
7:02
контекста. Хоть оно и достаточно велико,
7:05
оно всё же, конечно. Даже когда окна
7:07
контекста будут расти, к скорее всего
7:10
всегда будет преимущество в плане
7:12
масштабов
7:13
базы. А что насчёт актуальности,
7:16
актуализации данных data freshnшness?
7:19
Если информация меняется, укновляется
7:22
индекс, добавляются новые бединги,
7:24
удаляют старые, всё быстро и не требует
7:26
установки системы. А в К, если данные
7:29
часто меняются, нужно постоянно
7:31
загружать всё в кэш. Тогда преимущества
7:32
Кэш могут сойти на нет. Ведь обновление
7:35
кэша занимает, ну, занимает
7:39
время. Теперь давайте сыграем в игру Рек
7:43
или КК. В общем, мы просто разберём
7:45
несколько сценариев и будем решать,
7:47
какой метод подходит
7:48
лучше. Итак, первый сценарий. Делаем
7:52
чатбот для IT-поддержки, который
7:54
отвечает, опираясь на руководство по
7:57
продукту. Ну, примерно 200 страниц само
7:59
руководство обновляется пару раз в году.
8:02
Какой вариант выбрать?
8:06
5 секунд на размышление прошли, но
8:08
наверняка тут больше подойдёт вариант,
8:11
как ведь весь мануал легко помещается в
8:13
окно контекста, обновляется редко, и так
8:16
мы получим ответы быстрее, чем если бы
8:18
каждый раз ходили в векторную
8:21
базу. Давайте второй сценарий разберём.
8:24
Создаём ассистента для юридической
8:26
фирмы. Нужно искать по тысячам судебных
8:30
дел, которые постоянно обновляются
8:32
новыми поправками,
8:35
решениями, знать
8:37
законодательство. Юристам нужны, более
8:40
того, точные отсылки, да, на документы,
8:42
на пункты документов, где найдена
8:44
информация.
8:47
И здесь кажется, что уже больше подходит
8:50
рек, потому что база знаний огромная,
8:52
динамичная, загрузить всё сразу в
8:54
контекст невозможно, а с рек мы можем
8:56
постоянно обновлять базу, выдавать
8:58
точные ссылки, а где мы нашли
9:02
ответы. Да и для миллионных объёмов
9:05
документов рак рак гораздо эффективнее
9:08
будет.
9:10
Третий
9:10
сценарий: поддержка принятия клинических
9:14
решений в больницах для врачей,
9:18
докторов. Врачам нужно обращаться к
9:21
историям
9:22
болезней,
9:24
руководством по лечению, справочником по
9:26
лекарствам. Причём всё должно быть
9:28
максимально надёжно, потому что речь
9:29
идёт о здоровье
9:31
людей. Часто задаются дополнительные,
9:33
уточняющие вопросы: «А так что же
9:37
выбрать, как вы думаете?
9:39
Ну, на самом деле, никто же нам не
9:41
запрещает использовать и то, и другое.
9:43
Можно сначала использовать к, чтобы
9:46
извлечь нужные сведения из большой базы.
9:48
Ну, например, конкретные записи
9:49
пациента, нужное исследования, а потом
9:51
не просто отправлять эти части напрямую
9:53
в модель, а загружать их в контекст с
9:57
помощью как, чтобы модель помнила все
10:00
детали для дальнейших уточнений, не
10:02
запрашивала снова базу. Это получается у
10:06
нас гибридный подход.
10:08
Ну что ж, давайте теперь подытожим. К и
10:11
к — это два способа подключать внешнее
10:14
зание к большим языковым моделям. К
10:16
хорошо подходит, если у вас большой
10:18
набор данных, он часто меняется, нужны
10:20
ссылки на источники или у нас нет
10:23
ресурсов, чтобы использовать огромные
10:24
окна контекста. А КК лучше, когда у нас
10:27
фиксированный набор знаний, который
10:29
спокойно помещается в контекст,
10:32
когда требуется низкая задержка, то есть
10:35
высокая быстрота ответа. И когда, да, мы
10:38
просто хотим упростить своё решение и
10:43
развртували. Ну а на нашем
10:44
Telegram-канале IIDALX вы сможете
10:46
познакомиться и с другими техниками и
10:48
разработками и решений. Если вы хотите
10:51
научиться разобраться или заказать
10:53
подобных ассистентов, агентов под ключ
10:56
для своего бизнеса, то пишите нам
10:59
сообщение в Telegram Смирнов нижнее
11:01
подчёркивание. AI. Делитесь в
11:03
комментариях вашими впечатлениями,
11:05
ставьте лайки, подписывайтесь. И до
11:07
новых встреч, друзья.