PII в векторном индексе: почему удаление исходника недостаточно — не изолированный приём, а решение внутри связанного конвейера данных, retrieval (поиск контекста), генерации и контроля качества. Ниже — способ проверить его на собственном корпусе.
Начните с наблюдаемой проблемы
Зафиксируйте реальные вопросы пользователей, ожидаемые источники и тип ошибки. Не меняйте одновременно модель, chunking (разбиение на чанки), индекс и промпт: тогда улучшение невозможно объяснить и воспроизвести.
Разложите RAG по этапам
Для каждого этапа сохраните версию конфигурации и технические сигналы. Финальный ответ без retrieved chunks (чанки) недостаточен для диагностики.
Минимальный эксперимент
- Отберите 50–100 вопросов разных типов.
- Укажите релевантные документы и допустимые ответы.
- Запустите простую baseline.
- Измените один компонент.
- Сравните retrieval (поиск контекста), groundedness, latency и стоимость.
Какие данные записывать
| Сигнал | Зачем |
|---|---|
| query и его преобразования | понимать, что реально искала система |
| document/chunk (фрагмент) ids и scores | отделять retrieval (поиск контекста) от генерации |
| prompt и model version | воспроизводить ответ |
| citations и отказ | контролировать groundedness |
| latency и cost | связывать качество с эксплуатацией |
Типичные ошибки
- оценка на демонстрационных вопросах разработчика
- смешение старых и новых версий документов
- права доступа проверяются после retrieval (поиск контекста)
- успех измеряется красотой формулировки
- нет набора для регрессии после обновления индекса
Критерий готовности
Решение готово к следующему этапу, если команда может объяснить источник ответа, воспроизвести результат на фиксированной версии, показать отсутствие утечки прав и связать качество с бизнес‑метрикой. Иначе это полезный эксперимент, но ещё не production (промышленная эксплуатация).