Переклад моделей вбудовування 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-х років.

У цьому рішенні не використовується ітеративна оптимізація, тому немає показника швидкості навчання та не потрібно обирати кількість епох. Однакові вхідні дані завжди дають однакову трансформацію.

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

Випливає ще одна операційно важлива властивість: витрати на навчання залежать від кількості зіставлених пар, а не від розміру корпусу даних. Адаптер можна підібрати на основі кількох тисяч репрезентативних пар навіть тоді, коли індекс містить сотні тисяч записів. Трансформація повної матриці коштує приблизно стільки ж, скільки добуток двох розмірів за кожен запит, і вимагає такої ж кількості пам’яті для параметрів. Факторизація типу rank-r знижує витрати на обробку запиту до приблизно r разів суми розмірів. Як конкретний приклад, матриця розміром 768 на 768 з типом даних float32 займає близько 2,36 МБ, що є дуже малою кількістю порівняно з індексом, який можна заощадити, уникаючи його повторної створення.

Чому одного методу трансформації недостатньо

Взаємозв’язок між двома просторами ембеддингів часто нагадує ротацію, але це не стосується кожної пари моделей. Тому rebasis не припускає, що один алгоритм може працювати скрізь. Він виходить з Orthogonal Procrustes — формули з закритим виразом для оптимальної відповідності двох наборів точок. Однак реальні простори можуть мати зсуви середніх значень, відмінності у масштабі за кожним виміром та нелінійні компоненти.

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

• Procrustes у центрованих та класичних варіантах.
• Лінійний мапування з регуляризацією за допомогою рігів.
• Афінне мапування низького рангу.
• Procrustes із масштабом за кожним виміром.
• Якщо доступний PyTorch, невеликий MLP з залишковими ланцюгами.

CSLS не нав’язується через механізм мапування; він також бере участь у конкуренції як кандидат. Причина цього — практичність. У високорозмірних просторах він може полегшити проблему „хабності“ для слабких адаптерів, проте може пошкодити вже міцну відповідність. Метою є не довгий список назв алгоритмів, а переможець, обраний на основі оцінки на даних, які не використовувалися під час навчання. Коли кілька кандидатів знаходяться в одному регіоні невизначеності, інструмент віддає перевагу тому, хто має менше параметрів та нижчу вартість.

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

Асиметричні моделі ембеддингу також розглядаються окремо. Наприклад, у родині E5 префікси query: та passage: означають, що один і той самий текст кодується по-різному залежно від його ролі, а інші моделі використовують інструкції типу query або document для тієї ж мети. Якщо підібрати адаптер для пар, кодованих у форматі документа, та застосувати його до векторів, кодованих у форматі запиту, це призведе до класичної неузгодженості між процесом навчання та використанням. Саме тому профіль кодування у rebasis враховує набагато більше факторів, ніж назва моделі: розмірність, нормалізація, об’єднання даних, префікси query та document, а також будь-які додаткові параметри. Адаптер, створений за неправильним профілем, відхиляється під час завантаження, замість того щоб тихо повертати погані результати.

Як це пов’язано з попередніми дослідженнями

Забезпечення сумісності ембеддингів між різними версіями — це давня проблема. Тренування з зворотною сумісністю обмежує нову модель під час навчання, щоб її представлення залишалися порівнянними зі старими. Тренування з прямою сумісністю діє навпаки: під час навчання старої моделі готується додаткова інформація, щоб подальші оновлення були простішими. Обидва підходи підходять для великих систем пошуку, які контролюють весь життєвий цикл моделі з етапу проектування.

rebasis вирішує іншу ситуацію. Індекс вже існує, старі та нові моделі були навчені окремо, і ніхто не може втручатися у процес навчання. Це робить його постхоковим шаром сумісності. Він ґрунтується на методі Orthogonal Procrustes, трансформаціях низького рангу та сучасних розробках у сфері Drift-Adapter, а його власний внесок полягає у інженерній реалізації: об’єднанні цих ідей у один локальний інструмент, який також додає функції вимірювання, вибору адаптерів, теорії прийняття рішень, абстракцій щодо сховищ даних, безпечної міграції та робочого процесу для проведення повторюваних аудитів.

CSLS походить із літератури з алінгування міжмовних ембеддингів. Він враховує щільність локального оточення запиту та цільового об’єкта та карає вектори-„хаби“, які стають найближчими сусідами занадто багатьох запитів. Коротко кажучи, він оцінює пару як подвоєну косинусову схожість мінус показник щільності для кожної зі сторін. Експерименти з власним реальним корпусом проекту, за повідомленнями, показали, що цей підхід допомагає слабким зв’язкам, а іноді шкодить сильним, тому його вимірюють, а не застосовують сліпо.

