Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
PILLAR позволяет искать контекст для RAG в чужом корпусе, не раскрывая серверу ни слова запроса, ни последовательность обращений к данным. В препринте Arizona State University и George Mason University, который не прошёл рецензирование и где все числа получены самими авторами, быстрый вариант обработал запрос почти втрое быстрее PACMANN. Для систем с чувствительными запросами это добавляет в архитектурный выбор промежуточный вариант между обычным облачным RAG и размещением всего контура внутри своей инфраструктуры.
Почему приватный поиск по векторам требует лишних обращений
Обычный RAG отправляет запрос серверу, который хранит документы, находит подходящие фрагменты и передаёт их LLM. В медицинском, юридическом или корпоративном поиске сам запрос может содержать сведения, которые нельзя показывать владельцу корпуса.
Частное извлечение информации (PIR) позволяет запросить элемент по индексу так, чтобы сервер не узнал, какой именно элемент выбрал клиент. Но RAG начинает не с готового индекса документа: система должна определить его по тексту запроса.
Предыдущие схемы, включая PACMANN, решают эту задачу через плотный поиск по векторам. Документы образуют граф, а алгоритм идёт по нему к векторам, которые ближе к запросу по смыслу. Следующий переход зависит от предыдущего результата, поэтому последовательность узлов может раскрыть запрос.
Чтобы скрыть эту последовательность, приватная схема заранее фиксирует длину обхода и выполняет одинаковый объём работы для разных запросов. PACMANN использует 20 сетевых обменов и получает на MS MARCO значение MRR@10 0,266 против примерно 0,31 у неприватного поиска на тех же векторах. MRR@10 показывает, насколько близко к началу первой десятки оказался правильный документ.
Проблема здесь не в самом шифровании, а в адаптивном поиске: серверу приходится скрывать и выбранные узлы, и момент остановки. Чем больше фиксированный запас шагов, тем выше задержка; чем он меньше, тем выше риск пропустить нужный документ.
Как PILLAR разделяет отбор по словам и ранжирование по смыслу
PILLAR сначала сокращает корпус с помощью BM25 — лексической оценки, которая ищет совпадающие слова и придаёт больший вес редким терминам. Для этого сервер заранее строит инвертированный индекс: для каждого термина хранит список документов, где тот встречается, вместе с рассчитанными оценками.
Клиент приватно получает небольшой фиксированный набор таких списков. Сервер видит одинаковое число запросов и одинаковые размеры сообщений, но не узнаёт термины и выбранные документы. Затем клиент запрашивает векторы только для отобранных кандидатов и сам ранжирует их по смысловой близости.
Это не смешивание двух оценок в одной формуле. Лексический этап работает как фильтр, а плотный поиск определяет итоговый порядок. Так PILLAR сохраняет точные совпадения для названий, кодов и отраслевых терминов, но не ограничивает результат документами с теми же словами.
PILLAR-Bin складывает списки документов в хеш-таблицу и получает их за один сетевой обмен. Клиент принимает больше лишних кандидатов из-за совпадений в ячейках, зато задержка остаётся низкой и предсказуемой.
PILLAR-Tree разбивает корпус на блоки и хранит для каждого верхнюю границу оценки BM25. Дерево помогает отбрасывать группы документов, которые не могут попасть в лучшие результаты. Приватный обход требует нескольких этапов, но сокращает набор перед локальным ранжированием и повышает качество.
Обе схемы рассчитаны на публично известный корпус и скрывают запрос, а не содержание документов. Доказательство конфиденциальности относится к серверу, который соблюдает протокол, но пытается извлечь сведения из полученных сообщений.
Когда PILLAR меняет архитектурный выбор
Схемы проверяли на MS MARCO и SciFact, сравнивая с PACMANN. Оценка охватывала не только позицию правильного документа, но и ответы LLM: поддерживает ли найденный контекст утверждения модели и отвечает ли результат на исходный запрос. Это позволяет отличить формально удачный поиск от контекста, который действительно помогает генерации.
PILLAR-Bin обработал запрос к MS MARCO за 0,098 секунды, тогда как самая быстрая конфигурация PACMANN потребовала 0,293 секунды. Среди конфигураций, где нельзя улучшить качество без роста задержки, на PILLAR пришлось 93% вариантов.
PILLAR-Tree показал релевантность ответа 0,75 против 0,72 у лучшей конфигурации PACMANN по качеству, причём PACMANN потребовалось более чем вдвое больше времени. Bin поэтому подходит как исходная конфигурация для интерактивного поиска, а Tree — когда качество контекста важнее минимальной задержки.
Работа меняет планы прежде всего там, где корпус можно считать публичным, а запросы нельзя передавать его владельцу: при поиске по нормативным документам, открытым исследованиям или внешним базам знаний. Вместо переноса всего корпуса и LLM внутрь закрытого контура можно оставить документы у внешнего поставщика, а чувствительную часть поиска выполнить на клиенте.
Платой становится более сложный клиент: он хранит состояние после предварительной подготовки, получает кандидатов, загружает их векторы и выполняет итоговое ранжирование. При проверке на своём корпусе первым параметром стоит подбирать число кандидатов после лексического этапа — именно этот этап сильнее всего менял задержку PILLAR-Tree на крупном наборе.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
