Переключение моделей вкладки RAG без переиндексации: как работает rebasis

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

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

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

Почему модель эмбеддингов «закрепляется»

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

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

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

Преобразуйте запрос, а не индекс

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

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

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

from rebasis import Bridge

Затем загружаем адаптер и помещаем его в путь запроса:

bridge = Bridge.load("adapters/minilm-to-bge.rbs")query_vector = new_model.encode(["how do I deploy to production?"])
query_vector = bridge.to_index_space(query_vector)
results = collection.query(query_embeddings=query_vector, n_results=10)

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

Математика, лежащая в основе стандартного адаптера

Обозначим старую модель вжимания как f_old, а новую — как f_new, и возьмем n документов, закодированных с помощью обеих моделей. Это даёт две матрицы данных, по одной в каждом пространстве. Цель состоит в том, чтобы выучить функцию, переводящую векторы из нового пространства в старое; в своей общей форме задача обучения минимизирует расстояние по норме Фробениуса между отображёнными новыми векторами и старыми векторами.

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

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

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

Из этого следует одно важное с точки зрения практического применения свойство: стоимость обучения зависит от количества совпадающих пар, а не от размера корпуса. Адаптер можно подобрать на основе нескольких тысяч репрезентативных пар даже тогда, когда индекс содержит сотни тысяч записей. Преобразование с использованием полной матрицы требует ресурсов, пропорциональных произведению двух размеров матрицы за каждый запрос, и занимает столько же памяти для хранения параметров. Факторизация по рангу снижает стоимость обработки запроса примерно до r раз размера суммы размеров матрицы. Для наглядности: матрица размером 768 на 768 с типом данных float32 занимает около 2,36 МБ, что крайне мало по сравнению с ресурсами, которые экономятся за счёт отказа от повторной разработки индекса.

Почему одного метода преобразования недостаточно

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

При использовании параметра --method auto инструмент применяет несколько кандидатских алгоритмов к одному и тому же набору данных с одинаковой предварительной обработкой, а затем сравнивает их:

• Прокрустес в центрированной и классической версиях.
• Линейное преобразование с регуляризацией по методу рёбер.
• Аффинное преобразование низкого ранга.
• Прокрустес с учётом масштаба по осям.
• При наличии PyTorch — небольшая сеть MLP с остаточным выходом.

CSLS не навязывается в процессе маппинга; он также соревнуется как один из кандидатов. Причина в практичности: в высокомерных пространствах он может снизить проблему «центральности» у слабых адаптеров, но при этом повредить уже хорошо сформированной выравниваемости. Цель не в длинном списке названий алгоритмов, а в выборе победителя на основе измерений на отдельных данных. Когда несколько кандидатов находятся в одном и том же регионе неопределенности, инструмент отдает предпочтение тому, у кого меньше параметров и ниже стоимость.

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

Асимметричные модели вкладки также рассматриваются отдельно. Например, в семействе E5 префиксы query: и passage: означают, что один и тот же текст кодируется по-разному в зависимости от его роли, а другие модели используют инструкции типа query или document для той же цели. Если адаптер настроить на пары с документной кодировкой и применить его к векторам с кодировкой query, это приведёт к классическому несоответствию между этапами обучения и использования модели. По этой причине профиль кодировки в rebasis учитывает гораздо больше факторов, чем просто название модели: размерность, нормализация, методы агрегации, префиксы query и document, а также любые дополнительные параметры. Адаптер, созданный с использованием неверного профиля, отклоняется при загрузке, вместо того чтобы тихо выдавать плохие результаты.

Как это связано с предыдущими исследованиями

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

rebasis решает другую ситуацию. Индекс уже существует, старая и новая модели были обучены отдельно, и никто не может вмешиваться ни в один из процессов обучения. Поэтому это постхоковый слой совместимости. Он опирается на метод Orthogonal Procrustes, преобразования низкого ранга и более новые исследования в области Drift-Adapter; его собственный вклад заключается в инженерной реализации: объединении этих идей в один локальный инструмент, который также включает функции измерения, выбора адаптеров, теории принятия решений, абстракций для хранения данных, безопасной миграции и рабочий процесс для проведения воспроизводимых аудитов.

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

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

