Зміст
Коротко
Команда Apex Grid описує на Dev.to, чим підкладка даних відрізняється від векторної бази в контурі відповідей із пошуком за змістом. Підкладка для них — версійований шар, на який можна послатися: яка норма, який запис і який відбиток вектора стояли за рішенням. Векторна база швидко знаходить схоже, і на цьому пояснення закінчується. У регульованих фінансах їм потрібні обидва шари, а не вибір «або-або».
Що сталося
Привід статті — їхній інструмент для мікрофінансових банків у Нігерії. Коли система позначає підозрілу операцію або заявку на кредит, фрази «модель вважає це ризикованим» недостатньо. Потрібно показати, на яку редакцію норми спирається висновок, який історичний шаблон збігся і як дані пройшли обробку. Векторний пошук за текстом і числами заявки швидко знаходить схожі випадки. Для подальшої перевірки він не зберігає родовід: немає стійкого посилання на версію правила і на вихідний запис.
Підкладку вони показують простим запитом у дусі SQL. За ідентифікатором рішення обирають версію норми, ідентифікатор вихідних даних і хеш вектора, який брав участь у пошуку. Такий запит не покращує якість моделі. Він робить рішення розбірним після того, як його вже ухвалено: аудитор відкриває рядок, а не просить заново прогнати пошук у надії отримати тих самих сусідів.
Далі — гібрид, а не заміна. Векторна база лишається першим кроком: вона швидка і доречна, щоб знайти схожі документи. Відібране переносять у підкладку, де з’являються версія і облік. Автор прямо пише про ціну: більше місця, жорсткіша схема, суворіші версії. Для нігерійського мікрофінансування помилка класифікації або рішення без сліду, за його оцінкою, дорожчі за цю метушню. Попереду вони хочуть перевірку ближче до реального часу і доступ до сліду для людей без технічного тла — поки слід є, але його ще мають уміти читати ті, хто ухвалює рішення.
Чому це важливо
У розмовах про пошук за змістом векторне сховище часто називають «базою для моделі», ніби схожість і є облік. Для внутрішнього чернетки цього вистачає. Для банку, де прапорець по операції має вказувати на норму, схожість без версії — дірка. Підкладка не робить модель точнішою. Вона відповідає на інше питання: на якій підставі це було сказано того дня.
Гібрид корисний як схема меж. Пошук живе там, де потрібні швидкість і близькість. Слід живе там, де потрібна повторна перевірка. Змішувати їх в одній «розумній базі» означає або сповільнювати пошук важким обліком, або робити вигляд, що хеш вектора вчора і сьогодні — одне й те саме, хоча норма вже змінилася.
На практиці
Текст короткий і описує один продукт, без відкритого порівняльного тесту сховищ. Запит із полями рішення, версії норми, джерела і хеша — начерк, не готова схема. Його цінність у складі полів: якщо у вашій таблиці відповіді немає версії правила і посилання на запис, сперечатися про вибір векторної бази рано.
Людям без технічного тла слід некорисний, якщо його бачить лише інженер. Автор сам ставить це наступним питанням, а не розв’язаною задачею.
- Розділіть «знайти схоже» і «пояснити, на чому стояло рішення» — це різні сховища і різні строки життя даних.
- У записі рішення тримайте версію норми, ідентифікатор джерела і відбиток вектора, а не лише текст відповіді.
- Не обіцяйте, що повторний пошук поверне тих самих сусідів: для перевірки потрібне збережене посилання, а не новий запит.
- Заздалегідь оцініть місце, схему і версії: гібрид дорожчий за чисту векторну базу, і це нормальна плата лише там, де слід обов’язковий.
- Покажіть слід тому, хто підписує рішення, а не лише команді, яка пише запит.
Підсумок
Apex Grid не скасовує векторний пошук. Вони ставлять його перед шаром, який пам’ятає норму і джерело. Для регульованої задачі це переконливіше, ніж ще один аргумент на користь «лише вектори» або «лише таблиці». Переносити схему у свій контур варто з полями сліду, а не з гаслом про підкладку.
Коментарі