Что нового в Manticore Search 29.9.0
Manticore Search 29.9.0 добавляет chunked и multi-vector auto-embeddings: длинный документ теперь можно разбить на фрагменты по одной из пяти стратегий и хранить для него несколько векторов в типе float_vector_array. Параллельно mmap стал режимом доступа по умолчанию для columnar-атрибутов, а в схемах разрешили UTF-8 идентификаторы таблиц, полей и атрибутов.
Обязательной миграции данных релиз не требует. Дополнительные шаги нужны точечно: если вы хотите сохранить прежнее чтение columnar-атрибутов через файловый буфер, задайте access_columnar_attrs='file'.
Пять ключевых изменений выглядят так.
- Chunked auto-embeddings. Сервер сам режет документ на фрагменты по выбранной стратегии: truncate, mean, fixed, recursive или sentence.
- Тип float_vector_array. Один документ может хранить несколько векторов вместо одного.
- Опция MAX_INPUT_TOKENS. Ограничивает объем текста, который уходит в локальную embedding-модель, и снижает нагрузку на CPU при длинном контексте.
- mmap для columnar-атрибутов по умолчанию. Отображение файлов в память пришло на смену buffered file reads.
- UTF-8 идентификаторы. Имена таблиц, полей и атрибутов можно писать нелатинскими символами, плюс появилась опциональная нормализация немецкого sharp-s.
Еще в релиз вошли authenticated backup и работа manticore-load через HTTP JSON API. Исправления затронули hybrid search, KNN, bulk ingestion, grouped search и изменения схемы.
Chunked auto-embeddings: как разбивать длинные документы на фрагменты
Embedding-модель принимает ограниченное число токенов. Если документ длиннее, в вектор попадает только начало, а хвост отбрасывается. Для поиска это означает простую вещь: релевантный абзац из второй половины статьи в индекс не попадет, и запрос по нему ничего не найдет. Chunked auto-embeddings снимают ограничение на стороне сервера: документ режется на фрагменты, каждый векторизуется отдельно.
Стратегия разбиения задается при создании таблицы или в конфигурации. Вариантов пять, и различаются они не столько алгоритмом, сколько тем, чем вы готовы пожертвовать: полнотой, размером индекса или стабильностью границ.
| Стратегия | Что делает | Когда подходит | Ограничения |
|---|---|---|---|
| truncate | Берет начало документа до лимита токенов, остальное отбрасывает | Короткие новости, чаты, письма, где смысл сосредоточен в начале | Хвост документа исчезает из поиска полностью |
| mean | Считает векторы фрагментов и усредняет их в один общий вектор | Тематически однородные документы: отчеты, протоколы, обзоры | Локальные детали размываются, в индексе остается один вектор на документ |
| fixed | Режет на чанки фиксированного размера по токенам или символам | Однородные логи, выгрузки, потоковые данные с предсказуемой структурой | Граница может попасть в середину предложения |
| recursive | Идет по иерархии разделителей: абзац, предложение, слово | Статьи, документация, базы знаний, где важна структура текста | Чанки разной длины, нужен запас по памяти при индексации |
| sentence | Дробит текст по предложениям | Научные статьи, юридические документы, регламенты | Много коротких векторов, растет размер индекса |
truncate держит один вектор на документ и работает быстрее всех остальных вариантов: вычислять нужно ровно один эмбеддинг. Для архива коротких тикетов или ленты новостей этого достаточно.
mean тоже оставляет один вектор, но строится он по всему документу. Усреднение хорошо работает, когда текст раскрывает одну тему от начала до конца. Если в документе три разные темы, средний вектор получится «никаким»: похож на все и не похож ни на что.
fixed дает предсказуемый размер чанка, и это удобно для планирования памяти. Цена предсказуемости - разорванные предложения на стыках. Для текстов на естественном языке это заметная потеря качества.
recursive ищет границу по разделителям от крупных к мелким, поэтому старается не рвать смысловые блоки. Это разумный выбор по умолчанию для статей и документации, если у вас нет причин брать что-то другое.
sentence дает самую точную привязку к формулировкам. Научная статья про методы обучения моделей разбирается на отдельные утверждения, и запрос про конкретную метрику находит именно то предложение, где она упомянута. Плата - количество векторов: длинный текст превращается в сотни чанков.
Multi-vector embeddings и float_vector_array: один документ - несколько векторов
Классическая схема хранит на документ ровно один вектор. Тип float_vector_array меняет правило: в одной записи лежит массив векторов, и chunked auto-embeddings заполняют его автоматически при индексации.
Схема работы выглядит так. Документ на десять тысяч символов разбивается на пять фрагментов, каждый фрагмент получает свой вектор, и все пять сохраняются в одном атрибуте float_vector_array. При KNN-поиске сравниваются не документы целиком, а отдельные векторы из массива: ближайшим может оказаться третий фрагмент, и именно он определяет релевантность документа.
Практический эффект для длинных текстов заметный. Раньше документ с релевантным абзацем в конце либо не находился вовсе, либо получал низкий скор, потому что вектор строился по началу. Теперь совпадение ищется среди фрагментов, и полнота выдачи по длинным материалам растет без переписывания самих документов.
Обратная сторона - объем индекса. Пять векторов на документ вместо одного означают рост векторного хранилища и времени индексации примерно пропорционально числу чанков. Для баз знаний это приемлемая плата, для миллионов коротких записей - уже вопрос.
Опция MAX_INPUT_TOKENS: контроль нагрузки на CPU
MAX_INPUT_TOKENS задает предел в токенах для текста, который подается в локальную embedding-модель. Опция работает с моделями, запущенными на той же машине, где стоит Manticore, и решает две задачи: не дает переполнить контекст модели и ограничивает время вычисления.
Зависимость нагрузки от длины входа нелинейная: обработка текста на 2048 токенов занимает заметно больше времени, чем двух текстов по 1024. Если модель рассчитана на 512 токенов, значение MAX_INPUT_TOKENS=512 отсекает лишнее до подачи в модель, и CPU не тратит время на обработку хвоста, который все равно будет отброшен.
Что происходит с излишком, зависит от выбранной стратегии разбиения: truncate просто обрежет текст, а fixed или recursive успеют порезать его на чанки до применения лимита. Это стоит держать в голове: слишком маленькое значение MAX_INPUT_TOKENS вместе с truncate превращает длинный документ в его первый абзац, и в поиске он будет представлен только началом.
mmap для columnar-атрибутов: новый режим по умолчанию
Columnar-атрибуты хранят значения по столбцам, и запросы к ним читают данные выборочно. В 29.9.0 доступ к таким данным по умолчанию идет через mmap: файл отображается в адресное пространство процесса, а страницы подгружает операционная система по мере обращения.
Прежний режим buffered file reads читал данные через системные вызовы и промежуточный буфер. mmap убирает лишнее копирование и позволяет ядру держать горячие страницы в page cache между запросами, поэтому повторные обращения к одним и тем же столбцам становятся дешевле.
Цена решения - виртуальная память. Отображенный файл виден в адресном пространстве целиком, даже если физически подгружена лишь часть страниц. На мониторинге это выглядит как резкий рост потребления памяти процессом, хотя реальная резидентная память может быть заметно меньше. Если столбцы редко читаются, а файл большой, лишние page faults и вытеснение полезных страниц способны замедлить работу.
Вернуть прежнее поведение можно настройкой access_columnar_attrs='file'. Это штатный переключатель, и держать его под рукой стоит на случай, если после обновления аналитические запросы по колоночным атрибутам поехали в сторону замедления.
UTF-8 идентификаторы и нормализация sharp-s
Раньше имена таблиц, полей и атрибутов приходилось писать латиницей, а русские названия жили только в значениях. Теперь в идентификаторах допустимы UTF-8 символы, и схему можно называть на языке предметной области.
CREATE TABLE `новости` (
id bigint,
`заголовок` text,
`текст` text
);
В запросах такие имена нужно экранировать обратными кавычками: SELECT `заголовок` FROM `новости` WHERE MATCH('...'). Пока в командах участвуют только ASCII-имена, ничего не меняется. Как только появляются кириллические или другие нелатинские символы, экранирование становится обязательным, иначе парсер не поймет строку.
Дополнительно добавлена опциональная нормализация немецкого sharp-s. Символ ß приводится к ss, поэтому запрос «strasse» и «straße» находят одни и те же документы. Опция полезна для немецкоязычных каталогов и поиска по товарам, где пользователи набирают слова по-разному. Для русского и английского контента она не нужна, и включать ее без причины смысла нет: лишний шаг нормализации в конвейере анализа.
Authenticated backup и manticore-load через HTTP JSON API
Резервное копирование получило поддержку аутентификации. Раньше бэкап опирался на доступ к файлам и доверие к окружению, теперь создание копии можно привязать к учетным данным. Для серверов, где к Manticore подключены несколько сервисов с разными правами, это закрывает неприятный сценарий: сервис, которому разрешено только читать, больше не может выгрузить всю базу.
Утилита manticore-load теперь работает через HTTP JSON API. Практическая разница проявляется в интеграциях: скриптам и сервисам не нужен отдельный клиент для бинарного протокола, достаточно обычного HTTP-запроса с JSON-телом. Это упрощает загрузку данных из CI-пайплайнов, serverless-функций и всего, что умеет отправлять HTTP, но не умеет говорить на протоколе СУБД.
Если у вас уже написаны скрипты загрузки или резервного копирования, проверьте их перед обновлением: смена транспорта и появление аутентификации часто требуют правок в аргументах команд и в способе передачи учетных данных.
Исправления в hybrid search, KNN и других компонентах
Релиз включает исправления в нескольких чувствительных местах:
- hybrid search. Комбинирование полнотекстового и векторного ранжирования, область, где ошибки в скоринге заметны сильнее всего.
- KNN. Поиск ближайших соседей, база для векторных сценариев.
- bulk ingestion. Массовая загрузка данных.
- grouped search. Группировка результатов.
- Изменения схемы. Операции с таблицами и атрибутами.
Практический вывод простой: если вы уже используете hybrid search или KNN, обновление стоит проверить на своих данных, потому что исправления в скоринге могут изменить порядок выдачи. Точный список правок лучше сверять с официальным changelog релиза, а не с пересказами.
Миграция и обновление: что нужно сделать
Обязательной миграции данных на уровне релиза нет: формат индексов не требует переиндексации, и обновление не превращается в многочасовой простой. Но «не требует» не значит «не требует вообще ничего». Пройдитесь по списку.
- Проверьте columnar-атрибуты. Если аналитические запросы читают много столбцов, сравните поведение до и после обновления. При неприемлемом расходе памяти верните прежний режим через access_columnar_attrs='file'.
- Проверьте тексты с длинным контекстом. Если в индексе есть документы, которые раньше обрезались, решите, нужны ли чанки: включение chunked auto-embeddings меняет размер индекса и требует пересчета векторов.
- Пересмотрите значение MAX_INPUT_TOKENS. Слишком низкий лимит вместе со стратегией truncate оставит от документа только начало.
- Обновите скрипты загрузки и бэкапа. manticore-load через HTTP JSON API и authenticated backup могут потребовать других аргументов и способа передачи учетных данных.
- Проверьте схему и запросы. UTF-8 идентификаторы работают при экранировании; если в проекте есть генераторы SQL, они должны ставить обратные кавычки.
Обновляйтесь сначала на копии и на реальном объеме данных. Нагрузочные характеристики mmap и рост числа векторов на документ проявляются именно на больших индексах, а не на тестовой таблице из сотни записей.
Практические сценарии: где пригодятся новые возможности
RAG поверх длинных документов. Корпоративная база знаний из регламентов и инструкций раньше страдала от обрезки: ответ на вопрос лежал в середине документа и в вектор не попадал. Связка chunked auto-embeddings и float_vector_array ищет по фрагментам, поэтому в контекст модели попадает именно нужный абзац. Если вы считаете бюджет токенов на всем пайплайне, полезно держать в голове приемы из разбора Deep Agents v0.7: экономия на входе важна не меньше, чем качество поиска.
Поиск по научным текстам. Стратегия sentence подходит для статей, методик и патентов, где значение имеет конкретная формулировка. Запрос про метрику или метод находит предложение, где она упомянута, вместо документа целиком.
Аналитика по колоночным данным. mmap снижает стоимость повторных чтений одних и тех же столбцов, поэтому частые агрегаты по логам и метрикам выигрывают от нового режима. При редких обращениях к большим столбцам выигрыш неочевиден, и здесь стоит измерять.
Мультиязычные проекты. UTF-8 идентификаторы упрощают схему для русскоязычных каталогов, а нормализация sharp-s закрывает немецкий поиск. Чем проще схема читается человеком, тем меньше ошибок в аналитических запросах и админских скриптах.
Локальные embedding-модели на слабом железе. MAX_INPUT_TOKENS ограничивает нагрузку на CPU, и на домашнем сервере без GPU это ощутимая разница между индексацией, которая идет в фоне, и индексацией, которая занимает всю машину. При выборе самой модели пригодится подход из материала о том, как оценивать новые AI-модели без маркетингового шума, а при скачивании весов - практика из разбора huggingface_hub v1.0.
Ограничения и на что обратить внимание
У каждой новой возможности есть цена, и часть цен проявляется только на боевой нагрузке.
- Рост индекса. Несколько векторов на документ означают пропорционально больший векторный индекс и более долгую индексацию. Для больших корпусов считайте место заранее.
- mmap и виртуальная память. Потребление виртуальной памяти растет, а поведение зависит от того, помещаются ли рабочие страницы в page cache. На машине с дефицитом RAM случайные чтения по большому columnar-файлу могут уйти на диск.
- MAX_INPUT_TOKENS обрезает контекст. Лимит снижает нагрузку, но не различает важное и второстепенное. Слишком агрессивное значение ухудшает качество поиска, а не только ускоряет индексацию.
- Усреднение теряет детали. Стратегия mean оставляет один вектор на документ, поэтому многотемные документы будут находиться хуже, чем при разбиении на чанки.
- UTF-8 идентификаторы усложняют запросы. Обратные кавычки нужны везде, включая генераторы запросов и миграционные скрипты. Ошибка в экранировании ломает команду целиком.
- Изменения в скоринге. Исправления в hybrid search и KNN способны переставить выдачу. Если у вас есть эталонный набор запросов, сравните результаты до и после обновления.
Начните с одного шага: разверните 29.9.0 на копии, включите chunked auto-embeddings на реальном корпусе и замерьте три величины - размер индекса, время индексации и полноту выдачи на своих запросах. Этого набора цифр достаточно, чтобы решить, какие новые возможности стоит оставить включенными, а какие отключить настройками.