Построение базы знаний компании и поиска документов на LLM и RAG

Наиболее распространенный случай использования ИИ в бизнесе в данный момент— это поиск информации и документов в имеющихся у компании данных для принятия решений или создание красиво оформленных, но совершенно бесполезных отчетов, чтобы топ-менеджмент мог оправдать свои огромные бонусы. Все это, конечно, очень важные и легитимные кейсы.

Проблема тут если вы один из этих топ-менеджеров или просто не являетесь экспертом в области. Ваш отдел аналитики данных и ИИ, если он у вас есть, вероятно, говорит на своем инопланетном наречии и не может дать связного ответа, почему у нас столько данных, но мы все еще не можем ответить на довольно тривиальные вопросы (что, конечно, задерживает получение бонусов, а новый БМВ сам себя не купит).

Я разделяю вашу боль, давайте разберемся, о чем они говорят.

До бума генеративного ИИ

Ранее основной способ поиска по документам и корпоративным базам знаний заключался в использовании полнотекстовых поисковых систем, таких как Apache Lucene, Elasticsearch и Solr, или аналогичных функций в базах данных, таких как Microsoft SQL Full Text Search, примитивный поиск по ключевым словам. Плюс хардкорный самописный ML/AI, который обходился примерно как крыло самолета.

Эти подходы работают, но их возможности ограничены, поэтому и системы, использовавшие эти подходы, также были весьма ограничены. Они не могут справляться со сложными или неточными запросами, где требуется понимать смысл вопроса и контекст разговора, а не отдельные слова или поиск требует понимания контекста, чтобы быть эффективным. Пример их нашей практики - поиск по патентным базам, который мы помогали реализовать для компании Инветорус. Это сложная задача не по зубам старым системам, так как в патентах одни и те-же вещи часто описываются и называются по разному.

Теперь это стало возможным благодаря большим языковым моделям (LLM)

Главный виновник прогресса — это большие языковые модели, или LLM. Можно спорить, действительно ли они обладают интеллектом, но одно ясно: они очень хорошо понимают особенности человеческого языка. Эта технология настолько впечатляет что стала практически синонимом Искуственного Интеллекта.

Эпоха LLM и ретриверов

LLM помогают двумя способами:

1. Они способны понимать вопросы пользователей и преобразовывать их в формат, который может обработать компьютер. Это может звучать не очень впечатляюще, но на самом деле это огромный шаг вперед. Они буквально могут понять любую чепуху, которую вводят ваши пользователи, и превратить ее во что-то осмысленное.

2. Они способны дать осмысленный ответ на основе доступных данных и контекста разговора, в визуальном или текстовом формате. Насколько ответ будет осмысленным зависит от разных факторов.

Но есть один этап, который LLM не выполняют — это поиск данных для ответа на вопрос. Технически LLM может знать достаточно (то есть иметь достаточно данных), чтобы ответить на вопрос, если она была обучена на данных в этой области или вопрос не требует таких знаний. Однако, как правило, для компании, работающей в специфической области, это не так.

LLM, скорее всего, не знают ваших финансов или имени и телефона вашего руководителя отдела маркетинга, чтобы вы могли позвонить ему поздно ночью с крайне важными вопросами, как например, когда он собирается сменить шрифт в последнем отчете. Так бонусы не приблизить.

Но не нужно паники, существует еще один уровень между ними, называемый Retriever. Это компонент, который ищет релевантную информацию в корпоративных базах данных, документах, CRM и так далее, чтобы предоставить ее LLM. Очень популярный термин RAG означает Retrieval Augmented Generation, что буквально описывает такую систему — она использует LLM и ретривер для генерации ответов.

Вполне вероятно, что вам понадобятся несколько ретриверов, которые будут искать данные в разных изолированных системах вашей компании. В конце процесса поиска необходимо объединить результаты от всех ретриверов. Это называется Retriever Assembling (или ансамбль ретриверов).

Решили ли RAG-системы проблему поиска по документам?

Ну, не совсем.

У RAG есть свои ограничения, которые в основном связаны с тем, как работают LLM. Конкретно, LLM способны обрабатывать лишь ограниченное количество текста за один запрос, поэтому мы не можем дать ей всю доступную информацию, чтобы система нашла ответ. В вашей компании, вероятно, есть сотни, если не тысячи документов, записей в базах данных и другой информации. Очевидно, что невозможно каким-то образом передать всё это в LLM для обработки.

