Как подготовить мультимодальные данные для ИИ: поиск, разметка и проверка качества

Привет, на связи Папа Карло. Подготовка мультимодальных данных для ИИ начинается с поиска нужных материалов, продолжается их отбором и разметкой и заканчивается проверкой качества. Эти задачи можно разделить между разными инструментами: EmbeddingGemma 2 создаёт числовые представления текста, изображений, видео и аудио для смыслового поиска; Voxel51 3.0 объединяет работу с наборами данных, разметку и контроль; OmniExtractBench предлагает детальную оценку извлечённых значений. Однако наличие всех трёх технологий ещё не означает, что данные автоматически станут пригодными для обучения модели. Необходимо определить критерии отбора, проверить результаты обработки и сохранить возможность повторить процедуру.

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

Какие этапы включает подготовка мультимодальных данных

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

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

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

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

EmbeddingGemma 2: поиск по тексту, изображениям, видео и аудио

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

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

Какие компоненты нужны для поиска

Полная конфигурация EmbeddingGemma 2 содержит 740 миллионов параметров. Текстовый компонент включает 270 миллионов, визуальный — 170 миллионов, аудиокомпонент — 300 миллионов. Архитектура допускает загрузку только необходимых частей. Если приложение обрабатывает исключительно текст, дополнительные мультимодальные компоненты можно не использовать.

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

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

Как размер вектора влияет на выбор конфигурации

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

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

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

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

Voxel51 3.0: управление данными и автоматизация разметки

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

Одно из основных изменений версии 3.0 — поддержка мультимодальных временных рядов. Несколько потоков сенсорных данных можно просматривать на общей временной шкале. Это помогает находить отдельные эпизоды внутри продолжительных записей и сопоставлять материалы, относящиеся к одному временному интервалу.

Чем отличается поиск в Voxel51

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

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

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

Что изменилось в разметке

В Voxel51 3.0 поддерживается разметка двумерных изображений, трёхмерных объектов, видео и мультимодальных материалов. Функция Agentic Labeling позволяет формировать метки с использованием моделей компьютерного зрения и языка. Для управления процессом применяются инструкции на естественном языке и примеры.

Среди поддерживаемых форматов заявлены MCAP, облака точек, трёхмерные сетки, DICOM, NIfTI, геопространственные и аудиоданные. Такой набор особенно важен для задач, где информация поступает из специализированных измерительных и визуальных систем.

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

Агент, повторяемые операции и версии

Voxel51 Agent связывает поиск, отбор, разметку и оценку в повторяемые рабочие процессы. Разработчики заявляют более 45 инструментов MCP, свыше 80 операторов и 18 открытых навыков. Эти числа характеризуют набор доступных средств, но не показывают самостоятельно точность разметки или скорость выполнения конкретной задачи.

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

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

Бесплатный тариф включает 30 000 запросов на инференс и 30 вычислительных часов в месяц. Допускается не более трёх наборов данных, каждый объёмом до 10 000 образцов, при общем ограничении хранилища 20 ГБ. Эти пределы необходимо учитывать при оценке возможности использовать платформу для собственного проекта.

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

OmniExtractBench: как оценивать извлечённые значения

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

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

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

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

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

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

Как выстроить процесс подготовки данных

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

1. Определить назначение набора. Указать, какие виды информации нужны модели и для какой операции будет использоваться каждый из них. Отдельно зафиксировать обязательные характеристики материалов.
2. Организовать поиск. Для содержательного сходства использовать семантические представления. Для точных ограничений применять проверку времени, текста и доступных метаданных.
3. Проверить найденные образцы. Сопоставить результаты поиска с исходными материалами. Убедиться, что наиболее похожие записи действительно относятся к нужной задаче.
4. Создать и проверить метки. Определить категории разметки, подготовить примеры и проверить результаты автоматических операций. Случаи расхождения передавать на дополнительный разбор.
5. Зафиксировать состояние набора. Сохранить состав данных, изменения отдельных образцов, применённые критерии и версии материалов, если выбранная инфраструктура это поддерживает.
6. Оценить результат обработки. Сопоставить извлечённые значения с ожидаемыми, отдельно учитывать отсутствующие данные и анализировать конкретные расхождения.
7. Повторить проверку после изменений. Если меняются модель представления данных, правила разметки или состав выборки, повторно проверить операции, на которые изменения могли повлиять.

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

Какие ошибки могут исказить результат

Принимать близость векторов за подтверждение содержания

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

Уменьшать размерность без оценки потерь

Более короткие эмбеддинги экономят пространство индекса. Но результаты EmbeddingGemma 2 показывают, что степень сжатия влияет на качество сопоставления. Поэтому выбор между 768, 512, 256 и 128 измерениями необходимо связывать с требованиями конкретной поисковой задачи, а не только с размером файлов.

Путать автоматическую разметку с проверенной

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

Ограничиваться единственной итоговой метрикой

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

Не фиксировать изменения выборки

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

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

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

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

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

Четвёртый вопрос — воспроизводимость. После изменения набора необходимо установить, какая версия использовалась в каждой проверке. Иначе сравнение результатов разных запусков может оказаться некорректным из-за различий в исходных материалах.

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

Что показывают три разработки

EmbeddingGemma 2 демонстрирует возможности компактного мультимодального представления информации и локального смыслового поиска. Voxel51 3.0 развивает инфраструктуру, в которой можно отбирать, размечать и версионировать сложные наборы данных. OmniExtractBench предлагает более подробный способ оценивать корректность извлечённых значений.

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

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