Руководство разработчика по изучению возможностей Milvus 2.6 в Zilliz Cloud
Milvus начинался как высокопроизводительная open-source векторная база данных, созданная для масштабирования, с передовыми возможностями векторного ANN-поиска. По мере роста сообщества разработчиков запросы на новые функции расширились и стали включать полнотекстовый поиск, boosting и поддержку полуструктурированных типов данных (JSON, struct и т. д.). Эти запросы отражают более широкий тренд к конвергенции возможностей баз данных, обусловленный потребностью в более продвинутых функциях (помимо поиска по сходству), которые помогают ускорить разработку AI-приложений.
Конвергенция проявляется не только в запросах на функции — теперь она проявляется и в самой базе данных. В Milvus 2.6 многие возможности, которые разработчикам раньше приходилось собирать вне базы данных, такие как ранжирование на основе затухания, boosting на уровне полей и гибридная фильтрация по структурированным и неструктурированным данным, теперь стали полноценными примитивами.
Другими словами, Milvus 2.6 знаменует переход от "векторного поиска + glue code" к более продвинутому движку извлечения, и теперь он Generally Available (GA) on Zilliz Cloud (управляемый сервис Milvus).
В этой статье я расскажу о некоторых интересных функциях Milvus v2.6, о том, когда их использовать и как ими пользоваться. Давайте начнем!
Embedding Function (также известная как Data In, Data Out)
Вы когда-нибудь задумывались, может ли база данных взять на себя генерацию embeddings? С помощью Embedding Functions (также известных как "Data in, data out") Milvus может преобразовывать необработанный текст в векторы, обращаясь к внешним сторонним сервисам embeddings, таким как OpenAI, VoyageAI и Cohere.
Embedding Functions впервые были выпущены в Milvus v2.6.0, и я продемонстрировал их в демо kafka-milvus-no-code-pipelines. Теперь Embedding Functions доступны на Zilliz Cloud, полностью управляемом сервисе векторной базы данных Milvus.
Как работает embedding function?
Допустим, вы вставляете "The quick brown fox jumps over the lazy dog" в Milvus с настроенной embedding function. Milvus перехватывает это на уровне proxy, направляет через embedding pipeline, специфичный для провайдера, и сохраняет вектор, созданный вашей моделью. То же преобразование происходит в обратном направлении во время поиска. Текст вашего запроса преобразуется в вектор до того, как попадет в индекс.
Эта функция особенно полезна для команд, которые хотят передать ответственность за управление workflows embeddings базе данных. Позволяя базе данных прозрачно генерировать embeddings во время ingestion (через стороннего провайдера моделей), Zilliz Cloud берет на себя API-интеграцию, batching, retries, rate limits и обработку сбоев.
Чтобы начать работу с Embedding Functions на Zilliz Cloud, вам нужно:
- Настроить Model Provider Integration для выбранного вами провайдера embedding service
- Создать коллекцию с определенной Embedding Function
- Вставить ваши данные.
Если вы все настроили правильно, вы сможете увидеть embedding function в консоли Zilliz Cloud на странице схемы вашей коллекции.
Теперь вам нужно просто вставить необработанный текст, и embeddings будут автоматически сгенерированы и сохранены в указанном вами dense vector field. С определенными embedding functions вам больше не нужно генерировать embeddings, даже для поискового запроса.
Возможная проблема, с которой вы можете столкнуться, — это ограничение размера batch, которое Milvus накладывает при использовании embedding function.
2026-01-21 14:03:12,902 [ERROR][handler]: Ошибка RPC: [insert_rows], <MilvusException: (code=65535, message=numRows [1000] > function [openai]'s max batch [640])>, <Time:{'RPC start': '2026-01-21 14:03:12.722589', 'RPC error': '2026-01-21 14:03:12.902013'}>
Лучшие практики и советы
- Оставайтесь в пределах ограничения размера пакета (показанного в сообщении об ошибке). Это защитный механизм, позволяющий избежать превышения лимита токенов поставщика модели на один API-вызов. Например, у OpenAI есть ограничение максимум 300 000 токенов на один API-вызов.
- Для длинных текстов или сценариев с большими документами необходимо выполнять разбиение на фрагменты перед вставкой. Например, у OpenAI есть лимит 8192 токена на один входной текст для всех моделей эмбеддингов.
- Хотя такие поставщики, как VoyageAI и Cohere, по умолчанию автоматически обрезают длинные тексты, полагаться на это может привести к незаметной потере содержимого в конце вашего документа.
Лексическая подсветка
Лексическая подсветка полезна для того, чтобы показывать пользователям, почему результат соответствует их запросу, визуально отмечая точные термины или фразы, которые вызвали совпадение. Это повышает прозрачность, интерпретируемость и доверие пользователей к результатам поиска.
Вот несколько ключевых сценариев:
Отображение результатов поиска в пользовательских интерфейсах. При создании поисковых интерфейсов подсветка помогает пользователям быстро понять релевантность результата без открытия полного документа. Она снижает когнитивную нагрузку и повышает кликабельность, делая совпадение явным.
Поиск по документам / контенту. В больших документах (например, базах знаний, PDF-файлах, политиках) лексическая подсветка позволяет пользователям мгновенно находить совпавшие ключевые слова в окружающем контексте, ускоряя поиск информации.
Анализ логов / событий. Подсветка в операционных логах или данных событий упрощает обнаружение совпадающих шаблонов, кодов ошибок или ключевых слов в плотном, неструктурированном тексте, особенно во время устранения неполадок или реагирования на инциденты.
Отладка RAG (Retrieval-Augmented Generation). В конвейерах RAG лексическая подсветка помогает специалистам проверять, какие части извлеченных фрагментов совпали с исходным запросом. Это полезно для:
- Проверки корректности извлечения
- Диагностики ложных срабатываний или слабых совпадений
- Понимания, почему определенный контекст был выбран для генерации
Чтобы реализовать серверную лексическую подсветку с Zilliz Cloud, сначала вы создаете экземпляр LexicalHighlighter (с текстом запроса для подсветки и окружающими тегами, указывающими, как выглядит подсвеченный текст) и передаете его как параметр в ваш запрос полнотекстового поиска.
Затем Milvus выполнит поиск и запустит лексическую логику для нахождения точных совпадений и вернет позиционную информацию о том, какие подстроки нужно подсветить.
Лучшие практики и советы
- LexicalHighlighter работает только с полнотекстовым поиском BM25. Он не будет работать для поиска по плотным векторам.
- Вы можете определить
pre_tagsиpost_tags, чтобы оборачивать совпавшие термины HTML-тегами (например, пользовательским CSS-классом, жирным, курсивом и т. д.), которые отображаются непосредственно на веб-странице.
Индекс N-грамм
Индексы N-грамм — это мощные методы индексирования поисковых систем, которые разбивают строки на меньшие и перекрывающиеся последовательности символов (например, "coffee" на 3-граммы -> "cof", "off", "ffe", "fee"), чтобы обеспечить частичное, гибкое сопоставление и сопоставление в стиле wildcard.
Вот несколько сценариев, где индексы n-грамм будут полезны:
- Повышение производительности поиска подстрок (например,
LIKE %deep%) - Search-as-you-type / автодополнение
- Нечеткий поиск
- Поиск доменных имен и идентификаторов (например,
example.com,facebook.com)
Как это работает?
Документы, содержащие указанный n-грамм, можно эффективно находить с помощью индекса, часто называемого инвертированным индексом, который сопоставляет каждый n-грамм со списком идентификаторов документов, содержащих этот n-грамм. Список хранится отсортированным, чтобы обеспечить как эффективное сжатие, так и эффективное выполнение запросов. В случае Milvus ngram index строится поверх Tantivy, который, в свою очередь, использует такие методы сжатия, как delta encoding, bitpacking и skip lists, чтобы сжимать и уменьшать размер инвертированного списка, делая индекс легковесным.
Вместо полного сканирования вашего текстового поля Milvus сначала извлекает предикат, например deep, разбивает его на n-граммы на основе настроенных размеров грамм, выполняет поиски по инвертированному индексу и пересекает результаты, чтобы определить кандидатов, содержащих все граммы, а затем проверяет точные совпадения с исходным шаблоном LIKE.
Milvus позволяет указать min_gram и max_gram, которые соответственно представляют минимальную и максимальную длину n-грамм, которые будут сгенерированы. Подробнее о том, как создать и использовать ngram index, см. в документе NGRAM Index.
Вот короткая демонстрация автодополнения, реализованного с использованием функции ngram index в Milvus.
Лучшие практики и советы
- Проводите бенчмаркинг на репрезентативных запросах: Тестируйте реалистичные шаблоны запросов перед развертыванием в production, чтобы убедиться, что настройки
min_gramиmax_gramсоответствуют фактическому поведению пользователей. - Стратегически комбинируйте с векторным поиском: Используйте фильтрацию, ускоренную NGRAM, как предварительный фильтр, чтобы сократить набор кандидатов перед вычислением векторного сходства, улучшая общую задержку запросов.
- Избегайте избыточного индексирования: Не каждое поле VARCHAR выигрывает от NGRAM index. Отдавайте приоритет полям, часто используемым в запросах
LIKEс шаблонами wildcard. - Обратите внимание, что индекс n-грамм чувствителен к регистру. Это означает, что токены индексируются точно так, как они появляются в исходном тексте, с сохранением различий между прописными и строчными буквами. Запросы должны соответствовать точному регистру, используемому в индексированном содержимом.
Decay Ranker
Представьте, что вы создаете семантическую поисковую систему для научных статей, где вы отдаете предпочтение статьям, опубликованным за последние 10 лет, по сравнению с теми, которые были опубликованы более 10 лет назад.
Без decay ranker в Milvus вам, вероятно, придется повторно ранжировать результаты поиска вне векторной базы данных на основе поля года публикации. Это потребует обработки на стороне сервера приложения / клиента, что добавит как сложности, так и задержки, что может негативно повлиять на пользовательский опыт.
В основе decay ranker в Milvus лежит Decay Function. Decay Functions корректируют оценки релевантности на основе числовых полей (например, временных меток). Итоговая оценка рассчитывается как:
final_score = normalized_similarity_score x decay_score
В настоящее время существует три различные функции затухания, а именно: Linear, Exponential и Gaussian. Каждая функция затухания полезна для разных сценариев. Например, Linear Function следует использовать, когда нужно исключить сущности за пределами определенной точки (например, годы, расстояние и т. д.). Exponential Function можно использовать, когда вы хотите, чтобы более свежие элементы доминировали в результатах, но при этом более старые результаты оставались доступными для обнаружения. Gaussian Function полезна для поиска на основе местоположения, то есть элементы, находящиеся ближе к текущему местоположению, будут ранжироваться выше.
Функции затухания обладают высокой настраиваемостью, и вы можете управлять их формой с помощью нескольких параметров при их инициализации:
- origin: Точка отсчета (например, текущая временная метка)
- offset: Создает «зону без затухания», где элементы сохраняют полные оценки (decay = 1.0). Полезно, чтобы гарантировать, что самые недавние или очень близкие элементы вообще не штрафуются.
- scale: Большие значения обеспечивают более плавное снижение релевантности; меньшие значения — более резкое снижение.
- decay: Управляет крутизной кривой. Более низкие значения (например, 0.3) создают более резкое снижение; более высокие значения (например, 0.7) создают более плавное снижение. Значение по умолчанию — 0.5.
Вот пример того, как определить параметры функции затухания:
- Чтобы использовать текущий год в качестве точки отсчета:
origin=2026 - Исследовательские статьи с 2021 по 2026 год одинаково релевантны, без применения затухания:
offset=6 - Множитель оценки на расстоянии scale:
decay=0.5 - Статьи 2010 года должны иметь оценку затухания (указанную ранее) 0.5:
scale=16(поскольку 2026 - 2010 = 16)
Лучшие практики и советы
- Проводите A/B-тестирование конфигураций затухания. Небольшие изменения параметров
scaleиdecayмогут существенно повлиять на пользовательский опыт. - Убедитесь, что все параметры, основанные на времени (
origin,scale,offset), используют ту же единицу измерения, что и данные вашей коллекции. - FunctionScore принимает только одну DecayFunction на запрос. Цепочки или композиции нескольких DecayFunctions в настоящее время не поддерживаются.
- Каждый ранжировщик затухания поддерживает только одно числовое поле. Нельзя объединять несколько факторов затухания в одном ранжировщике.
- Избегайте затухания на разреженных или смещенных полях. Если поле затухания содержит много null-значений, выбросов или сильно смещенные распределения, ранжирование с затуханием может давать неинтуитивные результаты.
Boosting
Boosting — это практический механизм для включения доменных сигналов в ранжирование векторного поиска. Хотя семантический поиск понимает, о чем ваш запрос, он часто игнорирует то, что важнее в конкретной предметной области. Boosting позволяет повторно ранжировать результаты с использованием произвольного поля метаданных, фактически кодируя бизнес- или доменную интуицию на уровне извлечения.
Например, в рабочем процессе поиска исследовательских статей две статьи могут быть релевантны запросу "deep learning", но не одинаково важны. Статья с большим количеством цитирований может заслуживать позиции выше, чем менее цитируемая, даже если ее оценка сходства немного ниже. С помощью boosting статья с оценкой сходства 0.79, но с 1,200 цитированиями, может быть ранжирована выше статьи с оценкой 0.81 и всего 10 цитированиями.
Вышеописанное можно реализовать, усиливая статьи на основе количества цитирований. Простая реализация выглядит следующим образом:
Но что, если мы хотим усилить исследовательские статьи с количеством цитирований от 100 до 1000 и даже включить функцию затухания, чтобы отдавать предпочтение более свежим статьям. Оказывается, мы можем объединить функцию затухания с несколькими boost-ранжировщиками в одном поисковом запросе с помощью класса FunctionScore.
Лучшие практики и советы
- FunctionScore в настоящее время поддерживается только для поиска по плотным векторам. Гибридный поиск не поддерживает FunctionScore; вместо этого используйте один ранжировщик.
- Для boosting на основе полей с непрерывными значениями рассмотрите возможность разбиения значений на дискретные интервалы и назначения отдельного веса boost каждому интервалу.
Подведение итогов
Milvus 2.6 представляет собой значимый шаг вперед в том, что векторная база данных может делать «из коробки». Перечисленные выше функции и возможности, которые я обсудил, — это не просто приятные дополнения; они устраняют связующий код, который разработчикам ранее приходилось создавать и поддерживать вне базы данных.
Вместо того чтобы сшивать внешние конвейеры эмбеддингов, пользовательскую логику повторного ранжирования и обходные решения для поиска подстрок, теперь вы можете выражать все это напрямую в запросах Milvus. Результат — более чистый код приложения, меньшая задержка и меньше движущихся частей для отладки, когда что-то идет не так.
Если вы воспринимали Milvus как «просто» векторное хранилище, возможно, пришло время заново взглянуть на то, что возможно. Все эти функции теперь доступны в GA на Zilliz Cloud, так что вы можете начать экспериментировать уже сегодня.
Ресурсы
- Документ: Интеграция с поставщиками моделей
- Документ: Функции эмбеддингов на основе моделей
- Блог: Представляем Embedding Function: как Milvus 2.6 упрощает векторизацию и семантический поиск
- Документ: Лексический Highlighter в Zilliz Cloud
- Блог: Как мы создали модель семантической подсветки для сокращения контекста RAG и экономии токенов
- Документ: Индекс NGRAM
- Документ: Обзор Decay Ranker
- Документ: Boost Ranker
Читать далее
Build Multimodal Search for 3D Assets with Tripo and Zilliz Cloud
Generate 3D assets with Tripo, then search them by text, image, and metadata with multimodal embeddings and Zilliz Cloud.
Milvus WebUI: A Visual Management Tool for Your Vector Database
Explore Milvus WebUI to monitor, manage, and optimize your vector database with real-time insights, performance tracking, and system health monitoring.
DeepSeek Always Busy? Deploy It Locally with Milvus in Just 10 Minutes—No More Waiting!
Learn how to set up DeepSeek-R1 on your local machine using Ollama, AnythingLLM, and Milvus in just 10 minutes. Bypass busy servers and enhance AI responses with custom data.