"#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 💗"