Если у нас много документов, их нужно отфильтровать, а если сами документы объемные — нужно разбить их на небольшие фрагменты (chunks). Кроме того, каждый токен, который мы отправляем LLM, стоит денег, поэтому мы не хотим пересылать много ненужной и нерелевантной информации и за это платить. Как вы знаете, большинство документов содержат массу воды. Поэтому нам действительно нужно отправлять только ту информацию, которая, по нашему мнению, может быть полезной для ответа.

Это приводит к своим собственным проблемам: если мы разбиваем информацию на фрагменты и храним ее в разных частях, как мы можем гарантировать, что все необходимые фрагменты будут найдены при поиске? Это может быть очень сложно, особенно если речь идет о сложных документах с множеством таблиц и других данных, где объяснение таблицы может находиться в другой части документа или даже в другом документе. Более того, в вашей системе могут быть разные версии одного и того же документа с противоречивой информацией… 

Один из способов решения этой проблемы — Re-Ranking

Почему нужен Re-Ranking?

В стандартной RAG-системе документы находятся с помощью семантического поиска по хранилищу данных, который ищет документы, схожие с пользовательским запросом. Например, если вы спросите: «Почему моя кошка планирует захватить мировое господство?», поиск использует векторные эмбеддинги, чтобы найти документы, связанные с проказами кошек. Эти документы, вместе с вопросом, отправляются в LLM для создания финального (и, надеемся, не сильно пугающего) ответа.

К сожалению, алгоритмы семантического поиска не всегда могут найти идеальные совпадения. Это происходит по разным причинам, например, потому что документы часто содержат информацию не по одной, а сразу по нескольким темам, могут содержать противоречивую или устаревшую информацию, а также потому, что документы хранятся в векторных базах данных не целиком, а фрагментами.

В результате семантический поиск может вернуть такие документы:

• Кошки: история порабощения человечества

• Съест ли меня моя кошка, если я перестану её кормить?

• Мюзикл «Кошки» стал лидером кассовых сборов в этом году

• Как завоевать расположение кошек и оказывать на них дурное влияние

Как вы видите, третий пункт здесь не является релевантным документом.

Еще одна проблема (на примере аналогии)

Представьте, что вы знаете очень эрудированного профессора. Он прочитал множество книг и технически знает массу всего. Вы спрашиваете его о пеликанах на Галапагосских островах — он знает всё об этом. Вы спрашиваете, лучше ли Трамп или Байден, — и об этом он знает много. Вы начинаете думать: «Этот человек чертовски умен! Я могу спросить его обо всем!» Так как у вас есть проблема на работе, вы решаете обратиться к нему за помощью.

Вы задаете ему такой вопрос: «Согласно Директиве О Платежеспособности 23.2, если страховая компания застрахует колонию супер-интеллектуальных белок, которые управляют собственным хедж-фондом, как будут скорректированы их капитальные требования с учетом непредсказуемости рынка орехов?»

И что? Конечно, он знает и об этом тоже! И он дает вам ответ. Проблема в том, что этот ответ - полная чепуха. Он был прав по предыдущим темам, но как только дело доходит до специфических отраслевых вопросов, он выдает правдоподобные, но неточные ответы. Причина в том, что LLM обучались на большом количестве данных из интернета, но это очень общие данные. Они не отраслевые, поэтому модели дают обобщенные ответы.

Как помогает Re-ranking?

Re-ranking помогает решить эту проблему с помощью моделей переупорядочивания, которые обучены на текстах из конкретной предметной области. Это позволяет предоставить LLM наиболее релевантный контекст.

Возвращаясь к предыдущему примеру: если мы попросим систему с переупорядочиванием отранжировать результаты семантического поиска по степени релевантности, она выдаст такой список:

• Кошки: история порабощения человечества

• Съест ли меня моя кошка, если я перестану её кормить?

• Как завоевать расположение кошек и оказывать на них дурное влияние

• ...

• Мюзикл «Кошки» стал лидером кассовых сборов в этом году

Теперь вы можете взять первые три самых релевантных документа и отправить их нашему «очень умному профессору» (LLM), чтобы он дал ответ.

