Комментарии 30
Вопросы по поводу ассистентов:
Являются ли ассистенты RAG-инструментами? Если нет, то почему?
"Ищешь кусок данных и добавляешь его в контекст" - эта постановка вопроса выглядит на первый взгляд устаревшей. Кажется правильным говорить что нужно добавлять не кусок данных в контекст, а всю базу знаний в ассистента. И пусть уже он сам там разбирается где что искать (с помощью правильных Instructions и, возможно, файн-тьюнинга). Нет? Вроде бы об этом написано в пункте про референсные ответы"? Почему все вопросы-ответы нельзя сделать такими же как "рефернсные"?
Если мы говорим про ассистентов OpenAI, то в них да, тоже встроен механизм RAG, точнее его в них можно включить. В каждом ассистенте Open AI есть переключатель с названием "Retrieval" его нужно включить, далее загрузить в Ассистента файлы (до 20 штук на данный момент) и ассистент Open AI получает возможность читать эти файлы и извлекать из них информацию. По умолчанию Retrieval в ассистентах Open AI выключен.
К сожалению далеко не все модели сейчас могут получать на вход в виде контекста 128 тыс токенов как GPT-4 Turbo у OpenAI, поэтому всю базу знаний в контекст не "впихнешь" никак. Да и 128 тыс токенов это тоже не панацея, базы знаний могут быть сильно больше по размеру. Поэтому приходится выбирать только то, что релевантно запросу. Кроме того, LLM в данный момент не совершенны и не могут со 100% точностью выбирать из всего контекста только то, что относится к запросу от клиента. Перегружая контекст "лишней", не относящейся к запросу клиента информацией, Вы "провоцируете" модель отвечать неправильно.
Ну т.е. выглядит так что 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
@AlexanderAnisimov, добрый вечер.
В целом методология RAG работает через передачу данных в модель через контекст. Модели OpenAI на данный момент имеют максимальную длину контекста 128к токенов. Для того чтобы бороться с проблемой использую разбиение всей базы знаний (в контексте вашего вопроса - файлов) на части ограниченной длины, помещаются в векторную БД. Для ответа на вопрос - подбираются куски файлов с наиболее подходящим содержимым, их и помещают в контекст.
Поиск происходит с помощью сравнение embiding'ов части документа и запроса пользователя в семантическом векторном пространстве ( https://habr.com/ru/companies/ods/articles/329410/ ). Выбираются N самых похожих на запрос пользователя.
При слишком большом суммарном размере всех частей - они могут быть суммаризированны, но это может привести к некоторой потере деталей.
Отвечая конкретно по вопросам:
1. Проблемы некуда не ушли, просто OpenAI ассистенты сильно упростили создание простых RAG ботов, но это не подходит для больших баз знаний.
2. Контекста ассистента все так же дробится на N частей и загружается в векторную базу, по которой, в момент вопроса, ассистент попробует найти самые актуальные части и с их помощью ответить.
Надеюсь я не запутал вас еще больше.
Т.е. получается что существует "простой RAG", который решается ассистентами и "сложный RAG" для которого ассистенты не подходят и нужно пилить вручную? Если так, то где между ними граница? Хотя бы примерно.
Т.е. у ассистента под капотом спрятан механизм разбивки двух миллионов токенов из прикрепленного файла на мелкие куски подходящие для модельного контекста? Т.е. он берет на себя всю работу, описанную в статье? Зачем тогда нужны все эти подробности про чанки, если теперь все это доступно из коробки и достаточно просто воспользоваться ассистентом не вникая в подробности? Ассистенты плохо справляются с этой работой и поэтому надо пилить эти внутренности вручную?
На мой взгляд, логика "границы" проходит между SaaS и On Premise решением. Если есть возможность иcпользовать SaaS, то конечно нужно брать SaaS (в данном случае Open AI ассистентов) и использовать их, даже не думая изобретать велосипед. НО! Если бюджет не позволяет, или соображения по информ. безопасности не позволяют, или технические ограничения (2 млн токенов, 20 файлов, форматы файлов и т.д.) не позволяют использовать SaaS решение, то нужно садиться и пилить свой собственный RAG и использовать его.
Очень хотелось бы узнать, что у ассистентов Open AI под капотом :). Надеюсь Open AI когда-нибудь оправдает свое название и сделает свой код открытым. А пока я руководствуюсь логикой из пункта №1: "если можно SaaS, то SaaS, если нет, то пилим "свое" решение".
Получается что статья про 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 своими руками.
@AlexanderAnisimov
В целом RAG это методология которая не связана с продуктами OpenAI, она дает подход, который позволяет LLM отвечать на вопросы, информацию по которым отсутствует в обучающей выборке. Это работает для любой LLM, включая OnPremise решения.
Ответ на оба вопроса:
Граница на данный момент в объеме данных которые можно предоставить по теме в которой работает LLM. В большой компании объем прикладных данных (документация, FAQ, записи по собраниям, общение с подрядчиками и т.п.) сильно превышает 2кк токенов, к тому же все время обновляется, да и не всегда понятно в каком документе ответ на вопрос содержится, тогда собирают целые пайплайны выгрузки, обработки, обогащения метаданными (Например откуда взята информация, кто автор, документ в процессе написания или уже завершен) и загрузки их в векторное хранилище, чтобы потом любая LLM могла их использовать в процессе генерации ответа.
В целом разница между "простым ассистентом" и "сложным RAG" и тут только в автоматизации и объеме:
- для личного пользования подойдет и ассистент, просто грузим пачку доков и задаем вопросы
- для корпоративного - уже более сложный подход с пайплайнами подготовки данных
То что "вся документация в большой компании" превышает 2млн токенов - это понятно.
Сомнительно что ее всю реально есть смысл валить в одну кучу. Наверняка она разделена по каким-то крупным блокам (проектам, продуктам, направлениям). И то что размер каждого блока превышает 2млн - это уже не очевидно. Действительно есть статистика что 2млн - это на практике критическое ограничение?
@AlexanderAnisimov
Ассистент это упрощенный способ использования RAG, сама методология RAG появилась раньше чем этот инструмент.
По поводу разделения по блокам - вариант рабочий, но не всегда удобный. Плюс есть и другие ограничения на использование ассистентов.
По целесообразность таких статей могу сказать следующее:
Это не научная статья об открытии, а базовые знания по методологии. Да, сейчас появились инструменты которые позволяют все сделать проще(Убирая тонкости реализации RAG под капот), но это все равно знания которые лежат в основе понимания применения LLM. Мы же не убираем учебники по базовой математике из-за того что появились калькуляторы.
Если статья начинается с вопроса "что такое автомобиль", то наверно логично было бы объяснить что это самодвижущаяся железка с колесами и рулем, и дальше дать ПДД и методичку для автошколы.
Университетский курс автомобилестроения тоже имеет право на существование, но только его надо правильно позиционировать и ввести в общий контекст.
Самая первая фраза в тексте наводит больше на мысли о методичке для автошколы. Даже если предполагается учебник по автомобилестроению, то было бы неплохо как-то более аккуратно обойтись с контекстом. Типа вот есть машины, их можно купить в автосалоне (вот адрес автосалона) и ездить (вот ссылка на скачивание ПДД). А если вы не ищете легких путей, то в этой статье мы рассмотрим изобретение колеса, ДВС и автомобиля с нуля.
Вместо этого в статье получается что пункт с автосалоном и ПДД пропущен, сразу начинается с изобретения автомобиля. Для неподготовленного читателя это может быть немного confusing.
Насколько сильно по опыту превышвет 2кк токенов в коупной компании?
Скорее не убил, а показал на что надо ориентироваться при создании своего собственного RAG. У OpenAI ассистентов сейчас есть свои ограничения. Во-первых, те самые 20 файлов, т.е. нельзя просто взять и закинуть в ассистента сотни файлов с документами, нужно объединять в 20 файлов. Во-вторых, далеко не все форматы файлов сейчас поддерживаются, из моего опыта только docx и pdf. Другие форматы: txt, cvs, xls и т.д. я не смог добавить, выдает ошибку. И в-третьих, размер файла не более 2 млн токенов. Но я думаю, что это вопрос времени, OpenAI конечно же исправится и будет любое число фалов, любого формата, любого размера. И если у Вас не будет ограничения (ни финансового, ни по соображениям информ безопосности), то скорее всего правильнее использовать Open AI, так как это State Of The Art на данный момент.
У меня есть подозрение (по моим практическим опытам с Open AI ассистентами), что ассистент Open AI все-таки грузит весь документ в контекст, когда это возможно. Потому что если в ассистента Open AI загрузить много больших документов, то он начинает в них путаться и выдавать ответы не очень точные. При этом если взять один документ, вырезать из него нужный раздел и загрузить в ассистента, то он отвечает идеально.
Судя по этим объяснениям выглядит так что все-таки убил. 2млн - это не ограничение, это скорее синоним "без ограничений". Что за такая база знаний которая не помещается в лимит два миллиона? Если только на языках, отличающихся от английского, да и то сложно представить. 20 файлов и конверсия в док и пдф - это вообще не повод для разговора про ограничения. ТХТ тоже поддерживается, я пробовал, правда с микроскопическим файлом. csv/xls действительно не поддерживается для ретривала (https://platform.openai.com/docs/assistants/tools/supported-files). Но если на другой чаше весов собственноручная разработка, то проще наверно эксель сконвертировать в док или прикрутить его к Code interpreter. В общем все эти "ограничения" выглядят крайне маргинальными.
Тут хотелось бы больше подробностей. С какого размера/объема начинаются ошибки, масштаб этих ошибок, до какой степени удается эти ошибки устранить в собственноручной разработке.
Касательно п2, тут все просто, - RAG это костыль (и, весьма противоречивый костыль) для обхода ограничения на размер промпта. Разумеется, если б промпт был бесконечен, то все данные просто бы в него и клали
Согласен:
если бы промпт был бесконечным
если бы скорость обработки промпта была бы неограниченной
если бы модель была бы настолько совершенна, что не сбивалась бы с толку, имея в своем промпте кучу ненужной информации
то тогда да, можно было бы в промпт пихать все подряд, главное чтобы там "среди всего прочего" содержалось то, что нужно модели для ответа.
Но, к сожалению, на данном этапе развития ни одно из вышеперечисленных условий пока не выполняется, поэтому нужен RAG.
Угу. Но, с другой стороны, человеку ж RAG не нужен. Человек же, имея талмуд на 1000 страниц, способен заглянуть в него, и уточнить, если не может дать ответ сходу.
Как думаете, почему этим путем не пошло? Чтобы модель сама инициировала RAG, давая ключевые слова?
Все, что может делать сейчас LLM модель, это предсказывать следующее слово на основе всего предыдущего контекста. Ожидать от модели "разумного" поведения типа: "мне не хватает вот такой-то информации, дайте мне ее и тогда я вам отвечу" на данном этапе не приходится :). Модель - это просто генератор текста, на основе поданного в нее контекста.
Тем не менее, справедливости ради, надо сказать, что ассистенты Open AI хорошо продвинулись в описанном Вами пути. Они (ассистенты) могут вызвать внешние функции если им не хватает информации для ответа. Например, я программировал ассистента, который получает недостающую ему информацию из Интернета. В системном промпте я писал ассистенту Open AI: "Если тебе не хватает информации для ответа, вызови функцию get_info c параметром search_query, в результате ты получишь первые три страницы из поиска Google". И для простейших вопросов типа "какой курс доллара" ассистент вполне справлялся с полученной задачей - запрашивал недостающую ему информацию. Ассистент реально вызывает внешнюю функцию и подставляет в нее разумный вопрос в качестве параметра.
НО! Ассистенты Open AI это произведение искусства, запрограммировать Ассистента несколько сложнее, чем запрограммировать RAG :).
Тут в соседней статье на похожую тему коллега поднимал правильный вопрос: такая система должна давать не только ответ на поставленный вопрос, но и ссылку на первоисточники, откуда конкретно этот ответ взялся и где его можно перепроверить.
Эта фича входит в концепцию RAG? Или не барское это дело?
Да, конечно, входит. У тех же ассистентов Open AI это реализовано вполне грамотно. Если в ассистенте Open AI включен флажок Retrieval и загружены документы, то в тексте ответа ассистента будут ссылки на части документа, которые были использованы при ответе.
Но, по моим наблюдениям, эта фича не прям супер полезная и юзабельная для конечного пользователя. Объясню почему. Когда пользователь ведет диалог с LLM, то он хочет получать информацию именно в режиме диалога, как будто он говорит с реальным "человеком". Т.е. пользователь читает текст ответа и "идет" дальше. Пользователю проще переспросить, если он что-то недопонял или уточнить информацию у ассистента, чем "копаться" в ссылках. Ссылки на документы, из которых была извлечена информация, в каких-то сценариях возможно и будут интересны конечному потребителю, но в массе своей пользователь хочет видеть четкий, понятный и исчерпывающий ответ в самом тексте ответа.
PS. Ссылки на источники в ответе LLM могут быть полезны в первую очередь тому, кто занимается настройкой ассистента, вот ему/ей надо знать ответ на вопрос: "почему LLM так ответила?".
Полезность этой фичи для пользователя оставим за скобками. Пользователи бывают разные - кому-то нужно, кому-то нет.
Было бы любопытно посмотреть на конкретные примеры как это работает у ассистентов (подозреваю что никак).
И интересно было бы почитать первоисточники что про это пишут разработчики RAG.
Добрий день.
Спасибо за статтю на тему RAG.
Есть вопрос относительно проверки информации которую генерирует АІ, т.е. проверки на галюцинации.
Какие существуют подходи для того чтоби проверить что OpenAI сгенерировал правильно информацию и не добавил в ответ на промт своих галюцинаций?
К сожалению пока до темы галлюцинаций в LLM не добрался. Занимаюсь разработкой RAG. Извините, пожалуйста, что не могу помочь в этом вопросе.
нет решения этой задачи пока. но есть идеи. не знаю как прикрепить урл на пост в телеграме.
Вот ссылка на этот пост: https://t.me/llm_under_hood/230
Добрый день. Вопрос к опытным людям.
Есть идея, сделать ИИ помощника для технологической сферы. Нужно будет "скормить" программе стопку нормативов и море проектов из архива. Задача - система по запросу выдавала бы готовые куски текста для последующей вставки в новую документацию. В идеале научить понимать чертежи, что бы скинул чертеж - ИИ порылся в базе и выдал инструкцию как это сделать. Не могли бы вы посоветовать, с чего начать изучение и на основе чего вести разработку.
вот вы пишете про "дообучение модели на формат RAG" а вы это пробовали сами?
RAG (Retrieval Augmented Generation) — простое и понятное объяснение