Содержание
Коротко
Команда Apex Grid описывает на Dev.to, чем подложка данных отличается от векторной базы в контуре ответов с поиском по смыслу. Подложка для них — версионированный слой, на который можно сослаться: какая норма, какая запись и какой отпечаток вектора стояли за решением. Векторная база быстро находит похожее и на этом объяснение заканчивается. В регулируемых финансах им нужны оба слоя, а не выбор «или-или».
Что произошло
Повод статьи — их инструмент для микрофинансовых банков в Нигерии. Когда система помечает подозрительную операцию или заявку на кредит, фразы «модель считает это рискованным» недостаточно. Нужно показать, на какую редакцию нормы опирается вывод, какой исторический шаблон совпал и как данные прошли обработку. Векторный поиск по тексту и числам заявки быстро находит похожие случаи. Для последующей проверки он не хранит родословную: нет устойчивой ссылки на версию правила и на исходную запись.
Подложку они показывают простым запросом в духе SQL. По идентификатору решения выбирают версию нормы, идентификатор исходных данных и хеш вектора, который участвовал в поиске. Такой запрос не улучшает качество модели. Он делает решение разбираемым после того, как оно уже принято: аудитор открывает строку, а не просит заново прогнать поиск в надежде получить те же соседей.
Дальше — гибрид, а не замена. Векторная база остаётся первым шагом: она быстрая и уместна, чтобы найти похожие документы. Отобранное переносят в подложку, где появляются версия и учёт. Автор прямо пишет о цене: больше места, жёстче схема, строже версии. Для нигерийского микрофинансирования ошибка классификации или решение без следа, по его оценке, дороже этой возни. Впереди они хотят проверку ближе к реальному времени и доступ к следу для людей без технического фона — пока след есть, но его ещё должны уметь читать те, кто принимает решение.
Почему это важно
В разговорах про поиск по смыслу векторное хранилище часто называют «базой для модели», как будто похожесть и есть учёт. Для внутреннего черновика этого хватает. Для банка, где флаг по операции должен указывать на норму, похожесть без версии — дыра. Подложка не делает модель точнее. Она отвечает на другой вопрос: на каком основании это было сказано в тот день.
Гибрид полезен как схема границ. Поиск живёт там, где нужна скорость и близость. След живёт там, где нужна повторная проверка. Смешивать их в одной «умной базе» значит либо замедлять поиск тяжёлым учётом, либо делать вид, что хеш вектора вчера и сегодня — одно и то же, хотя норма уже сменилась.
На практике
Текст короткий и описывает один продукт, без открытого сравнительного теста хранилищ. Запрос с полями решения, версии нормы, источника и хеша — набросок, не готовая схема. Его ценность в составе полей: если в вашей таблице ответа нет версии правила и ссылки на запись, спорить о выборе векторной базы рано.
Людям без технического фона след бесполезен, если его видит только инженер. Автор сам ставит это следующим вопросом, а не решённой задачей.
- Разделите «найти похожее» и «объяснить, на чём стояло решение» — это разные хранилища и разные сроки жизни данных.
- В записи решения держите версию нормы, идентификатор источника и отпечаток вектора, а не только текст ответа.
- Не обещайте, что повторный поиск вернёт тех же соседей: для проверки нужна сохранённая ссылка, а не новый запрос.
- Заранее оцените место, схему и версии: гибрид дороже чистой векторной базы, и это нормальная плата только там, где след обязателен.
- Покажите след тому, кто подписывает решение, а не только команде, которая пишет запрос.
Итог
Apex Grid не отменяет векторный поиск. Они ставят его перед слоем, который помнит норму и источник. Для регулируемой задачи это убедительнее, чем ещё один аргумент в пользу «только векторы» или «только таблицы». Переносить схему в свой контур стоит с полями следа, а не с лозунгом про подложку.
Комментарии