RAG-системы врут? Проверяем источники знаний: графы против векторов

Почему RAG-системы начинают врать (и как это заметить)

Ты построил RAG-систему. Embeddings работают, ретривер находит релевантные чанки, LLM генерирует связные ответы. Все отлично на тестовых запросах. Пока не приходит пользователь с вопросом "Какие акции Tesla купить в 2026 году?" и получает ответ, основанный на финансовом отчете 2023 года. Устаревшие данные - это еще цветочки. Бывает хуже: система находит похожие по embedding'ам, но совершенно нерелевантные по смыслу документы. Или смешивает информацию из конфликтующих источников. Или цитирует внутренний меморандум как официальную политику компании.

Графы знаний vs векторные БД: где проще валидировать?

Векторные БД (Pinecone, Weaviate, Qdrant) ищут по семантическому сходству. Графы знаний (Neo4j, Amazon Neptune, ArangoDB) хранят связи между сущностями. Разные подходы - разные проблемы с валидацией.

Графы знаний выигрывают в прозрачности. Ты можешь буквально увидеть, как информация течет от источника к утверждению. В векторных БД все скрыто за многомерными векторами - черный ящик, который иногда работает, иногда нет. Если хочешь глубже разобраться в графах, посмотри этот гайд по построению графов знаний.

Метод 1: LLM как валидатор (самый дорогой и медленный)

Дать LLM проверить, релевантен ли найденный документ запросу. Звучит логично: кто лучше LLM поймет смысл текста? На практике этот метод съедает бюджеты и замедляет ответы в разы.

1 Как работает LLM-валидация

После ретривера ты получаешь N кандидатов. Вместо того чтобы сразу отправлять их в LLM для генерации ответа, ты сначала отправляешь каждый кандидат на проверку: "Насколько этот документ релевантен запросу X? Оцени от 0 до 10".

2 Проблемы с LLM-валидацией

• Стоимость: каждый дополнительный вызов LLM - деньги. При 10 кандидатах на запрос и 1000 запросов в день...
• Задержка: последовательные вызовы LLM складываются. 200ms на проверку × 10 кандидатов = +2 секунды к ответу
• Непоследовательность: LLM может по-разному оценивать один и тот же документ при повторных запросах
• Оверкиллинг: простые случаи (явная релевантность) не нуждаются в проверке LLM

И все же иногда без LLM не обойтись. Особенно когда нужно понять смысловые нюансы или проверить, не противоречит ли документ другим источникам. Просто не используй этот метод для всех запросов подряд.

Метод 2: Извлечение сущностей и проверка по графу (самый точный для графов знаний)

Если у тебя есть граф знаний, ты можешь проверять не "похожесть текстов", а наличие конкретных связей между сущностями. Это фундаментально другой подход.

1 NER + Cypher запросы

1. Извлекаешь сущности из запроса пользователя (люди, компании, даты, продукты)
2. Извлекаешь сущности из найденного документа
3. Проверяешь в графе: существуют ли связи между этими сущностями? Какие именно?

# Пример с spaCy и Neo4j
import spacy
from neo4j import GraphDatabase

# Загружаем самую свежую модель NER на 2026 год
nlp = spacy.load("en_core_web_trf")  # transformer-based, самая точная

# Извлекаем сущности из запроса
doc = nlp("Какие акции Tesla купить в 2026 году?")
entities = [(ent.text, ent.label_) for ent in doc.ents]
# [('Tesla', 'ORG'), ('2026', 'DATE')]

# Cypher запрос для проверки связей
query = """
MATCH (company:Company {name: $company_name})
MATCH (year:Year {value: $year})
OPTIONAL MATCH path = (company)-[:HAS_STOCK_DATA_IN]->(year)
RETURN company.name, year.value, 
       CASE WHEN path IS NOT NULL THEN true ELSE false END as has_data
"""

2 Проверка временных меток в графе

В графах знаний легко реализовать проверку актуальности. Просто добавь свойство `valid_from` и `valid_to` к отношениям или узлам.

// Найти актуальную информацию о Tesla на 2026 год
MATCH (tesla:Company {name: 'Tesla'})
MATCH (tesla)-[r:HAS_FINANCIAL_DATA]->(data:FinancialData)
WHERE r.valid_from <= date('2026-01-01') 
  AND (r.valid_to IS NULL OR r.valid_to >= date('2026-01-01'))
RETURN data.revenue, data.profit, r.source, r.last_verified
ORDER BY r.last_verified DESC
LIMIT 5

Проблема в том, что нужно поддерживать граф в актуальном состоянии. Если данные устарели, но не помечены как устаревшие - система все равно будет их использовать. Автоматическое обновление графов знаний - отдельная большая тема.

Метод 3: Метаданные и эвристики (самый быстрый)

Не все проверки требуют глубокого семантического анализа. Иногда достаточно посмотреть на метаданные.

• Дата документа: если запрос про "новые функции Python 3.12", а документ датирован 2022 годом - сразу отбрасываем
• Источник: внутренний черновик vs официальная документация vs проверенный внешний источник
• Уровень доверия: заранее присвоенный score для каждого источника (например, официальная docs = 1.0, форум = 0.3, блог = 0.5)
• Популярность/цитируемость: сколько других документов ссылаются на этот

Метод 4: Cross-encoder reranking (баланс скорости и точности)

Компромисс между быстрым, но неточным векторным поиском и точным, но медленным LLM-валидатором. Cross-encoder - модель, которая принимает на вход два текста (запрос и документ) и выдает score релевантности.

Как это работает в конвейере:

1. Векторный поиск находит 100 кандидатов (быстро, но неточно)
2. Cross-encoder переранжирует топ-20 кандидатов (медленнее, но точнее)
3. Только топ-3 идут в LLM для генерации ответа