Інструмент, який іноді радить не використовувати його

На ранніх етапах проекту питання „Чи можна побудувати міст між цими двома просторами?“ виявилося неправильним для постановки окремо. Важливішими є три питання:

1. Чи справді нова модель ембеддингів краща для цих конкретних даних?
2. Скільки від якості повного переіндексування зберігає адаптер?
3. Чи краще використовувати механізм місткування, ніж просто залишатися з поточною моделлю?

Саме тому як ключову команду пропонується probe, а не fit. Вона об’єднує вибір вибірки, вбудовування даних, створення бази істинних значень, підбір кандидатів, обчислення метрик та остаточне прийняття рішення в один процес вимірювання, причому вона ніколи не записує дані у існуючий індекс.

Одним із основних показників є ARR, Adapted Recall Retention — якість адаптованого пошуку у відсотках від того, що могло б забезпечити повне переіндексування з новою моделлю. Високий показник 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 визначає якість найрідкісніших кластерів у порівнянні з глобальним середнім значенням, тож девіації, які сильніше впливають на деякі регіони, стають помітними.

Ці відмінності мають значення. Два системи можуть повертати однакові документи у різному порядку, що неможливо виявити за допомогою показника recall, але можливо за допомогою nDCG. Так само ранжування може здаватися правильним, хоча форма розподілу балів достатньо змінюється, щоб обійти фільтр із жорстким порогом. Якщо результати, отримані на основі recall та 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 ітератори корпусу передають записи поступово, тож максимальне споживання пам’яті під час міграції дорівнює розміру пакета помноженому на розмір вектора. Час виконання зростає з кількістю записів, але корпус даних користувача ніколи не зберігається у RAM. Коли кількість використаної пам’яті наближається до значення --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 знову виконує попереднє вимірювання, щоб з’ясувати, чи виникла різниця через регресію програмного забезпечення чи через зміну корпусу даних.

Що намагається довести відкритий пакетувальний інструмент

rebasis випускається під ліцензією Apache 2.0, і його основною метою є забезпечити можливість перевірки заявлених характеристик, а також зробити код читабельним. У репозиторії ви знайдете записи про архітектурні рішення щодо ключових виборів, а також ідеальні сценарії, показники для реальних даних, бюджети продуктивності, тести для кожного бекенду, тести CLI, які виконуються повністю, та документацію для учасників розробки. Стратегія тестування охоплює не лише оптимальні сценарії, а й перевірку числової послідовності між пристроями, обмежень пам’яті, властивостей адаптерів, умов зберігання даних, а також надійності процесів міграції та скасування змін.

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

Зміни в моделях без вибору «усе або нічого»

Основна проблема полягає не у виборі технології, а у витратах на її заміну. У міру розвитку систем RAG їхні індекси стають інвестиціями в інфраструктуру, а вибір моделі ембеддингу перетворюється на рішення, яке набагато складніше скасувати, ніж це мало б бути. Ідея підходу rebasis — послабити цю взаємозв’язаність.

Коли з’являється нова модель, першим кроком має бути перевірка того, чи вона справді краща для ваших власних даних. Якщо так, то наступним кроком є з’ясування, чи можна створити надійний міст, який би поєднав її з поточним індексом. Якщо міст достатньо якісний, нову модель можна використовувати негайно. Якщо з часом потрібна повна якість, міграція може відбуватися пакетами з контролем та гарантіями скасування. А якщо міст не виправдовує очікувань, це має бути виявлено до початку дорогого експерименту в умовах реального використання, а не під час нього.

Ось простір можливих рішень, який пропонує цей інструмент: спочатку вимірювати, потім створювати містки, а за потреби — безпечно мігрувати. Це відкритий інструмент, призначений для зміцнення локальної інфраструктури RAG, зменшення обмежень у виборі моделей для інтеграції та підвищення прозорості оновлень моделей; він також відкритий для розробників, які можуть його перевірити, випробувати на реальних корпусах даних та допомогти у розробці.

Пов’язана література

• Практичні нотатки: Векторні бази даних для продакшн-систем RAG: індексування, гібридний пошук — Детальний огляд Практичних нотаток: Векторні бази даних для продакшн-систем RAG: індексування, гібридний пошук, включаючи контракти, перевірки та шаблони коду для команд, які впроваджують цю модель.
• RAG у простому Python: чанкування, TF-IDF, косинусна схожість та формулювання запитів — Створення системи генерації з підсиленням через пошук лише за допомогою модуля математики: чанкування за принципом ковзної вікна, вектори TF-IDF, ранжування за косинусом, ефективні запити та їхні обмеження.