Комментарии 52
Почему было решено делить на синтетические чанки вместо выделения каждого пункта в отдельный чанк? У вас же информация уже разделена логически.
Рассматривали ли идею генерации краткого содержания каждого из пунктов и использования его в качестве "чанка" (или, еще интереснее, комбинирования таких содержаний в большой промт для, например, Claude)?
Не знаю точно какого размера в среднем у вас контекст при ответе на вопрос, но в целом, не получится ли так что можно просто все релевантные пункты запихнуть в один контекст и тогда токенизация и вектроризация вообще не нужны?
(или, еще интереснее, комбинирования таких содержаний в большой промт для, например, Claude)?
Все-таки таргет у такой системы - локальный запуск, а для опенсорс моделей вроде как 100к нормального контекста нет, и рассчитывать на него не приходится.
Все так. Если нет никаких ограничений по облаку и зарубежным сервисам, то можно не заморачиваться и просто бить на огромные куски. GPT4-Turbo контекст больше Claude. 128К токенов. Это десятки страниц... И он работает, только дорого получается. около 0.2 $ за запрос.
У последней версии Claude контекст - 200К токенов (и вроде как они готовят версию на 400К).
Вопрос цены конечно тоже стоит, но тут именно с точки зрения исследования было бы интересно проверить - если просто запихивать все относительное релевантное в контекст, будет ли % хороших ответов выше. Может быть клиенты готовы платить и по 0.2$ за запрос, если качество ответа хорошее
Принято. Добавлю Claude в исследование.
Меня уже попросили Мистраль добавить.
Да, так можно, но это не приближает к задаче локального RAG
Мне кажется своим комментарием Вы пошли в какую-то не ту степь.
В части суждения о том, что является моей целью и про иллюзию ответа. А лишь обозначил, что копание в Openai противоречит задачи эксперимента.
Цель исследования, а это первая часть его, вполне обозначена конкретно в начале. Локальная модель. Получилось или нет увидим позже, но тратить время на то, что точно не входит в рамки эксперимента- зачем?
Более того внедрение подобного робота в процесс требует в ближайшее годы участие человека. Неважно локальная модель или облачная.
кстати а можно же попробовать кэшировать ответы исходя из смысла запроса, т.е. натравить модель на поиск похожих вопросов
По первому вопросу (Иерархия):
В юридических документах пункты могут содержать очень мало информации и релевантны только в сочетании с родительским пунктом. Например:
Товар можно отправлять в термоконтейнерах, когда:
1. Есть указание в заказе наряде
1.2. Груз содержит реагенты с хранением до -4
Товар нельзя отправлять в термоконтейнерах, когда:
2.1. Есть указанием в заказе наряде
2.2. Есть груз содержит реагенты с хранением более 15 градусов
Соответственно пункты 1.1. и 2.1. индентичны и имеют смысл только в сочетании с родителем.
По второму вопросу (суммаризация чанка):
Рассматривал в теории, но пока решил отказаться. Так как вопросы по тексту задавали с очень конкретным контекстом: перечисли случаи когда можно делать хххх. Сколько дней даётся на подписание документа Y. А можно ли подписать акты на 12 день? А на 9 дней после приемки? ---- Кажется, что при суммаризации все эти детали потеряются.
Но соглашусь, что гипотезу можно проверить и делать вектора по саммари.
По окну контекста:
Так смысл состоит в том, чтобы выбрать эти релевантные пункты. В самом начале я вообще перевёл регламент на английский язык и смог запихнуть большую главу сразу в промпт. И это работало. Но хочется как-то более оптимально.
Хотя конечно были идеи, все перевести на английский и кидать сразу по 50 страниц.... Но эта идея разбивается о требование, чтобы все работало в закрытом контуре или хотя бы на отечественных решениях.
Для юридических документов лучше рассмотреть ручную нарезку на чанки (создать специализированный документ).
Если же нужно автоматически (или полуавтоматически), то использовать граф, в нем хорошо отображаются разные взаимосвязи типа "все вышесказанное относится еще и к п. 104" и отлично будет видны отношения один ко многим когда написанное в пункте относить к каждому пункту ниже.
Никакие нарезки чанков на такое не способны из-за особенностей самой структуры юридических документов.
Да, Макс. Согласен ручная разметка вообще топчик. И кстати это может быть намного дешевле в итоге, чем городить онтологический граф.
Для текущего кейса точно было б круто. А если еще структуру документа переделать специально под этот сервис, я думаю при прочих равных gpt4 90-95% показал бы.
И еще -- мне очень понравились результаты gpt3 -- очень мало неточных! Или да или нет. Конкретная модель )) -- все "нет" точно можно обработать ))
Ручная - не всегда вариант.
Иногда объемы и human error не позволяют использовать ручную.
Вообще, для меня нерезка - showstopper в проекте.
Банковское регулирование.
Законов в базе - 112тыс., активных законов 7.6тыс.
Впереди обновление законов 2024 и у меня легкая паника.
GPT4 нещадно филонит на текстах с 2к+ токенов, т.е. нарезка - must have.
Толкового решения у меня нет.
Внимательно читаю подход в статье.
Верно подмечено.
Для художественной и профессиональной литературы, где одна и та же мысль повторяется многократно в разных абзацах достаточно чанкирования по абзацам и даже работает по словам с 20% перекрытием.
Для регламентов важен каждый пункт.
А вы все законы через ada пускаете? Я бы предложил локальный токенайзер. Дешевле.
А вы все законы через ada пускаете?
Не совсем.
У меня 4 последовательных промпта обработки закона:
- разбивка на сегменты (и под-сегменты) до размера 1к токенов
- идентификация требований (с добавлением заголовка-контекста в каждый сегмент)
- пробразование требований
- генерация цифровых правил с опорой на схему банковских данных.
Использую GPT4 128k токенов на разбивку большого текста на сегменты (этап 1), далее GPT4 на остальные этапы.
На малых текстах, когда сегментация не требуется, проблем нет.
На больших GPT4 128k лажается с разбивкой на сегменты и теряет контекст т.к. режет текст не всегда на логические куски. Но часто подбирает аккуратно.
А можете пояснить термин "идентификация требований"? Возможно это профессиональный сленг в банковской сфере.
И термин цифровые правила тоже. Вы имеете ввиду онтологические графы знаний?
А можете пояснить термин "идентификация требований"?
Да, конечно.
Требования - regulatory requirements.
Раньше эти требования определяли вручную, но это большой объем, срезали углы.
Тут все как с кащеевой жизнью:
- у государства масса регуляторов (агенства, инвесторы)
- у регуляторов законы
- в законах требования
- требования основаны на банковских данных
А теперь задача: упростить проверку banking data на regulatory compliance.
Я в банковской regulatory compliance - трансформируем банковские законы в опросники, чтоб компании могли проверять свои банковские данные на соответствие законам.
Да, при таких объемах -- точно не вариант. Но тут вопрос в точности ответов и кол-ве допустимых ошибок. Если их нужно минимизировать -- придется тюнинговать.
Вообще, я уже склоняюсь к мысли, что или граф или просто изменение самой формы документов (предварительное преобразование). Типа сделать так чтобы подпункт нижнего уровня включал в себя и все верхние + перекрестные отсылки. Да, будет дублирование, но вектор будет более специализированный, что позволит дать точный ответ. Теоретически )))
Вот сейчас у меня нижний пункт включает верхний по возможности.
Но в целом ты прав. Тут надо еще покапать как мы, как люди ищем ответы. Есть мысли, что вектора тоже тупиковый путь.
Вообще, я уже склоняюсь к мысли, что или граф или просто изменение самой формы документов (предварительное преобразование).
Граф - модно, но намучался с графовой базой при создании ontology для банковской сферы. При разрастании типов (не кол-ва) граф напоминает неконтролируемый mess.
Предварительное преобразование - это и делаем, с использованием GPT4 128k.
В идеале: нужен семантический анализ документов с формированием иерархической структуры, чтоб разбивку на сегменты согласно структуре, не разрывая контекст.
Надеялся здесь стыбрить решения. :)
А какая бизнес разница?
Если пользователи будут получать ответы некорректные, то это в любом случае плохо. Мы не можем просить задавать только простые вопросы.
Еще проблема, что сложность субъективна. По одному из вопросов у нас возник спор.
Звучит пункт примерно так: Заказчик должен подписать акт приемки через 5 дней после уведомления о доставке в электронной системе, но не позднее 20 дня.
Вопрос: может ли заказчик подписать акт приемки на 5 день после уведомления?
Мнения юристов, меня и GPT разошлись
Я понимаю что вопрос мой не в области исследований, но все же стоимость в отношении к % правильных ответов,нужно добавить к сравнению! Моих коллег остановила именно эта характеристика. Сложность вопроса очень эвристический параметр, например в параметрах химических сред в формулировках нет ничего сложного,но несовпадение одного лишь параметра убивает все на корню.
Поясните мысль. Стоимость ответа?
Конечно в идеале хочется видеть общую комплексную стоимость решения пусть даже и ориентировочную. То на чем мы остановились было 0.18долл это промпт+ комплишн /1к токенов. Плюс сервисная поддержка. Плюс стоимость человеческого ресолвера неправильных ответов. Поясню общую мысль- была похожая попытка создания автоматизированного консультанта по олигонуклеотидной сборке. Итоговая стоимость решения на базе модели с учётом подключения человека на спорные ответы оказалась на порядок выше стоимости обычного человека. И даже апроксимация в будущее с учётом изменения стоимости обоих не дала выигрыша языковой модели.
А что значит иная природа ?
Там довольно простые правила генерации, если рассматривать праймерные последовательности , 1к токенов это для сравнения. Ембединги через аду, дата-сет не большой, не буду врать про объем.
В конкретно этой задаче была интерпретация последовательности от заказчика на соответствие.
Если вы занимались синтезом - у каждой группы есть свой протокол, последовательность предоставляемая заказчиком не должна содержать ситуаций которые могут привести к появлению хайр-пинов, селф-димеров , экзон-экзон джанкшн должен быть справедливо описан для 3 прайм или 5 прайм и тд и тп.
Добрый день, а какую версию ruBERT large вы взяли? sbert-nlu-ru-mt надеюсь?
В моем случае лучше всего подошёл https://huggingface.co/ai-forever/ruBert-large
Из синтетических тестов. Я перебрал почти все.
Эта модель не является хорошим эмбеддером для задачи RAG. Уровня ada2 только sbert-nlu-ru-mt в том же репо. Это можно посмотреть в бенчмарке Encodechka. От качества ретривера много зависит в RAG.
https://huggingface.co/ai-forever/sbert_large_mt_nlu_ru вот эта модель и пуллинг из её карточки, можно с нормализацией l2 результат будет ещё лучше.
Большой тест GPT4, GPT3.5, YandexGPT, GigaChat, Saiga в RAG-задаче. Часть 1