На ранних этапах проекта вопрос «Можно ли построить мост между этими двумя пространствами?» оказался неправильным в своей формулировке. Более важны три вопроса:

1. Действительно ли новая модель эмбеддингов лучше работает с этими конкретными данными?
2. Насколько качество полной периндексации сохраняется адаптером?
3. Является ли использование мостового решения лучшим вариантом по сравнению с простым использованием текущей модели?

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

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

Следовательно, решение зависит от показателя точки безубыточности:

bridge_advantage = ARR × upgrade_gain

При записи логика становится более понятной. Пусть Ra обозначает Recall@k для адаптированной системы, Rn — для системы, полностью периндексированной с использованием новой модели, а Ro — для текущей старой системы. Тогда ARR представляет собой отношение преимуществ адаптированной системы по сравнению со старой к преимуществам полного периндексирования по сравнению со старой, а преимущество обновления — это отношение Rn к Ro. Если умножить их, члены, содержащие Rn, отменяют друг друга, в результате чего остается Ra деленное на Ro: адаптированная система сравнивается непосредственно с реальной альтернативой пользователя — отсутствием действий.

Каждый показатель отвечает на простой вопрос. ARR показывает, сколько из идеального реиндексирования было сохранено. Показатель улучшения после обновления указывает на степень превосходства новой модели. Их произведение показывает, действительно ли переход на новую модель способствует прогрессу. Значение выше 1 означает, что переход на новую модель лучше, чем оставаться на текущей; значение ниже 1 — наоборот. Когда значение слишком близко к пороговому уровню, инструмент не может гарантировать точность результата. В таком случае результат отмечается как неоднозначный, и рекомендуется использовать более крупную выборку.

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

Набор показателей, а не одна цифра

Recall@k является основным критерием принятия решений, но качество поиска не сводится к одному числу. Одна процедура probe генерирует несколько взаимодополняющих друг друга показателей:

• MRR@k показывает, на какой высокой позиции находится первый релевантный результат.
• nDCG@k учитывает одновременно степень релевантности и позицию в рейтинге.
• Top-k overlap показывает, сколько элементов из набора результатов оригинального поиска сохраняется в адаптированном наборе.
• Spearman correlation отражает степень нарушения внутреннего порядка совпадающих результатов.
• Kolmogorov-Smirnov distance измеряет, насколько калибровка влияет на распределение значений сходства.
• Tail ARR определяет качество наименее плотных кластеров по отношению к глобальному среднему, тем самым выявляя смещения, которые сильнее влияют на некоторые регионы.

Эти различия имеют значение. Два системы могут возвращать одни и те же документы в разном порядке, чего не может заметить показатель воспроизводимости, но может — nDCG. Аналогично, рейтинг может казаться нормальным, в то время как форма распределения баллов изменяется настолько, что это приводит к неудаче фильтра с жестким порогом. Если результаты, основанные на воспроизводимости и nDCG, не совпадают, инструмент rebasis сообщает об этом несоответствии и не заменяет один показатель другим без указания.

Неопределенность должна отражаться в результатах

Значение ARR, рассчитанное для образца, является оценкой в точке, поэтому инструмент определяет 95%-й диапазон доверия на основе 2 000 пересэмплирований с использованием метода Эфрона. На уровне доказательств T1 значение ARR представляет собой отношение двух средних значений. Независимое пересэмплирование числителя и знаменателя нарушило бы их статистическую зависимость, поэтому при использовании способа парных отношений для пересэмплирования применяются одни и те же индексы запросов для обоих элементов. Границы диапазона соответствуют 2,5-му и 97,5-му процентилям полученного распределения.

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