Существует множество способов выполнить переупорядочивание, некоторые из них описаны здесь (ссылка). Обычно в производственных системах используется комбинация нескольких методов, которые лучше всего подходят для конкретной области применения.

Чтобы выполнить ре-ранкинг данные нужно откуда то достать. Есть несколько вариантов хранения, подходящих для быстрого поиска.

Векторное хранилище

Для работы RAG ретривер может искать данные где угодно: например, напрямую в корпоративной SQL-базе данных или вашей электронной почте. Он также может использовать системы полнотекстового поиска, которые уже есть в компании. Но это непрактично, так как такой поиск будет медленным и неточным. Предпочтительный (на сегодняшний день) способ хранения данных для RAG-поиска — это векторная база данных или векторное хранилище.

В векторной базе данных (или, точнее, в векторном пространстве) концепции, которые семантически похожи, располагаются близко друг к другу, независимо от их текстового представления. Например, слова «собака» и «бульдог» будут расположены рядом, а слова «замок» (как дверной замок) и «замок» (как крепость) будут находиться далеко друг от друга.

Кроме того, векторная база данных хранит метаданные, то есть данные о данных, чтобы фиксировать информацию, такую как права доступа (кто может получить доступ к данным), источник данных, способ их хранения, тип данных, категория и так далее.

Таким образом, векторные базы данных отлично подходят для семантического поиска данных.

Существует множество решений, от open-source систем, таких как Quadrant, до корпоративных, таких как Pinecone. Большинство классических и NoSQL-баз данных теперь также имеют опции для работы с векторами.

Популярные векторные базы данных (на текущий момент):

• QDrant — открытая база данных, я предпочитаю её для большинства задач.

• Pinecone — облачная база данных (то есть вам придется заплатить немало), поддерживающая множество корпоративных функций.

• Elasticsearch - они тоже сделали векторный поиск и если вы уже используете Elastic и хотите сделать гибрид, это очень даже опция

• Chroma — еще одна открытая база данных с лицензией Apache-2.0.

• Weaviate — открытая база данных под лицензией BSD-3-Clause.

• Milvus — открытая база данных под лицензией Apache-2.0.

• Marqo — открытая платформа и полностью управляемый облачный сервис.

• FAISS — это отдельный инструмент, не база данных, а фреймворк от Meta.

• Pgvector для PostgreSQL — расширение для работы с векторами в PostgreSQL.

• Atlas для Mongo — опция работы с векторами для MongoDB.

Чтобы сделать такую систему лучше воспользоваться каким то фреймворком, а не писать с нуля.

LLamaindex (Ламаиндекс)

Наиболее популярный фреймворк для создания подобных RAG-систем — это LLamaindex. Это библиотека на Python, которая предоставляет следующие инструменты:

1. Обработка данных (Data ingestion):
   Ваши данные, скорее всего, разбросаны по разным местам и форматам: PDF-документы, SQL-базы данных, корпоративная вики, CRM и т.д. LLM не может работать с этими данными напрямую, поэтому их нужно извлечь. LLamaindex предоставляет коннекторы для работы с этими источниками.

2. Индексация данных (Data Indexes):
   Когда данные извлечены, они, скорее всего, представляют собой хаос, с которым не справится даже суперкомпьютер. Поэтому их нужно структурировать в формат, понятный для LLM.

3. Поисковые движки (Query Engines):
   После того как данные подготовлены, требуется инструмент для выполнения запросов. LLamaindex предоставляет инструменты для запросов данных различными методами и их интеграции в приложения.

4. Агенты данных (Data Agents):
   Это "работники" на основе LLM, которые могут выполнять сложные задачи с данными, например, вызывать API, дополнять данные или использовать вспомогательные функции. Они помогают строить рабочие процессы.

Альтернативы LLamaindex. Если вы работаете с экосистемой Microsoft, можно использовать Semantic Kernel. Однако, на мой взгляд, он всё ещё довольно сырой.

Однако есть одна альтернатива, против которой я вас хочу отговорить:

LangChain

LangChain — это еще один фреймворк, который используется для создания RAG-систем. Хотя он более универсален и не был специально создан для этого, его часто применяют для разработки различных приложений на основе LLM, таких как чат-боты.

