Локальный поиск по фото, видео и документам: как выбрать ИИ-модель, компьютер и хранилище

Привет, на связи Папа Карло. Найти нужную фотографию, документ или видеозапись в большом архиве можно не только по имени файла и папке, но и по смыслу содержимого. Для этого подходят мультимодальные ИИ-модели, которые преобразуют разные типы информации в числовые представления. Один из актуальных примеров — EmbeddingGemma 2 от Google DeepMind. Она рассчитана в том числе на локальную работу, поэтому для создания собственного поискового каталога не обязательно приобретать дорогую рабочую станцию или передавать все материалы удалённому сервису. Но модель — только часть решения. Нужно правильно выбрать вычислительное оборудование, организовать хранение индекса и проверить качество поиска на собственных данных.

Как работает смысловой поиск по разным форматам

Обычный файловый поиск ориентируется прежде всего на имена, расположение и доступные текстовые характеристики материалов. Если фотография называется IMG_0012.jpg, а пользователь ищет изображение определённого предмета, традиционному поиску может не хватить информации. Смысловой поиск решает другую задачу: сравнивает не буквальное совпадение названий, а содержание материалов.

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

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

Что предлагает EmbeddingGemma 2

Google DeepMind представила EmbeddingGemma 2 6 октября 2026 года. Это открытая мультимодальная модель, ориентированная на представление текстов, программного кода, изображений, видео и аудио в едином векторном пространстве. Её практическая особенность — оптимизация для работы непосредственно на устройствах, включая смартфоны и ноутбуки.

Модульная архитектура и память

Полная конфигурация содержит 740 миллионов параметров. Они распределены между текстовым компонентом на 270 миллионов, визуальным на 170 миллионов и аудиокомпонентом на 300 миллионов параметров. Модульная архитектура позволяет не загружать дополнительные компоненты, если приложение использует только текст.

По данным Google, текстовая конфигурация на Pixel 11 Pro занимает около 191 МБ оперативной памяти, тогда как полная мультимодальная версия — приблизительно 567 МБ. Это важный ориентир: сама модель может быть достаточно компактной для локального применения. Но приведённые значения относятся к конкретной конфигурации и устройству. Они не описывают полностью потребление памяти будущим приложением с индексом, файловым каталогом и другими компонентами.

Модель поддерживает более 100 языков и контекст до 8192 токенов. В одном входном наборе могут сочетаться разные форматы данных, включая текст, видеокадры и аудиофрагменты. Благодаря этому её можно рассматривать для каталогов, в которых рядом находятся документы, фотографии и другие материалы.

Почему размер вектора влияет на систему

Исходное пространство EmbeddingGemma 2 имеет размерность 768. Также предусмотрены выходные представления на 512, 256 и 128 измерений. Уменьшение размерности сокращает объём данных, необходимых для хранения векторов, но способно ухудшать качество поиска.

В опубликованных результатах сокращение до 256 измерений сопровождалось сравнительно небольшими потерями качества. При уменьшении до 128 измерений ухудшение оказалось заметнее: показатель MMEB v2 снижался с 59,01 до 45,65. Это конкретный результат тестирования модели, а не универсальная оценка точности любого пользовательского каталога.

Из каких компонентов состоит локальный поисковый каталог

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

На концептуальном уровне архитектуру можно разделить на несколько частей. Первый компонент получает материалы из выбранных каталогов. Второй подготавливает их к обработке моделью. Третий формирует эмбеддинги. Четвёртый хранит полученные векторы вместе с идентификаторами исходных файлов. Пятый принимает пользовательские запросы и возвращает результаты сопоставления.

Зачем сохранять связь с оригиналом

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

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

Выбор оборудования: обычный компьютер, Radxa или мощная рабочая станция

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

Radxa Dragon Q8B как компактная платформа

Одноплатный компьютер Radxa Dragon Q8B представляет интерес для небольших серверных задач. Рассмотренная конфигурация оснащена Qualcomm SC8280XP и 8 ГБ оперативной памяти LPDDR4X. Её цена составляет 209 долларов без доставки, тогда как Raspberry Pi 5 с аналогичным объёмом памяти оценивалась в 175 долларов.

В многопоточном Geekbench 6 Dragon Q8B набрала приблизительно втрое больше баллов, чем Raspberry Pi 5. В приведённом сравнении энергоэффективность вычислений составляла 3,73 против 2,75 Гфлопс на ватт. Кроме того, Dragon Q8B получила два порта Ethernet по 2,5 Гбит/с и возможности расширения через PCIe.

Главное ограничение Dragon Q8B — зрелость программной платформы. Для Linux предлагаются специализированные образы Radxa, настройка выполняется с использованием Rsetup. При тестировании отмечались недостаточная плавность Linux-окружения и проблемы с прошивкой UEFI. Поэтому преимущество аппаратной производительности не гарантирует быструю установку необходимого программного обеспечения.

AceMagic F9A: когда большой объём памяти действительно полезен

На другом конце аппаратного спектра находится AceMagic F9A. Это компактная рабочая станция с процессором AMD Ryzen AI Max+ Pro 495, 192 ГБ оперативной памяти и SSD на 2 ТБ. Её корпус имеет размеры 158,5 × 158,5 × 81,5 мм.