В проекте говорится, что метод измерения напрямую определил направление его развития. Согласно опубликованному отчету, были сравнены старая модель, простая замена моделей, адаптированный способ поиска и полная периндексация на идентичных наборах запросов в 11 корпусах, включающих 398 010 документов и 10 346 реальных запросов пользователей. Для оценки релевантности использовались суждения людей, а основные результаты оценивались независимо с помощью индекса ranx, а не только с использованием собственных метрик инструмента. Согласно этим данным, простая замена моделей сохраняла примерно 12,5% качества полной периндексации, тогда как адаптированный подход сохранял около 71% качества, что в 6,4 раза превышает показатели простой замены.

Более значимым результатом является то, что метод сопоставления не срабатывал правильно во всех случаях. Он действительно оправдал себя лишь в 12 из 62 измеренных пар моделей и корпусов. Правило принятия решений указывало правильное направление в 61 из 62 случаев, включая 32 из 33 случаев с корпусами, которые он ранее не видел до фиксации правила. Инструмент заслуживает доверия, когда он говорит «переиндексируйте здесь» или «вам не нужно это обновление», если это честный ответ, а также когда он говорит «используйте меня».

Полный процесс работы в командной строке

rebasis — это не просто функция библиотеки. Его интерфейс командной строки превращает изменение модели в управляемый процесс. Он начинается с проверки среды и определения того, какие хранилища и инструменты встраивания доступны:

# Inspect the environment and available store/embedder support
rebasis doctor

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

# Measure first and choose the right path
rebasis probe --store chroma:///path/to/db#notes \
  --old sentence-transformers/all-MiniLM-L6-v2 \
  --new BAAI/bge-base-en-v1.5 \
  --queries queries.jsonl --sample 10000 --report report.html# Fit the appropriate adapter
rebasis fit --store chroma:///path/to/db#notes \
  --old sentence-transformers/all-MiniLM-L6-v2 \
  --new BAAI/bge-base-en-v1.5 \
  --method auto --pairs 4000 \
  --out adapters/minilm-to-bge.rbs# When ready, migrate the index in background batches
rebasis migrate --adapter adapters/minilm-to-bge.rbs \
  --store chroma:///path/to/db#notes --priority access --limit 5000

Результатом работы адаптера .rbs является не только информация о весах. В его манифесте указаны идентификаторы старых и новых моделей, размерности векторов, направления и отпечатки профилей кодирования. Тензоры хранятся в формате safetensors, а также передаются результаты калибровки оценок и сами оценки. Следовательно, адаптер представляет собой портативную, проверяемую запись о том, какие модели и условия его сформировали, причем хэши тензоров можно пересчитать для подтверждения их целостности.

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

Поведение при вычислениях и использовании памяти

Инструмент, который теоретически не должен загружать весь корпус в память, всё равно может случайно это сделать. В rebasis итераторы корпуса передают записи постепенно, поэтому максимальное использование памяти во время миграции соответствует размеру пакета умноженному на размер вектора. Время выполнения растёт с увеличением количества записей, но корпус пользователя никогда не загружается в оперативную память. Когда объём памяти приближается к пределу, заданному параметром --max-memory, размер пакета может уменьшиться, и задача с сохранением состояния может быть приостановлена вместо того, чтобы быть прервана.

Матрица сходства, используемая для поиска по эталонным данным и запросов в зависимости от размера выборки, также не строится полностью. Запросы обрабатываются пакетами. Каждый пакет выполняет умножение матриц, извлекает топ-k результатов и удаляет промежуточную матрицу оценок. Полный сортировочный процесс потребовал бы S log S операций на строку. Использование функции argpartition позволяет сохранить ожидаемую стоимость выборки на строку в линейной зависимости от S. Для нормализованных векторов типа float32 поиск по косинусу сводится к одному умножению матриц, что позволяет контролировать как объем памяти, так и различия между платформами, связанные с типом данных.

В этом проекте центральный процессор является основным элементом обработки, а не вспомогательным решением второго сорта. Графический процессор может значительно ускорить генерацию эмбеддингов, но передача данных между устройствами может свести на нет этот эффект при выполнении небольшой операции адаптера для одного запроса. Тесты на эквивалентность устройств сравнивают допуски к результатам, а также полученные наборы соседних элементов, и, что самое важное, проверяют, приводят ли идентичные данные к одинаковому итоговому решению. Небольшая числовая разница, из-за которой показатель ARR превышает порог в 0,95, не считается допустимой вариацией аппаратного обеспечения; это считается дефектом в работе продукта.

