GraphRAG добавляет к поиску граф знаний: узлы обозначают сущности реального мира, а рёбра - семантические связи между ними. Такая структура позволяет LLM выполнять многошаговые рассуждения, находить реляционные цепочки и собирать сложные контекстные ответы, которые плохо даются векторному поиску по чанкам. Обзор шести архитектурных схем такой системы есть в материале GraphRAG на практике: 6 архитектурных паттернов.
Проблема начинается при масштабировании. Граф знаний - детерминированная структура, но его построение, поддержка и обход требуют десятков тысяч вероятностных микрорешений: сопоставить ли две сущности, одинаковы ли по смыслу два предиката, какие узлы из обхода оставить, а какие отсечь. Когда граф дорастает до миллионов узлов и рёбер, эти решения превращаются в узкое место. Если каждое из них отдавать авторегрессионной LLM, задержка и стоимость растут вместе с графом, а рутинные ingestion, поддержка и retrieval тянут бюджет.
TypeSafe Jev берёт эту часть работы на себя. Это неавторегрессионная калиброванная модель принятия решений от TypeSafe AI: она не стримит токены и не пишет текст, а принимает состояние и выполняет типизированные вероятностные микрорешения в параллельном режиме. Разработчик заявляет задержку менее 500 мс и долю стоимости LLM на этих задачах. Ниже разбираем, как разделить роли между Jev и LLM, какие паттерны это даёт и где начинаются ограничения.
Почему GraphRAG упирается в микрорешения
Граф знаний в GraphRAG хранит факты в явном виде: узлы и рёбра. Это удобно для многошаговых запросов, но на каждом шаге приходится принимать вероятностные решения, которые не сводятся к точному сравнению строк или чисел.
Что такое микрорешения в графах знаний
Микрорешение - небольшой выбор с вероятностным исходом, который приходится совершать часто и быстро. В графе знаний они разбросаны по всему жизненному циклу:
- Сопоставление сущностей. Один ли узел «Alphabet Inc.» из чанка A и «Google LLC» в узле 40812?
- Унификация предикатов. Одинаков ли по смыслу предикат [:WORKS_FOR] и [:EMPLOYED_BY] в нашей онтологии?
- Отбор релевантных узлов. Из 2500 узлов, собранных обходом в 3 шага, оставить только 15, которые действительно нужны под конкретный запрос.
- Взвешивание рёбер. Насколько сильна связь между узлами и как её вес меняется со временем.
- Тегирование. Какой категорией пометить новый узел: тип сущности, тематика, роль.
Примеры с «Alphabet Inc.» и предикатами приведены в разборе GraphRAG with TypeSafe Jev. Каждое решение вероятностное: однозначного ответа «это один узел или нет» часто не существует, есть лишь оценка уверенности.
Почему LLM плохо подходит для микрорешений
Авторегрессионные LLM обучены генерировать неструктурированный текст. Заставить их выдавать валидный JSON или Cypher почти детерминированно можно только через строгий prompt engineering, подбор temperature и хрупкий парсинг регулярками или pydantic, который ломается на граничных случаях. Одна ошибка парсинга - и пайплайн останавливается или пишет мусор в граф.
Вторая проблема - экономика. Один вызов LLM сам по себе недорог, но микрорешения исчисляются тысячами: каждая новая сущность, каждый предикат, каждый обход. Задержка и стоимость умножаются на это число, и там, где на десяти документах всё работает, на десяти миллионах узлов пайплайн перестаёт укладываться в SLA.
Причина архитектурная. Авторегрессионные LLM построены как движки System 2: они сильны в глубоких рассуждениях, синтезе текста и генерации сложного кода. Микрорешение - задача System 1, ближе к классификации или скорингу, и для неё отраслевой стандарт - быстрые лёгкие модели, а не генеративные.
System 1 и System 2: от Канемана к архитектуре GraphRAG
Разделение пришло из книги Даниэля Канемана «Thinking, Fast and Slow». Канеман разделил человеческое познание на две системы: System 1 работает быстро, инстинктивно, ассоциативно и без усилий; System 2 - медленно, последовательно, логически и с усилием.
В машинном обучении та же граница проходит по типу задачи. Микрорешение по своей природе вероятностное и повторяющееся, то есть это задача System 1, и решать её должна быстрая надёжная модель. Глубокое рассуждение и синтез ответа - System 2, где генеративные LLM на высоте.
Отсюда следует вывод, к которому пришёл автор разбора: держать обе роли на одной авторегрессионной модели неоптимально. LLM справятся, но заплатят задержкой, стоимостью и хрупкостью на каждом System 1 шаге. Нужна отдельная модель System 1, заточенная под типизированные решения.
TypeSafe Jev: что это за модель и как она работает
TypeSafe AI выпустила Jev как специализированную модель System 1, созданную закрыть разрыв между задачами микрорешений и возможностями генеративных LLM. Jev - неавторегрессионная калиброванная модель принятия решений. Она не стримит токены и не производит разговорную прозу: получает состояние и выполняет типизированные вероятностные микрорешения в параллельном режиме при задержке менее 500 мс и доле стоимости LLM. Подробнее о модели и её отличиях от ChatGPT - в обзоре Jev от TypeSafe: принцип работы и примеры.
Примитивы noul, choice и score
Описание темы называет примитивы noul, choice и score; в разборах Jev на AI-Manual те же три типа вопросов фигурируют как Choice, Noulli и Score. Смысл один - три формы ответа, которые покрывают большинство микрорешений в графе:
- Nouli (noul) - ответ да/нет с вероятностью. Подходит для сопоставления: «вероятность, что два узла - одна сущность, 0.94».
- Choice - категориальное распределение по заданному набору вариантов. Подходит для выбора типа связи из онтологии или тега узла: «персона - 0.8, организация - 0.15, локация - 0.05».
- Score - порядковая оценка по уровням. Подходит для релевантности узла запросу или силы ребра: «высокая / средняя / низкая» с вероятностями.
Фрагмент первоисточника обрывается на описании Jev и не детализирует примитивы, поэтому названия и поведение стоит сверять с документацией TypeSafe AI. Одно свойство из описания модели важно для графа: варианты ответа задаёт вызывающий код, а не модель. Jev не может сгенерировать произвольный текст и, как следствие, не может выдумать сущность, которой нет в списке. Разбор примитивов и сценариев применения - в статье Jev от TypeSafe AI: как System One модели меняют подход к AI-примитивам в коде.
Калибровка вероятностей и её значение
Калиброванная вероятность означает, что при значении 0.9 событие сбывается примерно в 90% случаев. Для микрорешений это критично: решения складываются в цепочку, и систематическая переоценка уверенности накапливается в ошибки графа. LLM выдают числа, которые выглядят как вероятности, но таковыми не являются, и опираться на них в порогах рискованно.
Калибровка даёт практическую выгоду: можно ставить пороги и принимать решения по уверенности модели. Например, автоматически сливать узлы при вероятности выше 0.95, отправлять на ручную проверку диапазон 0.7-0.95 и оставлять как есть всё, что ниже. Такой пайплайн предсказуем, а его пороги настраиваются и измеряются.
Dual-engine паттерн: как разделить роли между Jev и LLM
Dual-engine разводит работу по двум движкам. Jev в роли System 1 отвечает за построение, поддержку и фильтрацию графа. LLM в роли System 2 - за финальный текстовый ответ. Поток выглядит так:
- Ingestion: документы разбираются на сущности и связи, Jev разрешает дубликаты и унифицирует предикаты.
- Граф обогащается: рёбра получают веса, узлы - теги и метрики уверенности.
- Retrieval: под запрос обходится окружение, Jev отсекает нерелевантные узлы и оставляет компактный подграф.
- Синтез: LLM получает уже отфильтрованный подграф и пишет ответ.
Пример оркестрации таких решений в агентном цикле с LangGraph есть в отдельном разборе: Jev и LangGraph: продакшн-агенты на дешёвых решениях.
Зона ответственности Jev: построение, поддержка, фильтрация
Jev забирает все высокочастотные вероятностные решения:
- дедупликация сущностей и предикатов;
- кросс-онтологический маппинг при слиянии графов из разных источников;
- динамическое взвешивание рёбер;
- тегирование узлов в реальном времени;
- прунинг подграфов для снижения объёма контекста.
Общее у всех задач одно: каждая решается за один проход, а варианты ответа заданы заранее.
Зона ответственности LLM: рассуждения и синтез ответа
LLM остаются там, где нужна генерация: многошаговые выводы по подграфу, объяснение связей, написание сложного кода, финальный текст для пользователя. На вход LLM приходит уже отфильтрованный и обогащённый граф. Чем меньше лишних узлов, тем короче контекст, дешевле генерация и выше шанс, что модель не потеряет факт в середине длинного промпта. О том, как объём контекста бьёт по точности, есть отдельный материал: почему LLM теряет факты в больших документах.
Практические паттерны применения Jev в GraphRAG
Фрагмент первоисточника обрывается до разбора этих паттернов, поэтому ниже - рабочая схема того, как перечисленные задачи ложатся на примитивы Jev. Её стоит проверять на своём пайплайне, а не принимать как гарантированный рецепт.
Дедупликация сущностей и предикатов
Jev получает пару сущностей или предикатов и через noul возвращает вероятность их идентичности. Порог задаётся эмпирически. Пример: «Alphabet Inc.» и «Google LLC» - модель оценивает вероятность того, что это один узел, и решение принимается по порогу. Та же логика работает для предикатов [:WORKS_FOR] и [:EMPLOYED_BY].
Кросс-онтологический маппинг
При слиянии графов из разных источников сущности и связи приходят в разных онтологиях. Через choice Jev строит категориальное распределение по кандидатам соответствия и выбирает наиболее вероятного. Ручной маппинг схем заменяется пакетной обработкой, а спорные случаи уходят на проверку по порогу уверенности.
Динамическое взвешивание рёбер
Примитив score даёт рёбрам порядковую оценку силы или релевантности. Веса могут пересчитываться по мере поступления новых данных, поэтому граф отражает свежесть связей, а не только факт их наличия. Пример: ребро между пользователем и товаром получает вес на основе истории взаимодействий.
Тегирование узлов в реальном времени
Новый узел классифицируется по категориям через choice: тип сущности, тематика, роль. Узел «Иван Иванов» получает теги «персона» и «клиент» сразу при добавлении, без отдельного прохода LLM. Метаданные помогают фильтровать граф при retrieval.
Прунинг подграфов для снижения объёма контекста
Обход в 3 шага может вернуть 2500 узлов, из которых под запрос реально нужны 15. Jev через score оценивает релевантность каждого узла и отсекает остальное, формируя компактный подграф для LLM. Эффект двойной: меньше токенов на генерацию и меньше шума, в котором LLM теряет нужный факт.
Ограничения и подводные камни подхода
Цифры по задержке и стоимости приходят от разработчика, независимых измерений в разборе нет, а сам фрагмент источника обрывается на середине описания. Поэтому к таким обещаниям стоит относиться как к ориентиру, а не как к гарантии. Ниже - ограничения, которые заметны уже на уровне архитектуры.
Настройка порогов на калибровочной выборке
Пороги для noul, choice и score нельзя выставлять на глаз. Их настраивают на калибровочной выборке, балансируя precision и recall. Порог 0.9 для дедупликации может быть слишком строгим и оставить дубликаты, а 0.7 - слишком мягким и склеить разные сущности. Ошибка здесь портит граф молча.
Риск ошибок на граничных случаях
Jev, как любая модель, ошибается на неоднозначных данных: сущности с одинаковыми именами, но разным контекстом; предикаты, близкие по смыслу, но не эквивалентные. Для критичных решений имеет смысл добавлять проверки: ручную верификацию, сверку с дополнительным сигналом или ансамбль из нескольких запросов.
Часть ограничений лежит за пределами самой модели. Качество входа определяет качество графа: мусорные чанки дадут мусорные узлы, и никакая калибровка это не исправит. Стыковка Jev с существующим пайплайном требует работы: собственная логика батчинга, хранение метрик, обучение команды новому разделению ролей. И Jev не заменяет LLM полностью: он закрывает только часть задач.
Как встроить Jev в свой GraphRAG-пайплайн: рекомендации
Строгое разделение ролей
Границы стоит провести жёстко: Jev решает вероятностные задачи на графе, LLM генерирует текст. Попытка заставить Jev писать объяснения или LLM делать микрорешения сводит на нет выгоду от разделения: первый не умеет генерировать, второй тратит токены на то, что дешевле решить классификацией.
Параллельная пакетная обработка
Jev выполняет микрорешения в параллельном режиме, поэтому их выгодно собирать в пакеты. Вместо тысячи одиночных вызовов - один батч на тысячу пар сущностей, что поднимает пропускную способность и снижает суммарную задержку. Несколько вопросов к одному состоянию можно задавать в одном запросе.
Сохранение метрик Jev как свойств графа
Вероятности и оценки стоят того, чтобы писать их в атрибуты узлов и рёбер. Так видно качество решений, можно проводить аудит и пересчитывать пороги на накопленных данных. Ребро с низкой оценкой уверенности логично помечать для ручной проверки.
Начинать разумно с пилота на небольшом графе: посчитать, сколько микрорешений в пайплайне сейчас уходит в LLM, и сравнить задержку и стоимость до и после подключения Jev.
Кому и когда стоит использовать TypeSafe Jev
Jev имеет смысл там, где граф знаний большой, а микрорешения исчисляются тысячами: дедупликация при ingestion, унификация предикатов, прунинг подграфов перед генерацией. Тогда разделение System 1 и System 2 снимает часть нагрузки с LLM и убирает растущие задержки и расходы.
Если граф небольшой или микрорешения редки, выгода будет незаметна, а интеграция и настройка порогов добавят работы. Прежде чем браться, оцените объём вероятностных решений в своём пайплайне. Ответ на главный вопрос - сколько раз в сутки вы вызываете LLM ради задачи, которая по сути классификация, - обычно и определяет, окупится ли переход на Jev.