Knowledge graph в RAG

Knowledge graph в RAG использует доменную онтологию и проверенные связи как управляемый слой знаний, не заменяя первичные документы. Это отдельный контракт с измеримыми входами, выходами и условиями отказа. Сначала команда фиксирует типы запросов, доступные источники, требуемые доказательства и допустимую задержку, и только затем выбирает модель или библиотеку.

Поскольку граф отвечает за явные отношения между сущностями, retrieval должен возвращать не только текст, но и тип связи с доказательством происхождения. Генератор не должен превращать слабый или косвенный edge в категоричный факт. Это особенно важно для зависимостей, ownership, совместимости и причинно-следственных утверждений.

Практический поток выглядит так: entity linker сопоставляет запрос с каноническими узлами, traversal находит допустимые пути, а text retrieval добавляет цитируемые доказательства для найденных утверждений. Контракт должен содержать stable request ID, версии конфигурации, confidence или причину fallback и достаточно provenance для воспроизведения результата. Текст без идентификаторов источников нельзя считать полным retrieval-выходом.

Для knowledge-graph RAG полезен стабильный контракт: canonical entity ID, relation type, source document, validFrom, validUntil и confidence. Текстовый индекс может часто перестраиваться, но эти идентичности должны оставаться воспроизводимыми. Тогда entity resolution, relation retrieval и итоговый evidence bundle можно тестировать отдельно.

Knowledge graph имеет смысл строить, когда стабильная схема и relations дают бизнес-ценность; сложная онтология не нужна для корпуса независимых справочных страниц. Рядом следует сохранять сильный простой baseline, потому что дополнительная сложность оправдана только измеренным улучшением. Router может учитывать тип запроса, риск, ожидаемое число доказательств и latency budget.

Если у одной сущности несколько несовместимых relation paths, система не должна молча выбирать самый удобный. Нужно показать конфликт, применить временной или source-priority filter и при недостатке evidence завершить ответ с явным ограничением. Так ошибки графа становятся видны до того, как превратятся в убедительную галлюцинацию.

Главный риск — ошибочный entity resolution объединяет разные объекты, а отсутствие temporal qualifiers превращает историческую связь в якобы действующую. Более длинный system prompt это не исправляет: нужны детерминированные constraints, негативные тесты и разделение недоверенных данных от управляющих инструкций. Любой автоматический fallback должен быть видим в trace и не расширять права или источники.

Release-тесты для knowledge graph включают дубликаты сущностей, alias collisions, orphan nodes, конфликтующие relations и просроченные факты. После каждой ошибки сохраняют минимальный graph fixture как regression case. Rollback должен синхронно возвращать ontology version, graph snapshot и retrieval policy, а не только application code.

Основные сигналы: precision entity linking, accuracy relation traversal, evidence coverage, unanswered rate для неизвестных сущностей и качество ответа относительно text-only baseline. Offline evaluation должен содержать реальные и adversarial запросы, frozen labels и сегментацию по домену, языку и риску. Среднее значение не должно скрывать провал критического сегмента; для него нужен отдельный guardrail threshold.

В production нужны stable IDs, schema registry, constraints, review queue для новых связей, effective dates, source pointers и контролируемая миграция онтологии. Новую конфигурацию сначала запускают в shadow mode или на небольшом canary, сравнивают с baseline и автоматически откатывают при нарушении SLO. Такой цикл связывает качество, стоимость и надежность.

Knowledge graph полезен для multi-hop связей, но каждый node и edge должен иметь source, validFrom, validUntil и confidence. Автоматически извлеченные relations не становятся canonical fact без validation. Query pipeline сначала определяет entities, затем допустимые relation paths и только после этого собирает evidence для генерации. Слишком широкий traversal создает шум, latency и риск утечки между tenants.

Evaluation проверяет entity linking, path correctness, temporal validity и answer support. Для противоречивых sources граф сохраняет обе версии и provenance, а не перезаписывает факт. Graph update должен быть idempotent и поддерживать deletion propagation. Final response показывает source chain, чтобы пользователь мог проверить связь утверждений.

• Не создавайте edges без provenance.
• Ограничивайте traversal depth.
• Тестируйте temporal conflicts.