LangChain ускоряет процесс разработки, предоставляя множество готовых компонентов, которые можно связывать в цепочки для создания рабочих потоков.

Вы можете использовать LangChain и LLamaindex вместе Однако есть один момент, который стоит упомянуть: разработчики LangChain так часто и так сильно меняют что-то в своем фреймворке, что он нередко ломается. Это делает его довольно нестабильным и раздражающим в использовании. Иногда я начинаю сомневаться, подходит ли он вообще для продакшн-систем…

Контроль доступа

Еще одна проблема — контроль доступа. В ваших текущих системах, скорее всего, уже реализован какой-то уровень контроля доступа. На уровне LLM контроль доступа отсутствует, и попытки реализовать его на этом уровне бесполезны. Какие бы инструкции вы ни давали LLM, их можно обойти, и практически любую модель можно "уговорить" сделать что угодно, если приложить достаточно усилий.

Существует забавная игра, созданная одной из ведущих компаний в области безопасности LLM, Lakera, которая демонстрирует эту проблему.

Я не говорю, что вам не нужны механизмы защиты для ввода и вывода данных LLM. Я лишь указываю, что на них нельзя полагаться для контроля доступа или работы с секретными данными.

Важное следствие. Вы не можете обучать LLM на данных такого рода, потому что со временем модель с удовольствием расскажет их тому, кому знать их не положено.

Таким образом, единственный правильный способ работы — это предоставлять LLM необходимые данные во время процесса извлечения данных (retrieval), на уровне запроса пользователя, и только те данные, к которым этот пользователь имеет доступ. Этот доступ следует проверять, например, на уровне хранилища данных.

Разрешения и категории данных — это форма метаданных, и для корректной работы всей системы такие метаданные должны сохраняться на этапе обработки данных (ingestion), например, в векторной базе данных или другом месте. Соответственно, при поиске в векторной базе данных необходимо проверять, соответствуют ли найденные документы роли или другим атрибутам доступа пользователя.

Некоторые (особенно коммерческие корпоративные) векторные базы данных уже имеют эту функциональность по умолчанию. Пример хорошей реализации можно найти здесь.

Графы знаний

Это не обязательная часть RAG-системы, но, скорее всего, она понадобится, если у вас много данных или они хранятся определенным образом, важным для их понимания.

Например, подумайте о папке с фотографиями на вашем компьютере. Если вы случайным образом переименуете все подпапки, насколько легко будет что-то найти, даже если сами данные (фотографии) не изменились?

Мы, люди, в этом плане похожи. Без структуры информация мало что значит, поэтому у нас в головах есть нечто вроде графов знаний. Мы понимаем значение данных благодаря соглашениям о том, как эти данные хранятся (структуре или метаданным), чтобы эффективно ими пользоваться.

Для LLM эта проблема решается с помощью графов знаний с метаданными (также известных как карты знаний). Это означает, что LLM имеет не только сырые данные, но и информацию о структуре хранения и связях между различными сущностями данных.

Этот подход известен как Graph Retrieval-Augmented Generation (GraphRAG).

Графы отлично подходят для представления и хранения разнородной и взаимосвязанной информации в структурированной форме, легко фиксируя сложные связи и атрибуты между различными типами данных, с чем векторные базы данных испытывают трудности.

Обычный RAG выглядит так:

GraphRAG выглядит так:

Таким образом, на самом деле это ансамбль векторной базы данных и графа знаний. Как я упоминал в разделе об ансамблях в предыдущей статье, такие подходы обычно повышают точность и часто включают поиск через обычную базу данных или по ключевым словам (например, Elasticsearch).

Уже существует множество решений для хранения графов (хотя компании часто создают свои собственные версии):

• Nebula — открытое решение с лицензией Apache 2.0, отличается хорошей производительностью и масштабируемой архитектурой. Мой личный выбор.

• Neo4j — популярное решение, поддерживает язык запросов Cypher, что делает его доступным для различных приложений. Имеет Community Edition с лицензией GPL v3, но для серьёзных задач понадобится Enterprise Edition.

• RedisGraph — прекратил поддержку в 2023 году.