from sentence_transformers import CrossEncoder

# Загружаем cross-encoder модель
# На 2026 год рекомендую "cross-encoder/ms-marco-MiniLM-L-12-v2" или более новую
model = CrossEncoder('cross-encoder/ms-marco-MiniLM-L-12-v2')

# Подготавливаем пары запрос-документ
pairs = [[query, doc] for doc in candidate_docs]

# Получаем scores релевантности
scores = model.predict(pairs)

# Сортируем документы по убыванию score
ranked_docs = [doc for _, doc in sorted(zip(scores, candidate_docs), reverse=True)]

Cross-encoder точнее, чем cosine similarity векторов, потому что видит запрос и документ вместе. Но все равно быстрее, чем полноценная LLM. Идеальный вариант для production-систем, где важны и скорость, и качество.

Специфичные проблемы векторных БД (и как их решать)

Векторные БД имеют уникальные проблемы с валидацией. Embedding'ы - это сжатое представление смысла, и при сжатии теряется прозрачность.

Решение 1: Мультимодальные эмбеддинги

Используй не только текстовые embedding'ы. Добавь:

• Тематические embedding'ы: отдельный вектор для темы документа (финансы, техника, здоровье)
• Тип документа: техническая документация, новость, форум, исследование
• Временной embedding: представление даты как вектора (помогает искать свежие документы)

Тогда при поиске можно комбинировать: "семантическое сходство + тематическое сходство + свежесть". Это снижает риск семантического дрейфа.

Решение 2: Post-retrieval фильтрация

После того как векторный поиск нашел кандидатов, прогони их через простые фильтры:

def validate_candidates(query, candidates, min_trust_score=0.5, max_age_days=365):
    validated = []
    
    for doc in candidates:
        # Проверка доверия к источнику
        if doc.metadata.get('trust_score', 0) < min_trust_score:
            continue
            
        # Проверка актуальности
        doc_date = doc.metadata.get('date')
        if doc_date:
            age = (datetime.now() - doc_date).days
            if age > max_age_days:
                continue
                
        # Проверка типа документа (если запрос требует специфичного типа)
        if 'tutorial' in query.lower() and doc.metadata.get('type') != 'tutorial':
            continue
            
        validated.append(doc)
    
    return validated

Простые правила, но они отсекают очевидно неподходящие документы до дорогостоящей проверки LLM.

Графы знаний: валидация через связи и контекст

С графами знаний другая история. Здесь валидация встроена в саму структуру данных.

Проверка через путь в графе

В графе можно спросить: "Каким путем информация из источника A дошла до утверждения B?" Если путь длинный и проходит через ненадежные узлы - это красный флаг.

// Найти все пути между источником и утверждением
MATCH path = (source:Source)-[*1..5]->(claim:Claim {text: $claim_text})
RETURN source.name, source.trust_level, 
       length(path) as path_length,
       [n IN nodes(path) WHERE n:Source | n.trust_level] as source_chain
ORDER BY path_length, 
         reduce(s = 1.0, x IN [n IN nodes(path) WHERE n:Source | n.trust_level] | s * x) DESC

Обнаружение конфликтов

Графы отлично показывают противоречия. Если один узел связан с двумя противоречивыми утверждениями - это проблема.

// Найти противоречивые утверждения о компании
MATCH (c:Company {name: 'Tesla'})
MATCH (c)-[:HAS_CLAIM]->(claim1:Claim)
MATCH (c)-[:HAS_CLAIM]->(claim2:Claim)
WHERE claim1.confidence > 0.7 
  AND claim2.confidence > 0.7
  AND claim1.text CONTAINS 'profitable'
  AND claim2.text CONTAINS 'unprofitable'
RETURN claim1.text, claim1.source, claim1.date,
       claim2.text, claim2.source, claim2.date

Векторные БД такого не умеют. Они могут найти похожие документы, но не покажут, что эти документы противоречат друг другу.

Production-ready подход: гибридная валидация

В реальных системах я использую комбинацию методов. Разные типы запросов требуют разной степени проверки.

Мой стек для production-системы в 2026:

1. Векторный поиск: находит кандидатов быстро
2. Фильтрация по метаданным: отсекает устаревшее и ненадежное
3. Cross-encoder reranking: улучшает релевантность топ-кандидатов
4. Графовая проверка (если есть граф знаний): ищет конфликты и проверяет связи
5. LLM валидация (только для критичных запросов): финальная проверка

Да, это сложнее, чем просто "закинуть документы в векторную БД и радоваться". Но именно так строятся системы, которым можно доверять. Если интересно, как RAG развивается в 2026, посмотри обзор свежих трендов и угроз.

Чего ждать в 2027? Автоматическая валидация и self-correcting RAG

Тренды, которые я вижу:

• Автоматическое обновление доверия к источникам: система учится, какие источники чаще дают правильную информацию, и автоматически корректирует trust_score
• Встроенная временная логика: RAG-системы начинают понимать временные отношения ("до", "после", "в течение") без явного указания дат
• Мультимодальная валидация: проверка не только текста, но и таблиц, изображений, схем в документах
• Self-correcting механизмы: когда система обнаруживает конфликт или устаревшую информацию, она автоматически ищет обновления или помечает данные как требующие проверки

Уже сейчас появляются системы вроде BayesRAG, которые используют байесовские сети для оценки достоверности. Вместо бинарного "доверять/не доверять" они дают вероятностную оценку.

Главное - не пытаться сделать идеальную валидацию для всех случаев сразу. Начни с самых критичных сценариев (финансы, медицина, юридические вопросы). Для остального хватит базовых проверок. И помни: любая валидация лучше, чем ее отсутствие. Даже простой фильтр по дате документа убережет пользователей от устаревшей информации. А это уже большой шаг к доверию.