rag-staleness-check ищет протухшие и «недоудалённые» векторы в RAG-базах
На GitHub опубликован rag-staleness-check, open-source-утилита командной строки, которая проверяет уже работающую векторную базу RAG (retrieval-augmented generation) на четыре типа проблем. Первая, устаревшие фрагменты (staleness): куски текста, чей исходный документ с тех пор изменился. Вторая, «осиротевшие» фрагменты (orphans): куски, чей исходный документ вообще пропал из манифеста. Третья, дубликаты: почти идентичные фрагменты по косинусному сходству (порог по умолчанию, 0.98), плюс точное сравнение по хэшу, если он хранится в базе. Четвёртая, «доступность после удаления» (retrievable-after-delete): проверка, можно ли всё ещё физически получить по id вектор, который считается удалённым, и всплывает ли он в топ-k результатах поиска.
Инструмент работает только на чтение и никогда не вызывает методы записи, удаления или обновления у движка. Это гарантируется двумя способами. Во-первых, статический тест разбирает синтаксическое дерево всего кода утилиты (не просто ищет подстроки, это дало бы ложные срабатывания на самом README) и роняет сборку, если находит вызов метода записи или SQL-запрос на запись. Во-вторых, во время работы с pgvector каждое соединение открывается с флагом только для чтения, и это дополнительно перепроверяется перед каждым запросом, защита на случай, если пул соединений вроде PgBouncer незаметно «съест» эту настройку. Для Qdrant и Chroma такой рантайм-проверки нет: клиентские библиотеки этих движков не дают способа узнать, что сессия доступна только для чтения, поэтому разработчик рекомендует полагаться на статический тест плюс собственную настройку read-only доступа со стороны развёртывания.
Инструмент поддерживает три движка, pgvector, Qdrant и Chroma, устанавливается через pip или pipx и требует Python 3.10+. Работа опирается на JSON-манифест документов (пара «id документа + дата последнего изменения»), который служит единственным источником истины о том, что считается актуальным. Без нужных полей отдельные проверки, например, на устаревание или точное совпадение дубликатов по хэшу, помечаются как пропущенные с указанием причины, а не молча показывают обманчиво чистый результат.
Телеметрии по умолчанию нет, ничего не отправляется без явного согласия пользователя; флаг для отправки анонимной сводки пока ничего не отправляет на практике, потому что серверная часть для приёма таких данных ещё не настроена. Отдельно инструмент отключает встроенную телеметрию пакета chromadb (она включена по умолчанию и основана на PostHog) при подключении к Chroma. На версии chromadb 0.6.3 это отключение всё равно вызывает безобидную, но заметную ошибку в консоли при старте, по словам автора, она ничего не значит и данные никуда не уходят.
Проверка «доступности после удаления» опирается на нормы приватности: согласно рекомендациям Европейского совета по защите данных № 05/2019, на которые ссылается документация проекта, удаление должно быть проверяемым и необратимым, если запись просто перестала выдаваться в поиске, а исходный вектор физически остался в базе, этого недостаточно.
Утилита, бесплатная, открытая и однодвижковая версия (работает с одним движком за раз) отдельного платного продукта RAGproof, который проводит мультидвижковый аудит с проверкой находок по журналу изменений git и готовит отчёты для соответствия статье 17 GDPR («право на забвение»). В открытой версии нет ни эталонных данных для расчёта точности и полноты, инструмент сообщает о находках, но не оценивает, насколько они точны, ни глубоких проверок под конкретный движок, вроде деталей VACUUM у pgvector или роста HNSW-индекса на диске у Chroma. Лицензия, Apache-2.0, код открыт для issues и pull request'ов; в планах, добавить альтернативный режим поиска дубликатов по тексту на основе minhash.
Ключевые факты
- Open-source CLI-утилита rag-staleness-check проверяет базы pgvector, Qdrant и Chroma на четыре типа проблем: устаревшие фрагменты, «осиротевшие» фрагменты, дубликаты (косинусное сходство ≥ 0.98) и векторы, доступные после удаления
- Read-only режим подтверждён статическим анализом синтаксического дерева кода и, для pgvector, дополнительной рантайм-проверкой перед каждым запросом; для Qdrant и Chroma такой рантайм-гарантии нет
- Проверки опираются на JSON-манифест документов как источник истины; без нужных данных отдельная проверка помечается пропущенной, а не показывает ложно-чистый результат
- Телеметрии по умолчанию нет; отдельно инструмент отключает собственную (PostHog-based) телеметрию пакета chromadb при подключении к Chroma
- Это бесплатная однодвижковая версия платного продукта RAGproof, который делает мультидвижковый аудит с проверкой по git-журналу и готовит отчёты под статью 17 GDPR; open-source версия не даёт оценки точности своих находок и требует Python 3.10+
Почему это важно
Векторные индексы RAG-систем со временем расходятся с исходными документами: файлы меняются или удаляются, а проиндексированные фрагменты остаются в базе как есть. Это накапливает «протухшие» и «осиротевшие» данные, которые незаметно портят качество поиска, и создаёт риск, что удалённые данные физически остаются доступными, то, что по нормам защиты данных удалением не считается. rag-staleness-check делает эту проблему видимой без отдельного аудита: он один раз просматривает уже работающую базу и показывает масштаб проблемы по каждой из четырёх категорий.
Кому это важно
Инженерам, которые поддерживают в продакшене RAG-системы на pgvector, Qdrant или Chroma и хотят регулярно проверять гигиену индекса. Командам, отвечающим за соответствие требованиям вроде статьи 17 GDPR («право на забвение»), инструмент прямо проверяет, действительно ли удалённые данные недоступны. Тем, кто готовится к более глубокому платному аудиту RAGproof и хочет сначала бесплатно оценить масштаб проблемы своими силами.
Как это применить
Инструмент устанавливается через pip или pipx (требуется Python 3.10+) с опциональными наборами зависимостей под Qdrant и Chroma. Перед запуском нужно подготовить JSON-манифест документов с id и датой последнего изменения, а для проверки удаления, список id, которые считаются удалёнными. Запуск идёт через CLI с флагами под конкретный движок (таблица и колонки для pgvector, коллекция и поля payload для Qdrant/Chroma); результат, краткая сводка в консоли и подробный JSON-файл с находками. Если нужна проверка точности находок и работа сразу с несколькими движками, для этого существует отдельный платный продукт RAGproof.
Можно ли доверять
Read-only-гарантия инструмента подкреплена реальной проверкой, а не только словами в документации: статический тест разбирает синтаксическое дерево всего кода и роняет сборку при обнаружении вызова метода записи, а для pgvector есть ещё и рантайм-проверка перед каждым запросом. Для Qdrant и Chroma такой рантайм-проверки нет, там защита держится на статическом тесте плюс на настройках доступа, которые пользователь задаёт сам. Сама документация открыто признаёт границу: инструмент сообщает о найденных проблемах, но не оценивает точность и полноту находок, эталонных данных для такой оценки на стороне клиента просто нет.
Риски и подводные камни
Без корректно настроенного read-only доступа защита на Qdrant и Chroma слабее, чем на pgvector, где есть дополнительная рантайм-проверка. Точное обнаружение дубликатов по хэшу работает только если такой хэш вообще хранится в базе, иначе используется лишь приблизительное косинусное сравнение. На chromadb версии 0.6.3 при отключении телеметрии в консоли вылезает безобидная, но пугающая на вид ошибка. И главное ограничение, инструмент только сообщает о находках, не проверяя, сколько среди них ложных срабатываний или пропусков: для такой проверки нужен уже платный аудит RAGproof с внешним эталонным журналом.
«Это инструмент только для чтения, он никогда не вызывает методы записи, удаления или обновления у вашего движка.»
— документация rag-staleness-check