Искуственный мозг компании на LLM: пособие для менеджеров корпораций

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Подписывайтесь на мой канал.