Граф знаний для продуктового исследования: почему RAG недостаточно

“Покажи все боли, для которых нет решения на рынке” — если ваш инструмент использует RAG, он не справится. Потому что это вопрос не про текст, а про структуру: найди узлы типа “боль” без входящих рёбер “решается”. Это задача на граф, а не на семантический поиск.

AI-ассистенты для исследования: почему “поиск по тексту” — это потолок

Представьте: вы провели 15 интервью, собрали 80 фактов о рынке, нашли 12 болей аудитории, описали 4 сегмента и 6 конкурентов. Теперь спрашиваете AI:

«Покажи все боли, для которых нет решения на рынке»

RAG превратит вопрос в вектор, найдёт 5-10 похожих текстовых фрагментов и отправит в LLM. Модель честно попытается ответить. Иногда попадёт. Чаще — нет.

Потому что ваш вопрос — не про текст. Он про связи: найди узлы типа pain, у которых нет входящих рёбер типа solves. Один SQL-запрос с LEFT JOIN. Никакого LLM не нужно.

RAG: мощный молоток, но не каждая задача — гвоздь

RAG отлично работает для “расскажи, что я знаю про X”. Но продуктовое исследование — это не FAQ:

Какие сегменты испытывают боли, которые конкуренты не закрывают?
Если конкурент X запустит фичу Y — какие задачи каких сегментов под угрозой?
Какие боли я нашёл, но не привязал ни к одному сегменту?
Какие факты противоречат друг другу?
Где в моём исследовании пробелы?

Каждый вопрос — запрос к связям между сущностями. RAG не знает, что “боль” и “сегмент” — разные типы, связанные отношением “испытывает”. Для RAG это просто текст.

Конкретный пример: orphan pain nodes

Факт из интервью: “Предприниматели тратят 3 дня на анализ конкурентов вручную”. Это боль. Из другого интервью: “Solo-founders сталкиваются с нехваткой времени на исследования”. Это связь: сегмент → испытывает → боль.

Но RAG может никогда не положить их в один контекст. Семантически фрагменты не похожи — один про “3 дня”, другой про “нехватку времени”.

В графе знаний:

Node: pain:manual_competitor_analysis (confidence: 85)
Node: segment:solo_founder (confidence: 90)
Edge: solo_founder → AFFECTS → manual_competitor_analysis

Запрос “боли без решения” = найди pain узлы без входящего ребра SOLVES. Один SQL-запрос.

GraphRAG: шаг в правильном направлении

Microsoft предложил GraphRAG — надстройку над RAG:

Community detection — кластеризация связанных сущностей
Cross-document synthesis — LLM суммирует каждый кластер
Multi-level retrieval — поиск сначала по кластерам, потом по деталям

Значительно лучше для обзорных вопросов. Но граф — generic. Он не знает, что “боль” и “задача” — разные вещи. Что у задачи есть иерархия. Что переключение описывается формулой push/pull/anxiety/habit.

Мой подход: methodology-native Knowledge Graph

Вместо generic графа я построил граф, который знает методологию:

Онтология: 10 типов узлов, 18+ типов связей

Типы узлов: pain, job, segment, competitor, solution, trend, metric, feature, trigger, channel
Типы связей: causes, solves, threatens, enables, blocks, measures, affects, hires_for, switches_from и другие
Constraints: affects идёт только от pain к segment. solves — от solution к pain. Бессмысленное ребро не создашь

26 data points из Product DNA

Каждый проект отслеживает 26 точек данных из методологии Product DNA — от болей и триггеров переключения до unit economics и барьеров adoption. Граф знает что собрано, а что нет. Направляет исследование, а не просто ищет.

Bi-temporal модель

Каждый узел: когда факт был валиден (valid_at) и когда записан. “Рынок $1B” в марте → “рынок $500M” в апреле. Оба факта в базе. Старый инвалидирован, не удалён.

Hybrid Search: три источника сигнала

Граф — не замена семантическому поиску, а дополнение:

Vector search — находит концептуально близкие узлы. “Нехватка времени” = “тратит 3 дня вручную”
BM25 (keyword) — точное совпадение. Когда ищешь конкретный термин
Graph traversal (CTE) — обход графа. “Все боли сегмента X и их решения” = 2 шага по рёбрам

Результаты объединяются через Reciprocal Rank Fusion — берёт ранги из каждого источника и комбинирует. Устойчивее взвешивания.

Что это даёт на практике

AI-ассистент перестаёт задавать generic вопросы. Вместо “расскажите подробнее” он видит конкретные пробелы:

“У тебя 5 болей без сегмента. Кто именно сталкивается с ручным анализом конкурентов — solo-founder или команда?”

“3 конкурента, но ни у одного не указано, какие задачи решают. Какую job выполняет пользователь, когда нанимает конкурента X?”

Бот не просто отвечает — он ведёт исследование, опираясь на понимание того, что собрано и чего не хватает.

Competitive intelligence через граф

Конкурент запускает фичу → граф: фича → решает задачу → задачу испытывает сегмент → сегмент — наш целевой. Один обход графа = ответ “насколько это для нас опасно”. В RAG это серия запросов с ручной интерпретацией.

RAG = поиск. Knowledge Graph = понимание

RAG — отличная технология. Но для продуктового исследования одного поиска мало. Когда инструмент знает разницу между болью и задачей, между сегментом и персоной — он перестаёт быть поисковиком и становится исследовательским партнёром.

RAG отвечает на “что я об этом знаю?”
Knowledge Graph отвечает на “что я ещё НЕ знаю и почему это важно?”

Второй вопрос определяет качество исследования. Ценность — не в объёме данных, а в полноте связей.

Попробуйте methodology-native Knowledge Graph в действии — AICPO или напишите nevr@aicpo.com