TL;DR
SPAR — архитектурное решение для корпоративных RAG-систем, работающих с legacy файловыми системами. Вместо создания огромной векторной базы данных, которая зеркалирует всю файловую систему, SPAR строит лёгкий индекс метаданных с тегами, а затем для каждой задачи создаёт временную векторную БД только из релевантных файлов. Система вводит концепцию Workspaces — тематических окружений, где каждый проект получает свою узкую базу знаний.
Обычные RAG-пипелайны в корпорациях страдают от трёх проблем: (1) построение глобальной векторной БД требует огромных ресурсов, (2) непрерывная синхронизация с файловой системой создаёт накладные расходы, (3) поиск по большой БД неэффективен и даёт нерелевантные результаты. Например, запрос про квартальную выручку 2019 года может вернуть документы про "квартальную выручку" из других лет, потому что система не умеет фильтровать по метаданным до векторного поиска.
SPAR решает это через двухступенчатую архитектуру: сначала система фильтрует файлы по тегам и метаданным (дата, тип, отдел), затем строит временную векторную БД только из подходящих файлов. Когда задача завершена — временная БД удаляется. Это сокращает вычислительные затраты, ускоряет поиск и повышает точность результатов.
Схема метода
ЭТАП 1: Разовая подготовка (для системных администраторов)
├─ Создать Metadata Index: таблица файлов + иерархия тегов
├─ Назначить теги файлам (вручную, через LLM или полуавтоматически)
└─ Настроить метаданные (дата, формат, отдел, тип документа)
ЭТАП 2: Работа в сессии (для пользователей)
├─ Создать Workspace для задачи
├─ Запрос пользователя → система извлекает ключевые слова + метаданные
├─ Фильтрация файлов по тегам + метаданным (до векторизации!)
├─ Построение временной векторной БД только из релевантных файлов
├─ RAG-операции внутри узкой БД
└─ Удаление временной БД после завершения задачи
⚠️ Это системная архитектура, требует код/инфраструктуру для реализации.
Зачем это нужно
Для архитекторов корпоративных RAG-систем
Проблема: Финансовая компания хранит 20 лет отчётов в разных форматах. Аналитик спрашивает: "Суммируй рост выручки во втором квартале 2019". Обычный RAG индексирует ВСЕ документы в одну векторную БД, поиск возвращает документы про "квартальную выручку" и "второй квартал" из разных лет, потому что семантическое сходство не учитывает временные границы.
Решение SPAR: 1. Метаданные (год, квартал, тип отчёта) становятся фильтрами первого уровня 2. Теги (финансы → выручка → квартальная отчётность) сужают область 3. Временная БД строится только из документов Q2 2019 4. Векторный поиск работает на 10-20 документах вместо 10 000
Выгода: Меньше ресурсов, точнее результаты, прозрачнее логика отбора.
Принципы для пользователей чатов (ограниченная применимость)
Extractable принцип: Фильтруй метаданными ДО глубокого анализа.
Аналогия в чате: Вместо "вот 50 PDF, найди информацию про проект X" → Сначала: "Покажи список файлов с названиями и датами. Я выберу нужные." → Потом: "Анализируй только эти 5 файлов."
Ограничение: Это базовая практика работы с файлами, не уникальный инсайт.
Почему это работает (техническая механика)
Слабость обычного RAG: Глобальная векторная БД смешивает всё в одно пространство. Семантическое сходство не понимает структурных границ — год, департамент, тип документа. Чем больше БД, тем больше "шума" в результатах.
Сильная сторона фильтрации: Метаданные (дата, отдел, формат) — это точные критерии, не требующие интерпретации. Теги (иерархия категорий) — это структурированное знание, отражающее логику организации. Эти данные известны ДО векторизации и не требуют нейросетей для понимания.
Как SPAR использует это: Система строит лёгкий индекс метаданных + тегов (килобайты вместо гигабайтов векторов). При запросе сначала срабатывает точная фильтрация по тегам и метаданным, которая отсекает 90-99% файлов. Только после этого система векторизует оставшиеся 1-10% и строит временную БД для задачи. Векторный поиск работает на узком, релевантном подмножестве — это быстрее и точнее.
Аналогия: Вместо того чтобы искать иголку в стоге сена через магнит (векторный поиск по всему), SPAR сначала просеивает сено через сито (фильтры метаданных), оставляя горстку, и только потом применяет магнит.
Иерархия тегов: Если пользователь спрашивает про "неврологию", система автоматически включает все подкатегории (ЭЭГ, МРТ мозга, когнитивные тесты), не требуя перечисления. Если выбран родительский тег — все дочерние подтягиваются неявно. Это решает проблему "не знаю точный термин".
Ограничения
⚠️ Требует инфраструктуру: SPAR — не промпт-техника, а системная архитектура. Нужно написать код для построения индекса метаданных, интеграции с файловой системой, управления временными БД. Не работает в ChatGPT/Claude чатах.
⚠️ Разовая работа с тегами: Назначение тегов файлам — трудоёмкий процесс. Хотя можно использовать LLM для автоматизации, требуется проверка и настройка иерархии. Для систем с миллионами файлов это серьёзный начальный барьер.
⚠️ Ценность только для больших корпусов: Если у вас 50-100 файлов, проще загрузить всё в чат или построить простую векторную БД. SPAR окупается на десятках тысяч файлов, где глобальная индексация становится узким местом.
⚠️ Extractable принципы слабые: Идеи "фильтруй метаданными сначала" и "создавай отдельные контексты для задач" — это базовые практики, не новые техники. Для обычных пользователей чатов ценность минимальна.
Ресурсы
SPAR: Session-based Pipeline for Adaptive Retrieval on Legacy File Systems Duy A. Nguyen, Minh Doan, Hai H. Do, Minh N. Do University of Illinois at Urbana-Champaign, GlaxoSmithKline