Transcription
Сегодня большинство систем генерации с расширенным поиском основаны только на тексте. Однако в реальном мире в ваших документах присутствуют мультимодальные данные, включая изображения и таблицы. В этом видео я покажу вам, как создать мультимодальную систему поиска, которая сможет обрабатывать изображения, текст и таблицы. Мы рассмотрим как проприетарное решение на основе API, так и локальное решение, которое вы можете запускать в частном порядке. Вот как выглядит обычная настройка для текстовой системы поиска. Мы разбиваем наши документы на части, создаём эмбеддинги, но что, если документы содержат изображения и таблицы? Традиционный подход выглядит примерно так. Мы разбираем эти изображения и таблицы из документов, а затем используем языковую модель для изображений, чтобы сгенерировать подписи, а затем встраиваем эти подписи как часть встроенных фрагментов. Таким образом, по существу, мы будем преобразовывать изображения в текстовый markdown. Как вы можете видеть, у этого подхода есть потенциально огромная проблема. Вы теряете много контекстной информации, а также описание основано на используемой вами большой языковой модели или модели обработки изображений, а также на запросе. Поэтому вам нужно быть очень тщательным в составлении запросов. Что, если бы вы могли напрямую обрабатывать это изображение как часть процесса индексирования? В некоторых из моих предыдущих видео мы рассматривали подход, называемый Poly, который фактически позволяет вам делать именно это. Таким образом, он берёт изображения страниц напрямую, кодирует их с помощью кодера изображений, а затем создаёт эмбеддинги. Теперь проблема этого подхода заключается в том, что создаваемые эмбеддинги основаны на поздних взаимодействиях. Таким образом, вы получите многоуровневые эмбеддинги для каждого из фрагментов. Таким образом, требования к памяти довольно высоки, и большинство существующих хранилищ векторов не поддерживают это многоуровневое представление.
Но недавно компания Cohere, которая является компанией, занимающейся моделями Frontier Foundation, представила Embed v4, которая является их мультимодальными эмбеддингами для мультимодального поиска. Их тесты показывают, что этот новый подход к эмбеддингам способен получать лучшие результаты в поиске на основе изображений, даже превосходя что-то вроде Colqpali, которое было построено на основе Colpali. Это очень многообещающе, и хорошо то, что они генерируют эмбеддинги фиксированного размера. Таким образом, вы можете использовать эти эмбеддинги напрямую с хранилищем векторов по вашему выбору. Вот как будет выглядеть рабочий процесс. Мы будем создавать эмбеддинги изображений всех страниц в документе или наборе документов. Затем мы помещаем их в хранилище векторов. Когда поступает запрос пользователя, мы используем ту же модель Embed v4 для генерации эмбеддинга запроса пользователя. Мы выполним поиск, а затем передадим запрос вместе с извлечёнными изображениями в мультимодальную модель, такую как Gemini, и это должно позволить генерировать ответы. Код, который я собираюсь вам показать, основан на публикации Нила Римерса, вице-президента по поиску ИИ в Cohere. Прежде чем рассматривать реализацию, давайте также поговорим о стоимости использования многовекторного представления или даже этих мультимодальных векторных представлений изображений. Хорошая новость в том, что они динамичны по размеру. Таким образом, вы можете выбрать три разных размера ваших векторов эмбеддингов, начиная с 512 и до 1536. Но вы можете фактически квантовать эти векторы эмбеддингов, и это сэкономит вам много ресурсов как на вычислениях, так и на стоимости хранения. Идея заключается в том, что так же, как квантование весов LLM, вы также можете квантовать результирующие векторы, которые генерируются моделью эмбеддингов. И если вы посмотрите на этот график, если вы, скажем, используете 4-битное или 8-битное квантование, оно фактически сохраняет много производительности по сравнению с использованием 32-битного. Оно даёт вам очень похожий уровень производительности при значительно сниженной стоимости. Я освещал квантование эмбеддингов и их влияние на производительность поиска в одном из моих предыдущих видео. Если вам интересно, ссылка будет в описании видео. Также, если вы заинтересованы в изучении методов поиска, выходящих за рамки основ, я только что обновил свой расширенный курс по поиску. Он содержит тему о мультимодальных системах поиска на основе изображений и контекстном поиске. Поэтому обязательно проверьте его. Ссылка будет в описании видео.
Хорошо. Итак, давайте посмотрим на реализацию кода. Это будет основано на примере, который была предоставлена командой Cohere. В первой части мы будем использовать их проприетарный API для использования мультимодальной модели эмбеддингов. Но позже я покажу вам, как вы можете заменить этот проприетарный API локальной моделью, и вы получите очень похожие результаты. Мы сначала встроим наши изображения в этот проприетарный API с локальной моделью, и вы получите очень похожие результаты. Итак, возвращаясь к этому, мы сначала встроим наши изображения или наши документы, используя модель Embed v4. Мы выполним поиск на основе этих эмбеддингов, а затем нам нужно будет передать их в языковую модель для изображений, такую как Gemini или GPT-4.1, для генерации окончательных ответов. Хорошо. Итак, мы установим пакет Cohere Python. Затем сначала нам понадобится ключ API. Итак, перейдите в Cohere, создайте учётную запись, а затем нажмите «API keys». Они предоставляют вам возможность опробовать услуги, используя пробные ключи. Вы видите, что у меня их целая куча. Поэтому, если вы хотите использовать его в продакшене, создайте новый ключ для продакшена, или, чтобы начать работу, просто создайте новый пробный ключ. И вы можете бесплатно протестировать это. Далее мы создадим клиента. Нам также нужен ключ API Gemini. Вы можете получить его из AI Studio, так как мы будем использовать модели Gemini для части генерации. Хорошо. Итак, вот простая вспомогательная функция, которая будет оборачивать длинные тексты. Теперь, для того чтобы выполнить поиск, нам в основном нужно встроить изображения наших документов. Итак, если у вас есть файл PDF, вы сначала хотите преобразовать их в изображения, а затем вы хотите встроить эти изображения. Теперь в этом случае мы будем изменять размер изображений. Вы можете изменить разрешение. Это максимальное разрешение. Думаю, они могут обработать. Однако, в зависимости от выбранного вами разрешения, качество может потенциально ухудшиться, если вы используете изображение с низким разрешением. Хорошо, так что это в основном изменение размера изображений, а затем преобразование base64, это то, что вы получите в изображение, которое вы можете отобразить. Хорошо, так что сначала нам нужны некоторые данные. Итак, в этом примере мы будем использовать некоторые изображения непосредственно с этого веб-сайта, на котором есть очень хорошая инфографика для разных компаний. Что-то вроде этого будет чрезвычайно трудно обработать текстовой LLM, даже если вы сгенерируете подробное текстовое описание перед тем, как встроить его. Но языковая модель для изображений может напрямую обрабатывать это и отвечать на вопросы на основе содержимого. Именно это вы и увидите здесь. Хорошо, вот несколько изображений с этого сайта. Затем мы берём каждое изображение. Итак, мы в основном читаем файлы изображений. Мы передаём их в Embed v4 от Cohere. Мы получаем соответствующие эмбеддинги. Сейчас мы просто создаём массив NumPy, но поскольку это фиксированный размер 1536, вы потенциально можете сохранить это в любое хранилище векторов по вашему выбору. Итак, для этого быстрого примера есть всего шесть разных изображений для разных компаний и соответствующие векторы. Итак, вот вспомогательная функция, которая получает вопрос пользователя. Затем она использует ту же модель Embed v4. Чтобы встроить это, мы получим ответ API, который по сути является этим мультимодальным векторным представлением эмбеддингов. Хорошо. Итак, как только мы получим вектор эмбеддингов для нашего запроса, нам просто нужно выполнить скалярное произведение и выбрать изображение с наибольшим сходством. По существу, мы просто вычисляем косинусное сходство. Хорошо. Итак, мы делаем скалярное произведение, получаем индекс верхнего изображения и возвращаем это изображение для обработки языковой моделью для изображений. Итак, в этом примере вот изображение, которое возвращается, и теперь нам нужно будет передать его в языковую модель для изображений вместе с исходным запросом пользователя. Это очень похоже на нашу текстовую систему генерации с расширенным поиском. Вы также можете добавить переранжировщик. Скажем, вы возвращаете пять или пять лучших или десять лучших изображений, а затем вы можете настроить систему переранжирования на основе изображений, которая будет ранжировать возвращённые изображения и передавать их языковой модели для изображений, очень похожей на текстовую систему генерации с расширенным поиском. Все принципы применимы здесь. Единственное, что вместо разделения вашего документа на части, вы можете просто напрямую встроить изображение вашего документа. Далее мы получаем вопрос вместе с изображением или путём к изображению, возвращённому предыдущим шагом. Мы передаём его в Gemini 2.5 flash preview, и мы получим ответ. Скажем, если вы зададите вопрос, например, какова чистая прибыль Nike? Вот путь к изображению, который был возвращён. Теперь мы передаём это нашей вспомогательной функции, которая вызовет API Gemini. Вот изображение, которое было извлечено. Это наиболее актуально для Nike. И ответ основан на визуализации отчёта о доходах Nike за третий квартал 2025 финансового года. Чистая прибыль Nike, заканчивающаяся в феврале 2025 года, составляет 8 миллиардов долларов. И вы можете видеть, что чистая прибыль указана здесь. Любой текстовой системе будет чрезвычайно трудно сначала преобразовать эту инфографику в текстовую информацию, а затем попытаться найти ответ. Итак, вот ещё один. Какие три крупнейших приобретения Google? Теперь эта инфографика перечисляет все из них, и в основном языковая модель для изображений может просто посмотреть на это и сказать вам. Итак, например, в этом случае ответ - 32 миллиарда долларов. Motorola Mobility стоила 12,5 миллиарда долларов, а Bendant - 5,4 миллиарда долларов. Хорошо, вы можете задавать более сложные вопросы. Что-то вроде этого. Какова была бы чистая прибыль Tesla без учёта процентов? Итак, в этом случае ему нужно выполнить вычисления. Вот чистая прибыль, которая также включает проценты. Хорошо. Итак, если вы посмотрите здесь на ответ, модель Gemini генерирует его, говорится, что чистая прибыль с учётом процентов составляет 0,3 миллиарда долларов. Итак, для того чтобы вычислить чистую прибыль без учёта процентов, ему нужно выполнить вычитание, а затем сгенерировать ответ. Верно? Итак, модель не только способна извлекать информацию, но и способна рассуждать над визуальными данными, которые она видит. И первый шаг - это поиск. Таким образом, вы хотите иметь действительно хороший поиск, и на его основе он сможет генерировать ответы, если вы используете достаточно хорошую языковую модель для изображений. Итак, ещё несколько примеров, в каждом из случаев он очень хорошо справляется с генерацией ответов. Теперь, учитывая, что это игрушечный пример всего лишь, я бы сказал, семи-восьми разных инфографик, но это должно дать вам очень хорошее представление о том, что именно возможно, объединив поиск на основе изображений с языковой моделью для изображений для генерации, и я лично вижу огромную возможность и фактически видел некоторые приложения, работая с разными клиентами, потому что это может рассуждать над гораздо более сложными вопросами. И вам не нужны никакие предварительные шаги обработки, которые вы обычно выполняли бы для вашей текстовой системы генерации документов. Теперь в этом примере мы в основном рассматривали данные изображений. Вы можете создавать изображения таблиц, а затем обрабатывать их очень похожим образом. Или модель Embed v4 позволяет вам обрабатывать текстовые данные вместе с визуальными данными. Итак, скажем, если у вас есть подпись к этому изображению, вы бы встроили её вместе с данными изображения, и это потенциально могло бы дать вам ещё большее повышение точности поиска.
А что, если вы хотите сохранить всё локально и не хотите отправлять какие-либо данные в конечную точку проприетарного API? Ну, вы можете использовать такой подход, как Colpali, который позволит вам запускать систему поиска на основе изображений полностью локально в вашей собственной установке. Теперь в этом случае я покажу вам пример использования Colpali, но для языковой модели для изображений я всё ещё буду использовать Gemini, потому что её проще всего настроить. Однако, если вы хотите посмотреть на полностью локальное решение, я настоятельно рекомендую проверить мой проект с открытым исходным кодом под названием Local GPT. И в основном то, что я собираюсь вам показать, реализовано как часть Local GPT. Но это даёт вам возможность выбирать из широкого спектра моделей, включая полностью локальные модели как для поиска, так и для генерации, или вы можете использовать комбинацию моделей с открытым весом плюс проприетарный API, и если вам нравится проект, обязательно поставьте ему звезду. Хорошо, чтобы использовать Colpali, мы будем использовать пакет BLID, который позволяет запускать модели Colpali или Colqpali для поиска на основе изображений. Хорошо, так что сначала нам нужно установить это. Нам также нужен популярный пакет для преобразования наших файлов PDF в изображения. Вам также понадобится ваш токен API Hugging Face. Я собираюсь удалить это после записи видео. Затем мы используем пакет BLID для загрузки модели Colpali. Как я уже сказал, вы можете использовать модели Colqpali. Они дадут вам аналогичную производительность. Затем мы указываем на папку, где мы хранили все изображения, и это создаст для нас индекс. Теперь настройка очень проста. Это будет локальный индекс. Всё, что вам нужно сделать, это просто вызвать функцию поиска вместе с вашим вопросом. Итак, он вычислит эмбеддинги для этого вопроса на основе модели Colpali. И мы хотим, чтобы он возвращал только верхнее изображение, которое, по его мнению, является наиболее релевантным. Итак, вы получаете результаты. Теперь, поскольку это отдельные изображения, у вас будут разные идентификаторы документов. Теперь мы преобразуем этот поток изображений в байты изображения, и мы можем показать результаты. Итак, например, для первого вопроса: какова чистая прибыль Nike? Вот результат шага поиска. Итак, мы видим, что он правильно определил, что нам нужно использовать это конкретное изображение или документ. Следующий вопрос о крупнейших приобретениях Google. Итак, опять же, вы можете видеть, что он выполняет правильный поиск. Вот Tesla. И так же, как в предыдущем случае, вы собираетесь передать это возвращённое изображение вместе с запросом пользователя чему-то вроде Gemini. Хорошо. Итак, это был быстрый пример того, как выполнять поиск на основе изображений. Я действительно считаю, что поиск или извлечение информации в корпоративном секторе является одной из самых больших проблем, которые ещё предстоит решить, и в этом есть много возможностей. Если вы создаёте какую-либо систему поиска, обязательно ознакомьтесь с моим расширенным курсом по методам поиска, или если вам нужна профессиональная помощь или консультационные услуги, я сейчас их предлагаю. Подробности в описании видео. В любом случае, надеюсь, это видео оказалось полезным.