• OrientDB — мульти-модельная база данных, которая сочетает графовые и документные модели. Открытая (Apache 2.0) и существует уже довольно давно. Может быть хорошим вариантом, если вам нужен гибридный режим документ-граф. В противном случае лучше выбрать Nebula.

• Memgraph — графовая база данных в оперативной памяти, разработанная для анализа графов в реальном времени и использования в сценариях, требующих низкой задержки. Если вам требуется обработка в реальном времени, вероятно, придётся использовать хранение в памяти.

• ArangoDB — мульти-модельная база данных, поддерживающая графы, документы и модели ключ/значение в рамках одного движка. Не специализируется исключительно на графах, поэтому, если нужны только графы, снова лучше выбрать Nebula.

• JanusGraph — открытое решение с лицензией Apache 2.0, поддерживает различные бекенды для хранения, включая Apache Cassandra, HBase и BerkeleyDB. Использует язык обхода графов Gremlin из фреймворка Apache TinkerPop, поэтому, если вы уже работаете с этим фреймворком, это может быть хорошим выбором.

Обработка данных (Ingestion)

Это, вероятно, самая сложная проблема. Независимо от того, как вы построите свою RAG-систему, если она будет хранить мусор, то и результат будет соответствующий: мусор на входе — мусор на выходе.

Очень сложно получать только чистые данные, а если источник данных представляет собой неструктурированный хаос, вроде PDF-документов, задача становится ещё сложнее. Честно говоря, пора принять закон на планетарном уровне, чтобы запретить PDF формат.

Фреймворки вроде LLamaParse и подобные помогают справляться с этим до определённой степени. Но проблема не только в формате. Есть также вопрос версий документов, когда у вас могут быть несколько версий похожих документов или информация в одном документе противоречит информации в другом.

Что делать в таких случаях?

Подходы варьируются, и не всегда есть один правильный ответ. Это по своей природе сложная проблема, которую полностью решить не удастся, пока у нас не появится сверхинтеллектуальный ИИ.

Есть методы, например, алгоритм Maximum Marginal Relevance Search (MMR), который учитывает релевантность и новизну информации для фильтрации и переупорядочивания документов.

Что важно учитывать:

1. Система должна осознавать наличие противоречивой информации и передавать это на рассмотрение пользователя, если она не уверена.

2. Для этого необходимо хранить метаданные версий документов и определять, как версии и приоритеты будут разрешаться в случае конфликтов. Здесь могут помочь алгоритмы вроде MMR и другие методы переупорядочивания и оценки релевантности.

3. Универсального решения нет, так как многое зависит от того, как вы храните данные в своих системах. Однако наличие структуры и политики разрешения конфликтов информации в компании значительно упрощает задачу.

Если такие структуры и политики уже существуют, это предоставляет шанс формализовать их, объяснить агенту LLM или использовать схожий подход.

В рамках ваших данных у вас могут быть изображения, или вы можете захотеть, чтобы пользователи взаимодействовали с системой с помощью изображений. Теперь это возможно благодаря Vision Transformers. Однако это довольно большая отдельная тема.

Галлюцинации

Всем известно, что LLM (большие языковые модели) склонны к галлюцинациям. На мой взгляд, это делает их непригодными для использования в критически важных системах, таких как принятие решений в здравоохранении или финансовое консультирование. В этих областях они могут выступать в роли помощников (co-pilots) для профессионалов, и даже в таком случае — с большой осторожностью.

Почему модели галлюцинируют?
Очевидно, модели не получают никакой выгоды от своих галлюцинаций и не имеют корыстных намерений. Основные причины галлюцинаций включают:

1. Данные для обучения

Большие языковые модели обучаются на огромных и разнообразных наборах данных из множества источников. Это обучение происходит без надзора, что затрудняет проверку данных на справедливость и точность. Модели не могут самостоятельно отличить правду от вымысла. Они основываются на шаблонах, найденных в данных, которые могут включать противоречивую или субъективную информацию. Это приводит к ответам, которые выглядят логично, но фактически неверны.

2. Отсутствие точности в специфических областях

LLM, такие как GPT, разработаны для выполнения общих задач. При применении в конкретных областях, таких как медицина, юриспруденция или финансы, они могут давать неверные результаты. Галлюцинации возникают из-за попытки модели создать связный ответ без достаточных знаний в данной области.

3. Неправильное составление запросов (Bad Prompting)

