Меня все время спрашивают, что такое RAG (в контексте больших языковых моделей) и я все время хочу дать ссылку на статью на habr, где бы простыми словами, но тем не менее детально была бы изложена концепция RAG (Retrieval Augmented Generation), включая инструкцию, как этого «зверя» реализовать. Но такой статьи все нет и нет, в итоге решил не дожидаться и написать самостоятельно.
Если в статье что‑то непонятно или есть какие‑то аспекты RAG, которые нужно раскрыть, не стесняйтесь, пишите комментарии, все разжую и дополню при необходимости. Ну все, поехали…
RAG (Retrieval Augmented Generation) — это метод работы с большими языковыми моделями, когда пользователь пишет свой вопросы, а вы программно к этому вопросу «подмешиваете» дополнительную информацию из каких‑то внешних источников и подаете все целиком на вход языковой модели. Другими словами вы добавляете в контекст запроса к языковой модели дополнительную информацию, на основе которой языковая модель может дать пользователю более полный и точный ответ.
Самый простейший пример:
Пользователь спрашивает модель: «какой сейчас курс доллара?»
Очевидно, что языковая модель понятия не имеет какой СЕЙЧАС курс доллара, эту информацию она должна откуда‑то получить, чтобы ответить на вопрос.
Что нужно сделать? Правильно, открыть первую ссылку в Google по запросу «курс доллара к рублю» и содержимое страницы добавить к вопросу пользователя, чтобы LLM могла правильно ответить на вопрос используя эту информацию.
Чуть более сложный пример:
Допустим вы делаете автоматического оператора технической поддержки на основе LLM. У вас есть база знаний вопросов и ответов или просто подробное описание функциональности.
Самое плохое, что может прийти вам в голову, это дообучить модель на вашу базу знаний вопрос‑ответ. Почему это плохо? Потому что база знаний будет постоянно меняться и постоянно дообучать модель это дорого и не эффективно.
RAG вам в помощь. В зависимости от того, какой вопрос задал пользователь ваша RAG система должна найти соответствующую статью в базе знаний, и подать на вход LLM не только вопрос пользователя, но и релевантную запросу часть содержимого базы знаний, чтобы LLM могла сформировать правильный ответ.
Таким образом фраза Retrieval Augmented Generation как нельзя более точно описывает суть происходящего:
Retrieval - поиск и извлечение релевантной информации. Часть системы, которая отвечает за поиск и извлечение информации, так и называют — ретривер (retriever).
Retrieval Augmented — дополнение запроса пользователя найденной релевантной информацией.
Retrieval Augmented Generation — генерация ответа пользователю с учетом дополнительно найденной релевантной информации.
А теперь самый главный вопрос, который мне задают, когда я вот на таком примитивном уровне объясняю концепцию RAG: ну и что тут сложного? Ищешь кусок данных и добавляешь его в контекст, получаешь PROFIT! Но дьявол как всегда в деталях и самые первые, лежащие на поверхности «детали» с которыми сталкивается человек, вознамерившийся «запилить RAG за один день» следующие:
Нечеткий поиск — просто взять запрос пользователя и найти по точному соответствию все куски из базы знаний не получится. Каким алгоритмом реализовать поиск, чтобы он искал релевантные и только релевантные «куски» текста?
Размер статей из базы знаний — какого размера «куски» текста надо давать LLM, чтобы она по ним формировала ответ?
А если в базе знаний нашлось несколько статей? А если они большие? Как их «обрезать», как комбинировать, может быть сжать?
Это самые базовые вопросы, с которыми сталкивается любой, начинающий создатель RAG. К счастью, на данный момент есть общепринятый подход, с которого нужно начинать создание RAG и далее, как в анекдоте, полученный «паровоз» допиливать напильником, чтобы получился нужный вам «истребитель».
Итак из чего состоит изначальный, базовый «паровоз» под названием RAG. Основной алгоритм его работы следующий:
Вся база знаний «нарезается» на небольшие куски текста, так называемые chunks (чанки по‑русски). Размер этих chunks может варьироваться от нескольких строк, до нескольких абзацев, т. е. примерно 100 до 1000 слов.
Далее эти чанки оцифровываются с помощью «эмбеддера» и превращаются в эмбеддинги или другимими словами в вектора, некоторые наборы чисел. Считается, что в этих числах зашит скрытый смысл всего чанка, и именно по этому смыслу и можно производить поиск.
Далее все эти полученные вектора складываются в специальную базу данных, где лежат и ждут пока над ними и начнут производить ту самую операцию поиска (наиболее релевантных, т. е. близких по смыслу чанков поисковому запросу).
Когда пользователь отправляет свой вопрос в LLM, то текст его запроса точно по такому же алгоритму (как правило тем же самым эмбеддером), кодируется также в еще один эмбеддинг и далее над базой данных содержащей наши эмбеддинги чанков производится поиск наиболее близких «по смыслу» эмбеддингов (векторов). В реальности, как правило, считается косинусная близость вектора запроса и вектора каждого чанка и далее выбираются топ N векторов наиболее близких к запросу.
Далее текст чанков, соответствующий этим найденным векторам, вместе с запросом пользователя объединяется в единый контекст и подается на вход языковой модели. т. е. модель «думает», что пользователь написал ей не только вопрос, но еще и предоставил данные на основе которых нужно ответить на поставленный вопрос.
Как видно из описания ничего сложного: разбили текст на куски (чанки), каждый кусок оцифровали, нашли наиболее близкие по смыслу куски и подали текст этих кусков на вход большой языковой модели вместе с запросом от пользователя. Более того, весь этот процесс как правило уже реализован в так называемом пайплайне и все, что вам нужно, это собственно запустить пайплайн (из какой‑нибудь готовой библиотеки).
Написав первую версию и подав на вход несколько документов можно убедится в том, что полученный алгоритм в 100% случаев работает не так, как от него ожидалось и далее начинается долгий и сложный процесс допиливания RAG напильником, чтобы работало так как надо.
Ниже я опишу основные идеи и принципы допиливания RAG напильником, а во второй статье раскрою каждый из принципов в отдельности (возможно это будет серия статей, чтобы не получилась одна большая, бесконечная простыня).
Размер чанков и их количество. Настоятельно рекомендую начать эксперименты с изменения размера чанков и их количества. Если вы подаете на вход LLM слишком много ненужной информации или наоборот, слишком мало, то вы просто не оставляете шансов модели ответить правильно:
Чем меньше чанк по размеру, тем точнее будет буквальный поиск, чем больше размер чанка тем больше поиск приближается к смысловому.
Разные запросы пользователя могут содержать разное количество чанков, которое необходимо добавлять в контекст. Необходимо опытным путем подобрать тот самый коэффициент, ниже которого чанк смысла не имеет и будет лишь замусоривать ваш контекст.
Чанки должны перекрывать друг друга, чтобы у вас был шанс подать на вход последовательность чанков, которые следуют друг за другом вместе, а не просто вырванные из контекста куски.
Начало и конец чанка должны быть осмысленными, в идеале должны совпадать с началом и концом предложения, а лучше абзаца, чтобы вся мысль была в чанке целиком.
Добавление других методов поиска. Очень часто поиск «по смыслу» через эмбеддинги не дает нужного результата. Особенно если речь идет о каких‑то специфических терминах или определениях. Как правило к поиску через эмбеддинги подключают также TF‑IDF поиск и объединяют результаты поиска в пропорции, подобранной экспериментальным путем. Также очень часто помогает ранжирование найденных результатов например алгоритмом BM25.
Мультиплицирование запроса. Как правило, запрос от пользователя имеет смысл несколько раз перефразировать (с помощью LLM) и осуществлять поиск чанков по всем вариантам запроса. На практике сделают от 3-х до 5-ти вариаций запросов и потом результаты поиска объединяют в один.
Суммаризация чанков. Если по запросу пользователя найдено очень много информации и вся эта информация не помещается в контекст, то ее можно точно также «упростить» с помощью LLM и подать на вход в виде контекста (в добавление к вопросу пользователя) нечто вроде заархивированного знания, чтобы LLM могла использовать суть (выжимку из базы знаний) при формировании ответа.
Системный промпт и дообучение модели на формат RAG. Чтобы модель лучше понимала, что от нее требуется возможно также дообучить LLM на правильный формат взаимодействия с ней. В подходе RAG контекст, всегда состоит из двух частей (мы пока не рассматриваем вариант диалога в формате RAG): вопроса пользователя и найденного контекста. Соответственно модель можно дообучить понимать именно вот такой формат: тут вопрос, тут информация для ответа, выдай ответ, к вопросу. На первоначальном этапе эту проблему можно также попытаться решить через системный промпт, объяснив модели, что «вопрос тут, инфа тут, не перепутай!».
В заключение хочу отметить самую важную вещь, которую необходимо реализовать при работе с RAG. С первой же минуты, когда вы возьмете в руки напильник и начнете подпиливать RAG у вас встанет вопрос оценки качество того, что у вас получается. Пилить вслепую не вариант, каждый раз проверять качество руками тоже не вариант, потому что проверять желательно не один и не два, а десятки, а лучше сотни вопросов/ответов, даже после небольшого, единичного изменения. Я уже не говорю, что при смене библиотеки эмбеддера или генеративной LLM нужно запустить как минимум несколько десятков тестов и оценить качество результата. Как правило для оценки качества RAG модели используют следующие подходы:
Вопросы для проверки — должны быть написаны человеками. Тут никуда нельзя деться, только вы (или ваш заказчик) знает какие вопросы будут задаваться системе и ни кто, кроме вас проверочные вопросы не напишет.
Референсные (золотые) ответы — тоже в идеале должны быть написаны людьми, и желательно разными и в двух (а то и трех) экземплярах, чтобы избавиться от зависимости от человеческого фактора. Но тут, что называется, есть варианты. Например Ассистенты от OpenAI на модели GPT Turbo вполне себе не плохо справляются с этой задачей, особенно если в них не грузить большие (более 100 страниц) документы. Для получения референсных ответов, можно написать скрипт, который обратиться к ассистенту (в который загружены релевантные документы) и задаст ему все ваши вопросы для проверки. Причем несколько раз один и тот же вопрос.
Близость ответов LLM к референсным — измеряется несколькими метриками, такими как BERTScore, BLEURT, METEOR и даже простым ROUGE. Как правило опытным путем подбирается средневзвешенная метрика, являющаяся суммой вышеперечисленных (с соответствующими коэффициентами) которая наиболее точно отражает реальную близость ответов вашей LLM к золотым ответам.
Референсные чанки и близость найденных чанков к референсным. Как правило начинающий создатель RAG в своем желании побыстрее получить хорошие ответы от генератора напрочь забывает про то, что найденные чанки, которые подаются на вход этому генератору обеспечивают 80% качества ответа. Поэтому при разработке RAG первостепенное внимание необходимо уделить тем самым данным, которые нашел ретривер. В первую очередь необходимо создать базу данных из вопросов и соответствующим им чанков и каждый раз допиливании RAG напильником проверать насколько точно ретривер нашел чанки, соответствующие запросу от пользователя.
Жду ваши вопросы и замечания!
Комментарии (20)
AlexanderAnisimov
09.12.2023 17:13Тут в соседней статье на похожую тему коллега поднимал правильный вопрос: такая система должна давать не только ответ на поставленный вопрос, но и ссылку на первоисточники, откуда конкретно этот ответ взялся и где его можно перепроверить.
Эта фича входит в концепцию RAG? Или не барское это дело?
dimasklyarov Автор
09.12.2023 17:13Да, конечно, входит. У тех же ассистентов Open AI это реализовано вполне грамотно. Если в ассистенте Open AI включен флажок Retrieval и загружены документы, то в тексте ответа ассистента будут ссылки на части документа, которые были использованы при ответе.
Но, по моим наблюдениям, эта фича не прям супер полезная и юзабельная для конечного пользователя. Объясню почему. Когда пользователь ведет диалог с LLM, то он хочет получать информацию именно в режиме диалога, как будто он говорит с реальным "человеком". Т.е. пользователь читает текст ответа и "идет" дальше. Пользователю проще переспросить, если он что-то недопонял или уточнить информацию у ассистента, чем "копаться" в ссылках. Ссылки на документы, из которых была извлечена информация, в каких-то сценариях возможно и будут интересны конечному потребителю, но в массе своей пользователь хочет видеть четкий, понятный и исчерпывающий ответ в самом тексте ответа.
PS. Ссылки на источники в ответе LLM могут быть полезны в первую очередь тому, кто занимается настройкой ассистента, вот ему/ей надо знать ответ на вопрос: "почему LLM так ответила?".
AlexanderAnisimov
09.12.2023 17:13Полезность этой фичи для пользователя оставим за скобками. Пользователи бывают разные - кому-то нужно, кому-то нет.
Было бы любопытно посмотреть на конкретные примеры как это работает у ассистентов (подозреваю что никак).
И интересно было бы почитать первоисточники что про это пишут разработчики RAG.
AlexanderAnisimov
Вопросы по поводу ассистентов:
Являются ли ассистенты RAG-инструментами? Если нет, то почему?
"Ищешь кусок данных и добавляешь его в контекст" - эта постановка вопроса выглядит на первый взгляд устаревшей. Кажется правильным говорить что нужно добавлять не кусок данных в контекст, а всю базу знаний в ассистента. И пусть уже он сам там разбирается где что искать (с помощью правильных Instructions и, возможно, файн-тьюнинга). Нет? Вроде бы об этом написано в пункте про референсные ответы"? Почему все вопросы-ответы нельзя сделать такими же как "рефернсные"?
dimasklyarov Автор
Если мы говорим про ассистентов OpenAI, то в них да, тоже встроен механизм RAG, точнее его в них можно включить. В каждом ассистенте Open AI есть переключатель с названием "Retrieval" его нужно включить, далее загрузить в Ассистента файлы (до 20 штук на данный момент) и ассистент Open AI получает возможность читать эти файлы и извлекать из них информацию. По умолчанию Retrieval в ассистентах Open AI выключен.
К сожалению далеко не все модели сейчас могут получать на вход в виде контекста 128 тыс токенов как GPT-4 Turbo у OpenAI, поэтому всю базу знаний в контекст не "впихнешь" никак. Да и 128 тыс токенов это тоже не панацея, базы знаний могут быть сильно больше по размеру. Поэтому приходится выбирать только то, что релевантно запросу. Кроме того, LLM в данный момент не совершенны и не могут со 100% точностью выбирать из всего контекста только то, что относится к запросу от клиента. Перегружая контекст "лишней", не относящейся к запросу клиента информацией, Вы "провоцируете" модель отвечать неправильно.
AlexanderAnisimov
Ну т.е. выглядит так что OpenAI выпуском своих ассистентов убил всю эту сферу разработки каких-то специальных навороченных проблемных механизмов RAG - все в итоге свелось к тому что бы создать ассистента и прицепить к нему базу знаний. И вся эта канитель с чанками и тестами осталась в темном средневековом прошлом. Нет?
А при чем тут контекст модели? Ассистент работает с прикрепленными файлами у которых ограничение no more than 2,000,000 tokens (computed automatically when you attach a file). https://platform.openai.com/docs/assistants/tools/knowledge-retrieval
hrapovitskye
@AlexanderAnisimov, добрый вечер.
В целом методология RAG работает через передачу данных в модель через контекст. Модели OpenAI на данный момент имеют максимальную длину контекста 128к токенов. Для того чтобы бороться с проблемой использую разбиение всей базы знаний (в контексте вашего вопроса - файлов) на части ограниченной длины, помещаются в векторную БД. Для ответа на вопрос - подбираются куски файлов с наиболее подходящим содержимым, их и помещают в контекст.
Поиск происходит с помощью сравнение embiding'ов части документа и запроса пользователя в семантическом векторном пространстве ( https://habr.com/ru/companies/ods/articles/329410/ ). Выбираются N самых похожих на запрос пользователя.
При слишком большом суммарном размере всех частей - они могут быть суммаризированны, но это может привести к некоторой потере деталей.
Отвечая конкретно по вопросам:
1. Проблемы некуда не ушли, просто OpenAI ассистенты сильно упростили создание простых RAG ботов, но это не подходит для больших баз знаний.
2. Контекста ассистента все так же дробится на N частей и загружается в векторную базу, по которой, в момент вопроса, ассистент попробует найти самые актуальные части и с их помощью ответить.
Надеюсь я не запутал вас еще больше.
AlexanderAnisimov
Т.е. получается что существует "простой RAG", который решается ассистентами и "сложный RAG" для которого ассистенты не подходят и нужно пилить вручную? Если так, то где между ними граница? Хотя бы примерно.
Т.е. у ассистента под капотом спрятан механизм разбивки двух миллионов токенов из прикрепленного файла на мелкие куски подходящие для модельного контекста? Т.е. он берет на себя всю работу, описанную в статье? Зачем тогда нужны все эти подробности про чанки, если теперь все это доступно из коробки и достаточно просто воспользоваться ассистентом не вникая в подробности? Ассистенты плохо справляются с этой работой и поэтому надо пилить эти внутренности вручную?
dimasklyarov Автор
На мой взгляд, логика "границы" проходит между SaaS и On Premise решением. Если есть возможность иcпользовать SaaS, то конечно нужно брать SaaS (в данном случае Open AI ассистентов) и использовать их, даже не думая изобретать велосипед. НО! Если бюджет не позволяет, или соображения по информ. безопасности не позволяют, или технические ограничения (2 млн токенов, 20 файлов, форматы файлов и т.д.) не позволяют использовать SaaS решение, то нужно садиться и пилить свой собственный RAG и использовать его.
Очень хотелось бы узнать, что у ассистентов Open AI под капотом :). Надеюсь Open AI когда-нибудь оправдает свое название и сделает свой код открытым. А пока я руководствуюсь логикой из пункта №1: "если можно SaaS, то SaaS, если нет, то пилим "свое" решение".
AlexanderAnisimov
Получается что статья про RAG должна начинаться следующим образом:
Для 99% пользователей для ознакомления с RAG достаточно двух вещей:
Посмотреть вводную лекцию Ына https://www.coursera.org/learn/generative-ai-for-everyone/lecture/qF1Az/retrieval-augmented-generation-rag
Научиться пользоваться ассистентами (для начала хотя бы на самом примитивном уровне https://habr.com/ru/articles/778414/)
Все, больше про RAG ничего знать не нужно.
Оставшимся 1% (кто не пролезает по финансам, размерам или безопасности) придется все это пилить вручную - и дальше текст статьи с техническими подробностями.
Получается что тут возникает целый новый раздел экономической науки: Технико-экономическое обоснование запила RAG своими руками.
hrapovitskye
@AlexanderAnisimov
В целом RAG это методология которая не связана с продуктами OpenAI, она дает подход, который позволяет LLM отвечать на вопросы, информацию по которым отсутствует в обучающей выборке. Это работает для любой LLM, включая OnPremise решения.
Ответ на оба вопроса:
Граница на данный момент в объеме данных которые можно предоставить по теме в которой работает LLM. В большой компании объем прикладных данных (документация, FAQ, записи по собраниям, общение с подрядчиками и т.п.) сильно превышает 2кк токенов, к тому же все время обновляется, да и не всегда понятно в каком документе ответ на вопрос содержится, тогда собирают целые пайплайны выгрузки, обработки, обогащения метаданными (Например откуда взята информация, кто автор, документ в процессе написания или уже завершен) и загрузки их в векторное хранилище, чтобы потом любая LLM могла их использовать в процессе генерации ответа.
В целом разница между "простым ассистентом" и "сложным RAG" и тут только в автоматизации и объеме:
- для личного пользования подойдет и ассистент, просто грузим пачку доков и задаем вопросы
- для корпоративного - уже более сложный подход с пайплайнами подготовки данных
AlexanderAnisimov
То что "вся документация в большой компании" превышает 2млн токенов - это понятно.
Сомнительно что ее всю реально есть смысл валить в одну кучу. Наверняка она разделена по каким-то крупным блокам (проектам, продуктам, направлениям). И то что размер каждого блока превышает 2млн - это уже не очевидно. Действительно есть статистика что 2млн - это на практике критическое ограничение?
hrapovitskye
@AlexanderAnisimov
Ассистент это упрощенный способ использования RAG, сама методология RAG появилась раньше чем этот инструмент.
По поводу разделения по блокам - вариант рабочий, но не всегда удобный. Плюс есть и другие ограничения на использование ассистентов.
По целесообразность таких статей могу сказать следующее:
Это не научная статья об открытии, а базовые знания по методологии. Да, сейчас появились инструменты которые позволяют все сделать проще(Убирая тонкости реализации RAG под капот), но это все равно знания которые лежат в основе понимания применения LLM. Мы же не убираем учебники по базовой математике из-за того что появились калькуляторы.
AlexanderAnisimov
Если статья начинается с вопроса "что такое автомобиль", то наверно логично было бы объяснить что это самодвижущаяся железка с колесами и рулем, и дальше дать ПДД и методичку для автошколы.
Университетский курс автомобилестроения тоже имеет право на существование, но только его надо правильно позиционировать и ввести в общий контекст.
Самая первая фраза в тексте наводит больше на мысли о методичке для автошколы. Даже если предполагается учебник по автомобилестроению, то было бы неплохо как-то более аккуратно обойтись с контекстом. Типа вот есть машины, их можно купить в автосалоне (вот адрес автосалона) и ездить (вот ссылка на скачивание ПДД). А если вы не ищете легких путей, то в этой статье мы рассмотрим изобретение колеса, ДВС и автомобиля с нуля.
Вместо этого в статье получается что пункт с автосалоном и ПДД пропущен, сразу начинается с изобретения автомобиля. Для неподготовленного читателя это может быть немного confusing.
dimasklyarov Автор
Скорее не убил, а показал на что надо ориентироваться при создании своего собственного RAG. У OpenAI ассистентов сейчас есть свои ограничения. Во-первых, те самые 20 файлов, т.е. нельзя просто взять и закинуть в ассистента сотни файлов с документами, нужно объединять в 20 файлов. Во-вторых, далеко не все форматы файлов сейчас поддерживаются, из моего опыта только docx и pdf. Другие форматы: txt, cvs, xls и т.д. я не смог добавить, выдает ошибку. И в-третьих, размер файла не более 2 млн токенов. Но я думаю, что это вопрос времени, OpenAI конечно же исправится и будет любое число фалов, любого формата, любого размера. И если у Вас не будет ограничения (ни финансового, ни по соображениям информ безопосности), то скорее всего правильнее использовать Open AI, так как это State Of The Art на данный момент.
У меня есть подозрение (по моим практическим опытам с Open AI ассистентами), что ассистент Open AI все-таки грузит весь документ в контекст, когда это возможно. Потому что если в ассистента Open AI загрузить много больших документов, то он начинает в них путаться и выдавать ответы не очень точные. При этом если взять один документ, вырезать из него нужный раздел и загрузить в ассистента, то он отвечает идеально.
AlexanderAnisimov
Судя по этим объяснениям выглядит так что все-таки убил. 2млн - это не ограничение, это скорее синоним "без ограничений". Что за такая база знаний которая не помещается в лимит два миллиона? Если только на языках, отличающихся от английского, да и то сложно представить. 20 файлов и конверсия в док и пдф - это вообще не повод для разговора про ограничения. ТХТ тоже поддерживается, я пробовал, правда с микроскопическим файлом. csv/xls действительно не поддерживается для ретривала (https://platform.openai.com/docs/assistants/tools/supported-files). Но если на другой чаше весов собственноручная разработка, то проще наверно эксель сконвертировать в док или прикрутить его к Code interpreter. В общем все эти "ограничения" выглядят крайне маргинальными.
Тут хотелось бы больше подробностей. С какого размера/объема начинаются ошибки, масштаб этих ошибок, до какой степени удается эти ошибки устранить в собственноручной разработке.
akakoychenko
Касательно п2, тут все просто, - RAG это костыль (и, весьма противоречивый костыль) для обхода ограничения на размер промпта. Разумеется, если б промпт был бесконечен, то все данные просто бы в него и клали
dimasklyarov Автор
Согласен:
если бы промпт был бесконечным
если бы скорость обработки промпта была бы неограниченной
если бы модель была бы настолько совершенна, что не сбивалась бы с толку, имея в своем промпте кучу ненужной информации
то тогда да, можно было бы в промпт пихать все подряд, главное чтобы там "среди всего прочего" содержалось то, что нужно модели для ответа.
Но, к сожалению, на данном этапе развития ни одно из вышеперечисленных условий пока не выполняется, поэтому нужен RAG.
akakoychenko
Угу. Но, с другой стороны, человеку ж RAG не нужен. Человек же, имея талмуд на 1000 страниц, способен заглянуть в него, и уточнить, если не может дать ответ сходу.
Как думаете, почему этим путем не пошло? Чтобы модель сама инициировала RAG, давая ключевые слова?
dimasklyarov Автор
Все, что может делать сейчас LLM модель, это предсказывать следующее слово на основе всего предыдущего контекста. Ожидать от модели "разумного" поведения типа: "мне не хватает вот такой-то информации, дайте мне ее и тогда я вам отвечу" на данном этапе не приходится :). Модель - это просто генератор текста, на основе поданного в нее контекста.
Тем не менее, справедливости ради, надо сказать, что ассистенты Open AI хорошо продвинулись в описанном Вами пути. Они (ассистенты) могут вызвать внешние функции если им не хватает информации для ответа. Например, я программировал ассистента, который получает недостающую ему информацию из Интернета. В системном промпте я писал ассистенту Open AI: "Если тебе не хватает информации для ответа, вызови функцию get_info c параметром search_query, в результате ты получишь первые три страницы из поиска Google". И для простейших вопросов типа "какой курс доллара" ассистент вполне справлялся с полученной задачей - запрашивал недостающую ему информацию. Ассистент реально вызывает внешнюю функцию и подставляет в нее разумный вопрос в качестве параметра.
НО! Ассистенты Open AI это произведение искусства, запрограммировать Ассистента несколько сложнее, чем запрограммировать RAG :).