Миграция, устойчивая к прерываниям

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

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

Механизм миграции основан на четырех неизменных принципах:

1. Перед изменением записи в резервном хранилище должен существовать оригинальный вектор типа float32.
2. Пробная выборка после записи для каждой завершенной партии должна быть читаемой в пределах допустимых отклонений.
3. Завершенная задача должна быть проверена снова после повторного открытия хранилища через новое соединение.

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

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

Очередь миграции одновременно выполняет функцию точки контроля, поэтому параметр --resume позволяет продолжить работу с последней завершенной группой записей. Инструмент может отслеживать нагрузку на память и состояние аккумулятора, а журнал доступов может располагать наиболее часто запрашиваемые записи в начале списка. Если результат оказывается неудовлетворительным, функция rollback восстанавливает оригинальные данные из теневой копии. Контракты, совместимые с различными бэкендами (Chroma, LanceDB, sqlite-vec, Qdrant, FAISS и внутренняя памятная версия), обеспечивают единообразие смысла этих операций во всех системах.

Плагины для различных стеков

Local RAG не основан на одной конкретной векторной базе данных или поставщике эмбеддингов, поэтому хранение данных и генерация эмбеддингов осуществляются через реестры на основе плагинов. Поддерживаемые хранилища: Chroma, LanceDB, sqlite-vec, Qdrant и FAISS, а также бэкенд, работающий в памяти. Для генерации эмбеддингов используются sentence-transformers, fastembed, Ollama, API, совместимые с OpenAI, llama.cpp и заранее вычисленные векторы.

Основная версия приложения предназначена для работы без PyTorch. Основные функции probe, метод Procrustes fitting и логика принятия решений реализованы с использованием NumPy, SciPy и scikit-learn, а тяжелые или специфичные для платформы зависимости устанавливаются только теми, кто в этом нуждается. Пакеты от сторонних разработчиков могут предоставлять точку входа rebasis.stores или rebasis.embedders для интеграции без необходимости модификации проекта.

Конфиденциальность, логирование и воспроизводимость

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

Каждое решение может быть зарегистрировано в журнале аудита с возможностью только добавления новых записей, что обеспечивает воспроизводимость процессов. В записи хранятся идентификаторы моделей, отпечатки профилей, метод выборки, начальные значения, пороги, версия метрик, версия rebasis и детали среды. Записи связаны между собой с помощью цепочки хэшей, что позволяет обнаруживать последующие повреждения или частичные изменения. Команда rebasis audit replay перезапускает предыдущее измерение, чтобы выяснить, вызвана ли разница регрессией программного обеспечения или изменением набора данных.

Что стремится доказать open-source пакетирование

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

Пайплайн CI поддерживает Python 3.12 и 3.13 как на Linux, так и на macOS — двух системах с различной семантикой хранения данных. Для минимально необходимых версий зависимостей предусмотрен отдельный этап обработки, а отдельная задача проверяет, что такие дополнительные компоненты, как PyTorch или OpenTelemetry, не попадают в основной пакет. Проверка типов осуществляется с помощью mypy --strict, качество кода контролируется инструментом Ruff, границы слоев — import-linter, а ссылки на документацию — MkDocs в строгом режиме. Суть всего этого заключается в том, что доверие к open-source проектам зависит скорее от наличия конкретных тестов и измерений, подтверждающих заявления, чем от крупных утверждений в README-файле.

Изменения в моделях без принципа «всё или ничего»

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

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

Именно такой диапазон возможных решений предлагает это инструмент: сначала провести измерения, затем создать мостовое решение, а при необходимости безопасно мигрировать. Это открытый инструмент, предназначенный для укрепления локальной инфраструктуры RAG, снижения строгости требований к выбору встраиваемых моделей и повышения прозрачности процессов их обновления; он открыт для разработчиков, которые могут его изучить, протестировать на реальных корпусах данных и помочь в его совершенствовании.