- Проблема RAG только на основе текста
- Архитектура
- 5 ключевых выводов Урок первый: Измеряйте, прежде чем добавлять инфраструктуру Урок второй: Не просите LLM делать работу, которую вы и сами умеете делать Урок третий: Промежуточные представления — часть наблюдаемости Урок четвертый: Безопасность начинается тогда, когда прототип еще доставляет удовольствие Урок пятый: Локальный ИИ может зайти на удивление далеко
- Урок первый: Измеряйте, прежде чем добавлять инфраструктуру
- Урок второй: Не просите LLM делать работу, которую вы и сами умеете делать
- Урок третий: Промежуточные представления — часть наблюдаемости
- Урок четвертый: Безопасность начинается тогда, когда прототип еще доставляет удовольствие
- Урок пятый: Локальный ИИ может зайти на удивление далеко
- Переход от локального прототипа к планетарному масштабу
- А потом вернулась футболка
- Возможно, RAG — это больше, чем просто документы
Основные выводы
Мультимодальный поиск начинается с представления информации, которая действительно нужна пользователям, и эта информация может быть визуальной, а не текстовой.
Для некоторых рабочих нагрузок простые матричные операции могут обеспечить быстрый поиск без дополнительной инфраструктуры векторных баз данных.
Большие языковые моды (LLM) приносят наибольшую пользу, когда им поручают задачи, действительно требующие языковых рассуждений.
Где-то на стыке облачных вычислений, открытого исходного кода и моды находится футболка Akamai.
Компания Akamai объединилась с UNIQLO для участия в благотворительном проекте футболок PEACE FOR ALL, перенеся свои цифровые истоки в физический мир. Дизайн включает в себя сердце на передней части и настоящий компьютерный код на задней, отсылку к Linux, а также основы интернета с открытым исходным кодом.
Видя, как компьютерный код превращается в футболку, я задался вопросом, может ли этот процесс работать в обратном направлении: если технологии могут стать модой, может ли мода стать тем, что ИИ способен понимать и искать? Точнее говоря, какую систему дополненной поиском генерации (RAG) на самом деле хотела бы международная команда дизайнеров одежды?
Затем в архитектуру вошла Миранда Пристли.
Я пересматривал The Devil Wears Prada 2 во время долгих полетов, когда эта идея стала более конкретной. Где-то между миром моды, невыполнимыми дедлайнами и знаменитыми жесткими требованиями Миранды Пристли (она грозный, холодный и проницательный главный редактор Runway, вымышленного журнала высокой моды из фильма) я начал думать о том, что на самом деле должен делать корпоративный ИИ-ассистент для модной организации.
Представьте себе дизайнера, который спрашивает: «Покажи мне прошлые женские жакеты с таким же силуэтом, но с более коротким воротником». Или японского дизайнера, ищущего теплое зимнее пальто на японском языке, за которым следует итальянский дизайнер, уточняющий тот же поиск на итальянском.
Обычная текстовая RAG-система может искать по описаниям, документам и метаданным. Но то, что ищет дизайнер, может вообще не существовать в словах. Это может быть в пикселях: силуэте, узоре, цвете, крое или визуальной связи между одним дизайном и другим.
Это привело к инженерной задаче: смогу ли я построить RAG-систему, которая позволила бы командам дизайнеров одежды искать в визуальных архивах так, как они привыкли думать, и так, чтобы это могло заслужить даже небольшое одобрение от Миранды Пристли?
Я назвал ее Миранда.
Проблема RAG только на основе текста
Прежде чем создавать визуальную систему, я провел нарочито нелепый эксперимент с обычным текстовым поиском (Рисунок 1).
Результат отлично иллюстрирует проблему. Текстовый поиск может быть превосходным, когда нужная нам информация представлена в виде текста, а оптическое распознавание символов (OCR) может помочь, когда слова встроены в изображения или документы.
Однако ни то, ни другое необязательно отражает сам дизайн.
Архив моды по своей сути мультимодален, поэтому вместо того, чтобы просить LLM каким-то образом угадывать визуальное содержание сотен тысяч изображений, я попробовал кое-что попроще: я превратил изображения в векторы.
Архитектура
Базовый пайплайн в итоге оказался удивительно простым (Рисунок 2).
В этой операции q — это нормализованный эмбеддинг запроса, E — матрица, содержащая нормализованные эмбеддинги изображений, а S — оценка сходства. После вычисления этих оценок этап поиска выбирает изображения с наибольшими оценками (K).
Другими словами, одно матричное умножение сравнивает запрос со всеми векторами изображений, а наивысшие оценки становятся результатами. Исходный код и инструкции по воспроизводимости для эксперимента «Миранда» находятся здесь: available.
5 ключевых выводов
Проектирование и масштабирование этой системы стало упражнением по избавлению от ненужной сложности. В процессе масштабирования этого эксперимента с нескольких сотен изображений почти до 300 000 поведение стека в реальных условиях часто бросало вызов моим первоначальным предположениям. Следующие пять уроков отражают основные инженерные принципы, архитектурные корректировки и компромиссы в области безопасности, которые выявились при тестировании пределов возможностей локальных ИИ-моделей.
- Измеряйте, прежде чем добавлять инфраструктуру
Измеряйте, прежде чем добавлять инфраструктуру
- Не просите LLM делать работу, которую вы и сами умеете делать
Не просите LLM делать работу, которую вы и сами умеете делать
- Промежуточные представления — часть наблюдаемости
Промежуточные представления — часть наблюдаемости
- Безопасность начинается тогда, когда прототип еще доставляет удовольствие
Безопасность начинается тогда, когда прототип еще доставляет удовольствие
- Локальный ИИ может зайти на удивление далеко
Локальный ИИ может зайти на удивление далеко
Урок первый: Измеряйте, прежде чем добавлять инфраструктуру
Я начал с малого — с 500 изображений. Затем перешел к 5 000, 50 000 и 200 000.
В конце концов в эксперименте стало 289 222 изображения, представленных 512-мерными векторами, с полной матрицей эмбеддингов FP32 размером примерно 565 МиБ. На моем Mac с использованием бэкенда MPS от Apple поиск по всей матрице с помощью PyTorch GEMM оставался удивительно быстрым. В одном из запусков генерация текстового эмбеддинга CLIP заняла 162,3 миллисекунды, в то время как его сравнение со всеми 289 222 векторами изображений заняло всего 10,8 миллисекунды.
Точные цифры варьируются от запуска к запуску, но закономерность была достаточно стабильной, чтобы привлечь мое внимание.
Это показало мне, что сам по себе поиск не обязательно является самой затратной частью. Часто больше времени уходило на всё, что его окружает.
Это подводит меня к инженерному принципу, к которому я постоянно возвращаюсь: измеряйте ту систему, которая у вас есть в данный момент, прежде чем добавлять инфраструктуру для системы, которую вы, как вам кажется, создадите в будущем.
Векторная база данных вполне может стать правильной архитектурой по мере изменения масштаба или требований, особенно когда вам нужны распределенное хранилище, фильтрация, частые обновления, миллиарды векторов, отказоустойчивость, мультиарендность или другие возможности. Но я не думаю, что «RAG» должен автоматически означать «векторная база данных».
Иногда матрицы вполне достаточно.
Урок второй: Не просите LLM делать работу, которую вы и сами умеете делать
Моя первая многоязычная реализация пропускала практически каждый запрос через локальную LLM. Это работало, но также означало использование LLM для запросов, которые в ней на самом деле не нуждались.
Например, если кто-то вводит «черное зимнее пальто», намерение и так очевидно.
Зачем тратить секунды на то, чтобы просить LLM преобразовать perfectamente рабочий английский поисковый запрос о моде в другой английский поисковый запрос о моде?
С этой целью я добавил маршрутизацию. Прямолинейные поисковые запросы на английском языке обходят LLM и направляются напрямую в CLIP, в то время как японские, итальянские и другие многоязычные запросы могут использовать локальную LLM для нормализации пользовательского намерения в лаконичный английский перед созданием эмбеддинга CLIP.
Это наделяет каждый компонент четкой задачей: LLM интерпретирует язык, CLIP представляет поисковое намерение в том же векторном пространстве эмбеддингов, что и изображения, а GEMM извлекает ближайшие векторы.
Это разделение оказалось одним из важнейших архитектурных уроков, которые я вынес из этого эксперимента. LLM имеет смысл применять там, где языковое рассуждение добавляет ценности. В остальных же случаях более простой компонент может отлично справиться с задачей.
Урок третий: Промежуточные представления — часть наблюдаемости
В процессе разработки Miranda время от времени неправильно понимала уточняющие запросы. Вместо того чтобы прятать всё за отполированным ответом чат-бота, я вынес на поверхность промежуточное представление, чтобы видеть, что именно происходит между запросом пользователя и поиском (Рисунок 3).
Такая прозрачность оказалась невероятно полезной. Когда результат поиска выглядел неверным, я мог сразу увидеть, испытывает ли CLIP трудности с поиском или же языковой слой изначально передал ему не тот запрос.
Для систем ИИ наблюдаемость не должна ограничиваться CPU, памятью и задержкой HTTP. Она также может включать в себя отображение или, по крайней мере, логирование преобразований, происходящих при перемещении информации между моделями, поскольку именно в этих промежуточных представлениях зачастую и кроется баг.
Урок четвертый: Безопасность начинается, пока прототип еще вызывает интерес
Поскольку мой профессиональный бэкграунд связан с безопасностью, я не смог удержаться от того, чтобы не атаковать собственный модный чат-бот.
Я попросил Miranda написать программу Hello World на C++.
Очевидно, что поисковый ассистент в сфере моды не должен этим заниматься, даже если за интерфейсом стоит LLM. Это выявило потребность в доменном шлюзе (domain gate): элементе управления, который удерживал бы Miranda в рамках запросов о моде и отклонял бы запросы, выходящие за рамки предполагаемого использования.
Но как только я добавил эту границу, я столкнулся с противоположной проблемой. Рассмотрим два следующих запроса:
Слово «код» присутствует в обоих из них, но их намерения совершенно различны. Первый должен быть отклонен, в то время как второй является абсолютно легитимным запросом, связанным с модой.
Простой черный список подозрительных слов не сработал бы. Система должна была понимать контекст, что указывает на более широкий принцип безопасности: средства обеспечения безопасности должны понимать предполагаемые возможности системы, а не просто реагировать на отдельные токены, появляющиеся в запросе.
Продумывать эти границы, пока Miranda все еще оставалась прототипом, было гораздо проще, чем пытаться встроить их туда позже.
Урок пятый: Локальный ИИ может зайти на удивление далеко
Весь эксперимент начался на компьютере Mac с процессором Apple Silicon, причем OpenCLIP и поиск на базе PyTorch выполнялись через MPS, в то время как языковая модель и архив моды оставались локальными. Это было не просто удобно.
Для архивов корпоративного дизайна сами изображения могут представлять собой ценную интеллектуальную собственность, и дизайн-команда может вполне обоснованно предпочесть архитектуру, при которой проприетарные дизайны не покидают контролируемую среду просто ради обеспечения возможности их поиска.
А поскольку код PyTorch уже умеет выбирать между MPS и CUDA, та же самая базовая архитектура может быть перенесена с прототипа на базе Mac на GPU от NVIDIA без перепроектирования приложения.
Это создает практический путь от прототипа к продакшену: начните локально, измерьте то, что происходит на самом деле, а затем масштабируйте тот компонент, который в этом нуждается.
Тот же подход применим и к месту выполнения этих рабочих нагрузок. По мере того как приложение визуального поиска переходит в стадию продакшена и начинает обслуживать большее число пользователей, более крупные архивы или распределенные по всему миру команды, компоненты на базе CUDA могут быть перенесены на распределенную инфраструктуру GPU без изменения базовой логики поиска.
Переход от локального прототипа к планетарному масштабу
Akamai Inference Cloud создана именно для такого рода распределенного инференса в реальном времени, приближая вычисления на GPU к пользователям и данным и позволяя командам масштабировать те части системы, которые в этом действительно нуждаются.
Хотя локальное тестирование на Apple Silicon доказывает математическую эффективность поиска на базе GEMM, корпоративный визуальный поиск по миллионам глобальных активов требует распределенной инфраструктуры. Развертывание этих рабочих нагрузок OpenCLIP и PyTorch в Akamai Inference Cloud приближает принятие решений на базе GPU к глобальным командам дизайнеров, помогая обеспечить сверхнизкую задержку, защитить проприетарную интеллектуальную собственность и гарантировать прогнозируемую экономическую эффективность.
А затем появилась та самая футболка
Чтобы замкнуть круг, я провел финальный эксперимент.
Я добавил три изображения футболки Akamai × UNIQLO PEACE FOR ALL в корпус модных данных и перестроил индекс, доведя их общее количество до 289 222 изображений.
Я нарочно не стал просить Miranda найти «футболку Akamai». Вместо этого я ввел поисковый запрос: «футболка с гиковским компьютерным кодом». После этого Miranda выполнила поиск по всем 289 222 векторам.
Футболка Akamai × UNIQLO появилась в качестве третьего результата с показателем сходства 0.307 (Рисунок 4).
Окружающие результаты находились именно в том семантическом поле, которое я надеялся увидеть: футболки с двоичным кодом, текстом в техническом стиле и другой компьютерной графикой.
В том запуске поиск на базе GEMM занял около 10,8 миллисекунды.
Этот результат замкнул круг неожиданным для меня образом. Akamai и UNIQLO нанесли код на футболку, что помогло мне задуматься о том, чем поиск на базе ИИ может стать для индустрии моды. Я превратил эту моду в векторы, выполнил по этим векторам поиск гиковской футболки с компьютерным кодом, и система снова нашла футболку Akamai без какого-либо указания искать именно Akamai.
Как удивительно циклично.
Возможно, RAG — это нечто большее, чем просто работа с документами
RAG часто объясняют как способ предоставить LLM доступ к документам, которые она не видела во время обучения.
Это полезно, но данный эксперимент подкрепил нечто более фундаментальное: архитектура должна следовать за той информацией, которую пользователи пытаются извлечь.
Для юридических исследований эти представления могут в основном состоять из слов. Для операций — из логов и метрик. Для модельеров, архитекторов, промышленных дизайнеров или креативных команд они все чаще могут носить визуальный характер.
В случае с Miranda это означало начать с самого визуального архива, представить его в форме, доступной для поиска системой, а затем добавить языковые рассуждения только там, где это было полезно. Векторная база данных, модель или инфраструктура появляются уже после этого.
Miranda началась с идеи, которая пришла мне в голову во время просмотра фильма на борту самолета во время долгого перелета. В конечном итоге она научила меня гораздо большему: маршрутизации, мультимодальному поиску, задержкам, границам безопасности, локальному инференсу и ценности измерений до начала проектирования.
И где-то внутри матрицы из 289 222 × 512 чисел с плавающей запятой теперь живет довольно гиковская футболка Akamai. Моя Miranda нашла ее, и я думаю, что Миранда Пристли даже одобрила бы это.
Об авторе (-ах)
Алекс Люн (Alex Leung)
Алекс Люн (Alex Leung) — старший корпоративный архитектор в компании Akamai. Он консультирует ведущие предприятия в сферах медиа, электронной коммерции и цифровых платформ по вопросам создания масштабируемых, безопасных и высокопроизводительных интернет-архитектур.
Обладая более чем 20-летним опытом, Алекс руководил самыми разными проектами, охватывающими ОТТ-вещание (over-the-top), периферийные вычисления и крупномасштабные распределенные системы. Помимо помощи вещательным компаниям в адаптации их сервисов для доставки контента по ОТТ, он проводил оценку безопасности для многочисленных организаций, повышая устойчивость их веб- и мобильных приложений к современным угрозам.
До прихода в Akamai Алекс реализовал сложные проекты, включая платформу видео по запросу для электронного обучения государственных ведомств в специальном административном районе Гонконг и поисковую систему изображений на базе Apache SOLR.
Он имеет степень магистра в области прикладной физики Стэнфордского университета и степень бакалавра в области инженерной физики Корнеллского университета.