Пользователи взаимодействуют с моделью через запросы (prompts). Написание чётких и точных запросов крайне важно, как и в программировании. Если запрос недостаточно детализирован или контекстуален, модель может сгенерировать нерелевантный или неправильный ответ. Чтобы получить правильные результаты, важно задавать правильные вопросы.

4. Умышленная предвзятость

Или, проще говоря, модель обучена «лгать». Это особенно верно для общедоступных моделей, таких как ChatGPT или Gemini. Они обучены с учётом множества сомнительных политик, чтобы соответствовать законам и регуляциям, что приводит к нелепым ответам на чувствительные для общества темы.

5. Потеря контекста

У модели есть ограниченное окно контекста или коротковременная память. Если разговор слишком длинный или объем данных слишком большой, модель начинает терять детали контекста и генерировать бессмысленные результаты. Я считаю, что эта проблема будет решена в ближайшем будущем с увеличением окна контекста, что в свою очередь связано с доступной вычислительной мощностью. Однако на данный момент это остаётся проблемой, и важно правильно проектировать системы RAG, чтобы оптимизировать использование контекста.

Можно ли устранить галлюцинации?
Краткий ответ: нет. Однако существуют способы уменьшить вероятность их возникновения:

• Дополнительное обучение модели на релевантных данных из конкретной области.

• Использование RAG (Retrieval-Augmented Generation) для предоставления валидного контекста, избегая перегрузки контекста.

• Инженерия запросов (Prompt Engineering) для создания запросов, которые явно инструктируют модель не добавлять информацию, в которой она не уверена.

• Тонкая настройка в процессе запроса (In-prompt tuning) с использованием few-shot примеров.

• Использование стратегий самопроверки LLM, таких как "Дерево мысли" (Tree of Thought), для проверки логики и результатов модели.

• Просьба к модели вернуть распределение токенов с их вероятностями, чтобы оценить, насколько уверена модель в своём ответе. Если вероятности низкие (что считается низким, зависит от задачи), модель, скорее всего, начала фантазировать.

• Валидация результатов с помощью других моделей или «оракулов».

• Постобработка и фильтрация, чтобы цензурировать ответы, которые не соответствуют политике компании или могут быть вредными.

Тем не менее, как я уже упомянул, ни один из этих методов не может гарантировать полное отсутствие галлюцинаций.

Вычисления

То, о чём говорилось ранее, в основном относится к работе с текстовыми данными. Но что, если у вас есть множество чисел и таблиц, и вам нужно выполнять вычисления в ответах? Здесь всё становится сложнее, так как LLM плохо справляются с подсчётами. Даже лучшие модели ужасно решают простую математику, не говоря уже о сложных задачах.

Наиболее распространённый способ выполнения вычислений — это предоставление LLM инструмента для их выполнения, например, использование Elasticsearch или SQL-базы данных.

Что вы делаете? Вы используете LLM для создания запроса, например, к Elasticsearch, чтобы выполнить вычисления, а затем используете результаты для формирования финального ответа.

Пример:

{

  "query": {

    "bool": {

      "must": [

        {"term": {"region": "Moskow"}},

        {"range": {"date": {"gte": "2024-01-01", "lte": "2024-03-31"}}}

      ]

    }

  },

  "aggs": {

    "total_revenue": {

      "sum": {

        "field": "sales_revenue"

      }

    }

  }

}

{

  "aggregations": {

    "total_revenue": {

      "value": 4520000000.0

    }

  }

}

Elasticsearch справляется с вычислениями средней сложности. Если вам нужно выполнить что-то действительно сложное, возможно, придется делегировать задачу скрипту на NumPy или Pandas.

Что является залогом успеха построения такой системы

Я думаю две вещи: правильно описанные процессы в компании и правильная архитектура системы.

Правильная архитектура - важная часть, потому как примитивное решение в лоб потом будет больно использовать, и так же больно переделывать. Но хочу заострить внимание на первом пункте.

Если вы попытаетесь натянуть сову на глобус, и сделать какого-то чат бота в компании так как вам (а не вашим пользователям) нужно - не стоит потом удивляться что системой никто не пользуется. То есть вам нужен BPMN и человек в компании или консультант, способный провести подобный анализ.

Всем добра!