#ai_on_backend

Проблема: векторные базы ищут по косинусной близости или гибридно – и то и другое связей между данными не понимает.

Запрос "найди все контракты с японскими поставщиками" возвращает случайные японские документы (Манга Берсерк?), а не логические связи между поставщиками и контрактами.

Это достаточно легко может превратиться в черную коробку — система находит что-то похожее, но не то что нужно. Бизнес платит за галлюцинации, а разработчикам сложно отладить систему. 😨

Почему так происходит? Ну "близость в векторном пространстве" это вообще не про смысловую связность, а про статистическую корреляцию в данных на которых обучалась эмбеддинг модель (паттерны совместной встречаемости токенов). Если проще, то документы могут быть семантически близки, но контекстуально далеки.

Возможное решение – Knowledge Graph RAG

Вместо тупого поиска по косинусной близости строим граф связей между сущностями в документах. Каждый узел в графе — это конкретная сущность (компания, контракт, персона), а ребра — установленная связь.

Как это работает на практике:

1. LLM анализирует документы и создает структурированный граф, формирует "долгосрочную память" (Да, вдохновлено белковыми мозгами)
2. Вместо косинусной близости делаем траверс по графу с учетом связей
3. В результате система "понимает" не только что искать, но и как связаны найденные данные

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

Большая прозрачность в проде означает:

- Более понятный дебаг – можно проследить путь обхода графа, в отличие от малопрозрачных векторных пространств (почему оно вообще сметчилось?!)
- Повышаем нашу способность наблюдать, понимать и объяснять логику решения
- Некоторое снижение рисков галлюцинаций – ведь данные такая система должна вытаскивать более релевантные

Но честно, сам процесс построения графа может вносить ошибки – LLM может неправильно извлечь сущности или связи между ними. Это просто смещает проблему с retrieval на extraction.

Microsoft уже показала в своем прошлогоднем GraphRAG исследовании, что такой подход улучшает точность в сложных кейсах с multi-hop reasoning.

Тут как всегда есть компромисы – построение графов знаний может требовать более емкой предварительной обработки данных и более сложной архитектуры чем обычный векторный поиск.

Как я уже писал вчера – для простых кейсов (FAQ, документация) обычный векторный поиск часто хорош и достаточен. GraphRAG имеет смысл для структурированных запросов с множественными связями между сущностями. А еще, если свернуть не туда то, переусложить граф, то наблюдаемость... будет не такой уж и хорошей :) Разбираться в запутанных графах то еще удовольствие.

Еще посмотреть по теме:
- mem0
- Cortex
- fast-graphrag
- Cognee

---

Если пред вами стоит задача построить внедрить на бекенд AI систему с памятью – приходите!
Я с удовольствием помогу вам в разработке @m0n0x41d 💗