Передовые методы обеспечения качества данных, проектирования и оценки методов поиска в производственных системах RAG.
Делиться
За последние пару лет технология RAG превратилась в своего рода сигнал доверия в области ИИ. Если компания хочет выглядеть серьезной в глазах инвесторов, клиентов или даже собственного руководства, от нее теперь ожидается наличие готовой истории о разработке технологии генеративного поиска с дополненной реальностью (RAG). Магистерские программы изменили ситуацию практически в одночасье и внедрили генеративный ИИ почти во все деловые дискуссии.
Но на практике: создание плохой системы RAG хуже, чем ее полное отсутствие.
Я наблюдал, как эта схема повторяется снова и снова. Продукт быстро выпускается, демоверсия выглядит хорошо, руководство удовлетворено. Затем реальные пользователи начинают задавать реальные вопросы. Ответы расплывчаты. Иногда неверны. Иногда уверены, а иногда совершенно бессмысленны. Обычно на этом все и заканчивается. Доверие быстро исчезает, и как только пользователи решают, что системе нельзя доверять, они перестают проверять, улучшилась ли она, и не дают ей второго шанса. Они просто перестают ею пользоваться.
В данном случае настоящая ошибка не техническая, а человеческая. Люди терпят медленные инструменты и неудобные интерфейсы. Чего они не потерпят, так это введения в заблуждение. Когда система с уверенностью выдает неверный ответ, это кажется обманом. Восстановиться после этого, даже после месяцев работы, крайне сложно.
Всего нескольких неверных ответов достаточно, чтобы пользователи вернулись к ручному поиску. К тому времени, когда система наконец станет по-настоящему надежной, ущерб уже будет нанесен, и никто больше не захочет ею пользоваться.
В этой статье я поделюсь шестью уроками, которые, как мне кажется, я должен был знать до начала реализации проектов RAG для клиентов.
1. Начните с реальной бизнес-проблемы.
Важные решения в рамках принципа RAG принимаются задолго до написания кода.
- Почему вы взялись за этот проект? Необходимо определить проблему, которую нужно решить. Делать это «потому что все так делают» — это не стратегия.
- Затем встает вопрос окупаемости инвестиций, тот, которого все избегают. Сколько времени это действительно сэкономит в конкретных рабочих процессах, а не просто на основе абстрактных показателей, представленных на слайдах?
- И наконец, сценарий использования. Именно здесь большинство проектов RAG незаметно терпят неудачу. «Ответы на внутренние вопросы» — это не сценарий использования. Помогает ли это отделу кадров отвечать на вопросы о политике компании без бесконечной переписки? Предоставляет ли это разработчикам мгновенный и точный доступ к внутренней документации во время написания кода? Является ли это узкоспециализированным помощником по адаптации новых сотрудников в течение первых 30 дней? Надежная система RAG хорошо справляется с одной задачей.
RAG может быть очень эффективным. Он может экономить время, уменьшать трение и действительно улучшать командную работу. Но только если к нему относиться как к реальной инфраструктуре, а не как к эксперименту, основанному на тренде.
Правило простое: не гонитесь за трендами. Реализуйте ценность.
Если эту ценность нельзя четко измерить в сэкономленном времени, повышении эффективности или снижении затрат, то, вероятно, проекту вообще не место.
2. Подготовка данных займет больше времени, чем вы ожидаете.
Многие команды спешат с разработкой RAG, и, честно говоря, простой MVP можно создать очень быстро, если не сосредотачиваться на производительности. Но RAG — это не быстрый прототип; это огромный инфраструктурный проект. Как только вы начнете нагружать свою систему реальными, постоянно меняющимися данными в производственной среде, начнут проявляться слабые места вашего конвейера.
Учитывая недавнюю популярность моделей с длинным контекстом (LLM) с большими окнами контекста, иногда измеряемыми миллионами, некоторые заявляют, что модели с длинным контекстом делают извлечение необязательным, и команды пытаются просто обойти этап извлечения. Но, судя по моему опыту многократной реализации такой архитектуры, большие окна контекста в LLM очень полезны, но они не заменяют хорошее решение RAG. Если сравнить сложность, задержку и стоимость передачи огромного окна контекста с извлечением только наиболее релевантных фрагментов, хорошо спроектированная система RAG по-прежнему необходима.
Но что определяет «хорошую» систему поиска? Конечно, важны ваши данные и их качество. Классический принцип «мусор на входе — мусор на выходе» здесь применим так же, как и в традиционном машинном обучении. Если ваши исходные данные не подготовлены должным образом, вся ваша система будет испытывать трудности. Неважно, какую модель машинного обучения вы используете; качество извлечения данных — это самый важный компонент.
Слишком часто команды напрямую загружают необработанные данные в свою векторную базу данных (VectorDB). Она быстро превращается в песочницу, где единственным механизмом извлечения данных является приложение, основанное на косинусном сходстве. Хотя оно может пройти ваши быстрые внутренние тесты, оно почти наверняка потерпит неудачу в реальных условиях.
В зрелых системах RAG подготовка данных осуществляется по собственному конвейеру с этапами тестирования и версионирования. Это означает очистку и предварительную обработку входного корпуса. Никакое хитроумное сегментирование или сложная архитектура не смогут исправить принципиально некачественные данные.
3. Эффективное разделение идей на смысловые блоки заключается в сохранении целостности идей.
Когда мы говорим о подготовке данных, мы имеем в виду не просто чистые данные, а осмысленный контекст. Это подводит нас к сегментации данных.
Разбиение на фрагменты (чанкинг) подразумевает разбиение исходного документа, например, PDF-файла или внутреннего документа, на более мелкие части перед кодированием его в векторный формат и сохранением в базе данных.
Зачем нужна сегментация (chunking)? LLM-ы имеют ограниченное количество токенов, и даже «LLM-ы с длинным контекстом» становятся затратными и страдают от отвлекающих факторов в виде избытка информации. Суть сегментации заключается в том, чтобы выделить единственный наиболее релевантный фрагмент информации, который ответит на вопрос пользователя, и передать в LLM только этот фрагмент.
Большинство команд разработчиков разделяют документы, используя простые методы: ограничение количества токенов, подсчет символов или создание приблизительных абзацев. Эти методы очень быстрые, но обычно именно на этом этапе качество поиска начинает ухудшаться.
Когда мы разбиваем текст на фрагменты без продуманных правил, он превращается в отдельные части, а не в целые концепции. В результате получаются фрагменты, которые постепенно распадаются и становятся ненадежными. Копирование наивной стратегии разбивки на фрагменты из опубликованной архитектуры другой компании без понимания собственной структуры данных опасно.
В лучших системах RAG, которые я видел, используется семантическая сегментация.
На практике семантическая сегментация означает разбиение текста на осмысленные фрагменты, а не просто на фрагменты случайного размера. Идея состоит в том, чтобы каждый фрагмент был сосредоточен на одной законченной мысли. Цель состоит в том, чтобы каждый фрагмент представлял собой одну законченную идею.
- Как это реализовать: Вы можете реализовать это, используя такие методы, как: Рекурсивное разделение: Разбиение текста на основе структурных разделителей (например, разделы, заголовки, затем абзацы, затем предложения).
- Трансформаторы предложений: Этот метод использует облегченную и компактную модель для определения всех важных переходов на основе семантических правил с целью сегментации текста в этих точках.
Для внедрения более надежных методов можно обратиться к библиотекам с открытым исходным кодом, таким как различные модули сегментации текста LangChain (особенно их продвинутые рекурсивные модули), а также к исследовательским статьям по сегментации тем.
4. Ваши данные устареют.
Список проблем на этом не заканчивается после запуска. Что происходит, когда ваши исходные данные изменяются? Устаревшие эмбеддинги постепенно выводят системы RAG из строя с течением времени.
Вот что происходит, когда базовые знания в вашем корпусе документов изменяются (новые правила, обновленные факты, реструктурированная документация), но векторы в вашей базе данных никогда не обновляются.
Если ваши векторные представления слабые, ваша модель будет, по сути, основываться на исторических данных, а не на текущих фактах.
Почему обновление VectorDB представляет собой технически сложную задачу? Векторные базы данных сильно отличаются от традиционных баз данных SQL. При каждом обновлении одного документа вы не просто меняете пару полей, а, возможно, вам придётся заново разбить документ на части, сгенерировать новые большие векторы, а затем полностью заменить или удалить старые. Это ресурсоёмкая операция, очень трудоёмкая и может легко привести к простоям или несоответствиям, если к ней не отнестись должным образом. Команды часто пропускают этот этап, потому что инженерные усилия по его выполнению нетривиальны.
Когда необходимо повторно встраивать корпус данных? Единого правила нет; на этапе проверки концепции единственным ориентиром является тестирование. Не ждите определенного количества изменений в данных; наилучший подход — автоматическая повторная встраивание системы, например, после выпуска основной версии внутренних правил (если вы разрабатываете систему управления персоналом). Повторная встраивание также необходима, если сама предметная область существенно меняется (например, в случае серьезных изменений в законодательстве).
Внедрение версионирования, или отслеживание того, какие документы связаны с каким запуском для генерации вектора, является хорошей практикой. В этой области необходимы инновационные идеи; миграция в VectorDB часто является упущенным шагом для многих команд.
5. Без оценки недостатки выявляются только тогда, когда пользователи жалуются.
Оценка RAG означает измерение того, насколько хорошо ваше приложение RAG действительно работает. Идея состоит в том, чтобы проверить, дает ли ваш информационный помощник на базе RAG точные, полезные и обоснованные ответы. Или, проще говоря: действительно ли он работает в вашем реальном сценарии использования?
Оценка системы RAG отличается от оценки классической системы LLM. Ваша система должна работать с реальными запросами, которые вы не можете полностью предвидеть. Вам нужно понять, извлекает ли система правильную информацию и дает ли корректные ответы.
Система RAG состоит из множества компонентов, начиная от способа разбивки и хранения документов, заканчивая встраиванием данных, поиском, форматом подсказок и версией LLM.
Поэтому оценка RAG также должна быть многоуровневой. Наилучшие оценки включают метрики для каждой части системы в отдельности, а также бизнес-метрики для оценки того, как вся система работает от начала до конца.
Хотя эта оценка обычно начинается на этапе разработки, она потребуется на каждом этапе жизненного цикла продукта, созданного с использованием ИИ.
Тщательная оценка превращает RAG из экспериментального проекта в измеримый технический проект.
6. Модные архитектурные решения редко подходят для решения вашей проблемы.
Архитектурные решения часто принимаются на основе информации из блогов или конференций, без учета того, соответствуют ли они внутренним требованиям.
Для тех, кто не знаком с RAG, следует отметить, что существует множество архитектур RAG, начиная от простой монолитной системы RAG и заканчивая сложными агентными рабочими процессами.
Для эффективной работы вашей системы вам не нужна сложная агентная RAG-архитектура. На самом деле, большинство бизнес-задач лучше всего решаются с помощью базовой RAG-архитектуры или двухэтапной RAG-архитектуры. Я знаю, что слова «агент» и «агентный» сейчас популярны, но, пожалуйста, отдавайте приоритет реализованной ценности, а не реализованным тенденциям.
- Монолитный (базовый) RAG: начните здесь. Если запросы ваших пользователей просты и повторяются («Какова политика отпусков?»), вам достаточно простого конвейера RAG, который извлекает и генерирует данные.
- Двухэтапное переписывание запроса: используйте этот метод, когда ввод пользователя может быть косвенным или неоднозначным. Первый этап LLM переписывает неоднозначный ввод пользователя в более чистый и качественный поисковый запрос для VectorDB.
- Агентский подход RAG: Рассматривайте его только в тех случаях, когда сценарий использования требует сложных рассуждений, выполнения рабочих процессов или применения инструментов (например, «Найти политику, кратко изложить ее, а затем составить электронное письмо в отдел кадров с просьбой о разъяснении»).
Системы RAG — это захватывающая архитектура, которая в последнее время приобрела огромную популярность. Хотя некоторые утверждают, что «системы RAG мертвы», я считаю, что этот скептицизм — естественная часть эпохи, когда технологии развиваются невероятно быстро.
Если ваша задача ясна и вы хотите решить конкретную проблему, связанную с большими объемами документных данных, архитектура RAG остается весьма эффективной. Ключевым моментом является простота и интеграция с пользователем с самого начала.
Не забывайте, что создание системы RAG — это сложная задача, требующая сочетания навыков машинного обучения, MLOps, развертывания и управления инфраструктурой. Вы обязательно должны начать этот процесс с участием всех — от разработчиков до конечных пользователей — с самого первого дня.
🤝 Оставайтесь на связи
Если вам понравилась эта статья, подписывайтесь на меня в LinkedIn, чтобы получать больше честных советов по искусственному интеллекту, науке о данных и карьерным возможностям.
👉 LinkedIn: Sabrine Bendimerad
👉 Medium: https://medium.com/@sabrine.bendimerad1
👉 Instagram : https://tinyurl.com/datailearn
Источник: towardsdatascience.com