Производитель заявляет возможность выделения до 160 ГБ унифицированной памяти под задачи, использующие видеопамять. Также упоминается локальный запуск больших языковых моделей объёмом до 300 миллиардов параметров. Но это заявленные возможности, а не опубликованные результаты проверки производительности EmbeddingGemma 2.

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

На китайском рынке стандартная цена F9A составляет 50 999 юаней, а стартовая — 49 998 юаней. Для задачи создания небольшого поискового каталога это принципиально иной бюджет по сравнению с одноплатным компьютером.

Хранение архива: почему четыре NVMe SSD не означают четырёхкратную скорость

Кроме вычислений, локальной поисковой системе потребуется хранилище оригинальных файлов и индексов. В некоторых проектах основную ёмкость могут занимать фотографии и видео, тогда как сами эмбеддинги будут только частью общего объёма данных.

Один из вариантов увеличения числа накопителей — карта расширения JGINYUE на чипсете AMD B650. Она позволяет установить четыре NVMe SSD формата M.2, используя один слот PCIe компьютера. Заявленная стоимость адаптера составляет 58 долларов.

Важная техническая особенность заключается в общем подключении PCIe 4.0 x4. Чипсет распределяет линии между четырьмя накопителями, но обмен с основным компьютером всё равно проходит через один четырёхлинейный интерфейс.

Поэтому карта решает прежде всего задачу увеличения количества подключённых SSD. Если несколько накопителей одновременно выполняют интенсивные операции, они разделяют доступную пропускную способность общего соединения. Четыре быстрых диска не становятся четырьмя независимыми полноскоростными каналами.

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

Пошаговый план внедрения локального поиска

Шаг 1. Определить сценарии поиска

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

Шаг 2. Выбрать минимально необходимую конфигурацию модели

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

Шаг 3. Подготовить небольшой контрольный набор

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

Шаг 4. Организовать обработку и индексирование

Следующий этап — создать программную цепочку, которая передаёт данные модели, получает векторы и сохраняет их вместе с идентификаторами оригинальных файлов. Конкретный способ реализации зависит от выбранных программных средств: опубликованные характеристики EmbeddingGemma 2 не заменяют документацию полноценного поискового приложения.

Шаг 5. Сравнить варианты размерности

Для контрольного набора можно последовательно оценить представления размерностью 768, 512 и 256 измерений, а при необходимости — 128. На каждом варианте нужно повторить одинаковые запросы и сравнить список результатов.

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

Шаг 6. Подбирать оборудование по фактической нагрузке

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

Как проверить, что система действительно работает

Успешный запуск модели ещё не означает успешный поиск. Проверка должна охватывать всю цепочку — от чтения оригинального файла до открытия результата пользователем.

1. Проверка точности. Выполнить подготовленные запросы и убедиться, что соответствующие им материалы действительно присутствуют среди результатов. Отдельно записать нерелевантные совпадения.
2. Проверка мультимодальности. Если предусмотрен поиск изображений по тексту, проверить именно такой сценарий, а не ограничиваться сопоставлением текстовых документов.
3. Проверка ссылок. Открыть несколько найденных файлов и убедиться, что индекс связан с правильными оригиналами.
4. Проверка обновления. Добавить, изменить и удалить контрольные материалы, затем проверить, отражаются ли эти изменения в результатах после обновления индекса.
5. Проверка ресурсов. Оценить потребление памяти и поведение системы при индексировании и обычных запросах. Не переносить показатели памяти, опубликованные для Pixel 11 Pro, непосредственно на другую платформу.
6. Проверка скорости. Раздельно оценить продолжительность первичного индексирования и обработки последующих запросов. Это разные операции, которые могут предъявлять разные требования к оборудованию.
7. Проверка хранения. Убедиться, что выбранная дисковая конфигурация справляется с предполагаемыми операциями и что ограничения общего интерфейса PCIe не мешают выполнению задач.

Типичные ошибки при построении локального ИИ-поиска

Покупка дорогого оборудования до проверки модели

Объём памяти AceMagic F9A впечатляет, но он сам по себе не доказывает необходимость подобного компьютера для EmbeddingGemma 2. Возможности запуска больших генеративных моделей нельзя напрямую переносить на требования компактной модели эмбеддингов.

Оценка платы только по процессорным тестам

Преимущество Radxa Dragon Q8B над Raspberry Pi 5 в многопоточном Geekbench 6 не гарантирует аналогичного преимущества в целевом поисковом приложении. Кроме того, сложности Linux и UEFI могут оказаться существеннее потенциального выигрыша в вычислениях.

Чрезмерное уменьшение размерности

Переход на 128 измерений сокращает размер представлений, но для EmbeddingGemma 2 уже показано заметное ухудшение одного из мультимодальных показателей. Поэтому минимальный индекс не обязательно является оптимальным.

Путаница между ёмкостью и пропускной способностью

Четыре разъёма NVMe на карте JGINYUE позволяют подключить дополнительные диски, однако все они используют общий PCIe 4.0 x4. Увеличение числа накопителей нельзя считать автоматическим способом пропорционально ускорить поиск.

Отсутствие контрольных запросов

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

Предположение, что локальность решает все вопросы

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

Итог: сначала проверяем поиск, потом масштабируем оборудование

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

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