Тестирование Jev (TypeSafe System One) с помощью решений для навигации
Я создал neo4jev, чтобы поэкспериментировать с навигацией по графу, и здесь я немного расскажу о том, зачем и как это было сделано.
Что такое Jev? И почему это должно вас волновать?
Анонс на прошлой неделе от Typsafe.AI о модели принятия решений и классификации Jev произвел фурор в сообществе AI-инженеров.
Jev — это модель с самой быстрой скоростью внедрения в истории AI Gateway
Это не LLM, а быстрая, компактная и дешевая (42 доллара за миллиард входных токенов, выходные данные бесплатны) модель классификации, которая выдает только вероятности для выбора, логические решения (Noul) и оценки на основе текстовых и структурированных входных данных, но не генерирует текст. Она не предсказывает по одному токену, а выполняет все предсказания параллельно, поэтому вы можете передать столько задач, сколько захотите, в одном вызове API.
Модель обучена не с помощью RLHF для согласования с человеком, а с помощью RLCD (RL для калиброванных решений) — поэтому она больше похожа на традиционные задачи машинного обучения, просто с более современной базой модели.
Документация хороша, есть Playground и официальные SDK для JavaScript и Python, а также неофициальные для любого другого языка. Она уже интегрирована в OpenRouter, Pydantic.ai (отличная документация), LangChain, BrainTrust (для оценки).
Такие модели предназначены для использования внутри «горячего цикла» программного обеспечения, где вы обычно принимаете решения if/switch на основе данных, которые не являются детерминированными, а вероятностными. Текущие LLM слишком медленны и дороги для этого.
Neo4Jev — навигация по графу с помощью Jev
Когда появляется новый API модели или парадигма, игрушечные примеры обычно работают нормально, выглядят красиво, но не дают практического опыта.
Ожидая одобрения моей заявки в списке ожидания, я хотел попробовать что-то близкое мне, простое в реализации и демонстрации. Навигация по существующему графу знаний Neo4j с реальными данными и реальной схемой — это задача, на которой можно увидеть, действительно ли вещь работает или просто звучит убедительно.
Идея пришла из их демо «WikiRacing/WikiGame», просто чтобы было что-то, выполняющее осмысленную работу.
Wikiracing
Wikiracing
Цель игры — начать с одной страницы Википедии и достичь другой конкретной страницы Википедии, используя только ссылки, которые встречаются во время обхода. Каждый шаг может означать выбор между сотнями и тысячами ссылок! Это отличная площадка для демонстрации не только интеллекта в секунду, но и совокупных преимуществ отсутствия галлюцинаций при выборе с высокой кардинальностью.
Цель игры — начать с одной страницы Википедии и достичь другой конкретной страницы Википедии, используя только ссылки, которые встречаются во время обхода. Каждый шаг может означать выбор между сотнями и тысячами ссылок! Это отличная площадка для демонстрации не только интеллекта в секунду, но и совокупных преимуществ отсутствия галлюцинаций при выборе с высокой кардинальностью.
Задача: навигация по графу. Начать с узла, следовать по связям к цели (целевая сущность, цель пути или общая задача), по одному переходу за раз, и позволить модели — а не написанным вручную эвристикам — решать, по какой связи переходить на каждом шаге.
Для тестирования я использовал публичный граф знаний компаний Neo4j (15 меток, 28 типов связей), доступный на https://demo.neo4jlabs.com:7473 в базе данных «companies2».
Почему навигация — полезный тестовый пример
Если вы попытаетесь использовать LLM для обхода графа, то есть предсказания пути через набор данных, они справляются не очень хорошо, так как сгенерированные пути, узлы или связи могут на самом деле не существовать.
Они довольно хороши в генерации запросов, преобразуя вопрос пользователя со схемой графа в запрос к графу, что мы используем в Text2Cypher.
Но для этого варианта использования интерактивной навигации они слишком медленны. Обход в любом заданном узле — это не проблема генерации. Это выбор между текущим состоянием (возможно, историей) и конкретным, конечным набором вариантов: связями, которые действительно выходят из этого узла. Это гораздо лучше подходит для API, который возвращает вероятности вариантов, чем для того, который возвращает прозу.
Как работает Jev
API system_one принимает состояние (произвольный JSON, описывающий ситуацию) и набор вопросов, а затем возвращает ответы с вероятностями. Типы вопросов, которые здесь важны:
- Choice — «какой из этих вариантов?». Вы передаете карту ключей с описаниями. Ответ включает победителя, показатель уверенности и полное распределение вероятностей по каждому варианту.
- Noul — число с плавающей запятой от 0 до 1, по сути «насколько верно это утверждение?». Мы используем его как проверку достижения цели.
- Score — числовая оценка, здесь не требуется.
Вы можете задать несколько вопросов за один вызов (они выполняются параллельно, без дополнительных задержек или затрат), поэтому один «туда-обратно» на каждый переход одновременно выбирает следующее ребро и проверяет, прибыли ли мы. А для лучевого поиска (beam search) нужно то, что возвращает Choice: распределение для ветвления.
Начните откуда-нибудь и следуйте по следу
Конфигурация базы данных и ключ API typesafe загружаются из файла .env.
Коннектор neo4j загружает схему, для выбора начального узла вы выбираете метку, а затем можете находить записи с помощью точного, полнотекстового или векторного поиска.
Например, в нашем случае компания, такая как Apple
Затем вы указываете целевой режим
- Достижение целевого узла, например, члена совета директоров, такого как Ларри Пейдж
- Цель пути, концептуально следовать по такому пути, например, найти статьи, упоминающие эту компанию
- Задача в свободном тексте, например, найти всех людей, которые входят в совет директоров этой компании и других компаний, которые они консультируют
Затем приложение повторяет цикл до достижения порога
- Из текущего узла извлеките его исходящие и входящие связи — тип, свойства и метку + свойства целевого узла на другой стороне.
- Представьте их как варианты Choice: «по какой связи должен продолжаться обход?». Ключи вариантов — это непрозрачные идентификаторы (e0, e1, …) с таблицей соответствия реальным ребрам.
- В том же вызове задайте вопрос Noul: «достигнута ли цель в текущем узле?»
- Следуйте по top-k вариантам выше порога вероятности, ветвитесь, повторяйте.
Каждая ветвь накапливает сумму логарифмов вероятностей своих ребер (логарифмические суммы позволяют избежать потери точности и не наказывают более длинные пути так, как это делают произведения).
if view.goal_reached_by_noul(hop.noul, config.goal_threshold): expansion.terminated.append( NavPath( steps=[*state.path, _terminal_step(state.node_id, hop)], cumulative_log_prob=state.cumulative_log_prob, terminated_reason=TerminationReason.GOAL_REACHED, ) ) return expansion
for candidate, probability in hop.chosen: next_id = candidate.next_element_id if not next_id or next_id in state.visited: continue step = NavStep( node_id=state.node_id,chosen=[candidate], probabilities=hop.probabilities, log_prob=math.log(max(probability, _LOG_FLOOR)), candidates=hop.candidates,noul=hop.noul)
child = state.extend(step, next_id) if view.is_target(next_id): expansion.terminated.append( NavPath( steps=list(child.path), cumulative_log_prob=child.cumulative_log_prob, terminated_reason=TerminationReason.GOAL_REACHED, ) ) else: expansion.children.append(child) expansion.nodes[next_id] = NodeContext( element_id=next_id, label=candidate.next_label, properties=candidate.next_props, )
if not expansion.children and not expansion.terminated: expansion.terminated.append(_as_path(state, TerminationReason.NO_CANDIDATES)) return expansion
Набор посещенных узлов блокирует циклы, максимальная глубина и бюджет вызовов API ограничивают поиск, а ширина луча (соседи) ограничивает количество активных ветвей до максимального числа записей Choice.
Результатом является путь или пути с наивысшим баллом, а также исследованные, но не выбранные ветви в качестве контекста.
Тупиковый узел все равно получает свой вызов — только Noul, поскольку пустой Choice не имеет вариантов для выбора. Таким образом, «достижение цели и остановка» отличается от «исчерпания ребер».
Как достичь цели в зависимости от целевого режима
- Свободный текст — «найди компанию, которая конкурирует с начальным узлом». Описание попадает в состояние, Noul проверяет его на каждом шаге.
- Целевой узел — переход к конкретному узлу, выбранному через интерфейс поиска. Noul здесь тривиален («это он?»); Choice выполняет поиск пути.
- Намерение пути — описание формы пути, а не пункта назначения: «от пациента к экспрессии генов для его заболеваний». Описание разбивается на этапы, которые влияют на выбор Choice на каждом шаге; Noul проверяет финальный этап. Этот режим возвращает топ-N путей.
Что на самом деле имело значение
Поиск по лучу был легкой частью. Эти решения оказали гораздо большее влияние на то, хорошо или плохо работал Jev:
Модель может выбирать только из тех вариантов, которые она может прочитать. Убедитесь, что отправляете модели корректные и понятные данные, а не непрозрачные идентификаторы.
Отправляйте схему как «карту» вместе с локальными ребрами. Кандидаты на шаге показывают только то, что находится в текущем узле. Без дополнительного контекста модель не может рассуждать об обходном пути — например, проход через новостную статью, чтобы добраться до конкурента, когда нет прямого ребра. Она пойдет по касательной (в настоящее время обратного хода нет).
Держите полезную нагрузку достаточно маленькой. Длинные текстовые свойства и векторы эмбеддингов раздувают запрос и скрывают важные поля. Меньше состояние — лучше вероятности, ниже стоимость.
Предлагайте также входящие ребра. Изначально кандидатами были только исходящие ребра, что делало некоторые узлы недоступными. Теперь обход предлагает оба направления с явными метками, поэтому модель может двигаться назад по ребру, если цель находится выше по потоку.
Ограничивайте кандидатов справедливо. Реальные графы неравномерны и перекошены — у одной компании тысячи ребер поставщиков и горстка конкурентов. Наивное общее ограничение лишает ресурсов более редкие и интересные типы отношений. Мы сначала ограничиваем по типу ребра, затем заполняем оставшийся бюджет методом циклического перебора и сообщаем «N из M рассмотренных ребер», чтобы усечение было заметно.
Система
Код вокруг основного шаблона минимален, всего 5 файлов Python.
- neo4j_access — все, что связано с Neo4j: интроспекция меток и индексов, выборка кандидатов с вышеуказанным ограничением, вывод свойств идентификации, снимок схемы.
- types — статические типы для хранения результатов графа, вариантов выбора и полезной нагрузки API для Typsafe API.
- navigator — поиск по лучу и граница TypeSafe: создает вызов system_one для каждого шага, превращает вероятности в ветви, оценивает пути.
- viz — визуализирует пути и контекст окрестностей с помощью neo4j-viz, раскрашивая по метке/типу, с путями поверх, легендами, деталями и макетами, доступными «из коробки».
- Notebooks — три блокнота (исследование, один шаг, полный обход по всем режимам целей) и
- Streamlit app — приложение, которое показывает трассировку каждого шага: каждый вариант, предложенный Jev, с его вероятностью, что он выбрал и вердикт Noul.
Работает ли эта идея?
Пока да, с оговорками. Когда полезная нагрузка чиста и схема включена, Jev перемещается разумно: от Microsoft, при запросе найти конкурента, он выбирает HAS_COMPETITOR → Amazon.com, Inc. с вероятностью 0.85 — и полное распределение показывает почему, чего не даст никакой текстовый ответ. Все три режима цели дают связные пути.
Оговорки:
- качество решений тесно связано с качеством полезной нагрузки (мусорные свойства на входе — безразличный выбор на выходе),
- узлы с высокой степенью нуждаются в ограничении, чтобы оставаться в пределах лимита выбора в 255 вариантов и разумной стоимости токенов, и
- Noul, определяющий достижение цели, является самым слабым звеном для расплывчатых целей в свободном тексте.
Более широкий вывод таков: если каждый шаг задачи можно сформулировать как решение на основе реальных, полученных вариантов, вам не нужно позволять модели импровизировать запросы или описывать путь.
Вы получаете обход, который является:
- обоснованным (каждое пройденное ребро существует),
- проверяемым (распределение вероятностей записывается для каждого шага),
- управляемым (цели — это просто состояние), и
- дешевым (один вызов API на шаг, вопросы мультиплексируются внутри него).
Этот шаблон должен переноситься на планирование запросов, маршрутизацию рабочих процессов, выбор моделей/инструментов и другие виды принятия решений. Навигация по графу — это просто очень буквальная его версия.
Попробуйте
Репозиторий GitHub находится здесь: https://github.com/jexp/neo4jev
Демо работает с публичным графом знаний компаний Neo4j
- URI
- имя пользователя только для чтения, пароль, база данных: companies2
Укажите .env на любой другой экземпляр Neo4j, и метки, индексы, свойства идентификации и схема будут обнаружены в реальном времени.
Нет предела совершенству
У них есть список ожидания, но вы попадете туда в течение дня. Вам определенно стоит присоединиться к их Discord, он очень активен, у них регулярные общие собрания AMA и очень интересный канал show-and-tell с тысячами демо и приложений.
Некоторые вещи, которые я хотел попробовать:
- Разрешение сущностей (мой коллега Kervin Hu писал об этом
Я протестировал Jev на разрешении сущностей
- Маршрутизация/выбор инструментов (включая извлечение параметров)
- Принятие решений для кодирования и обвязок баз данных (например, для сжатия, маршрутизации моделей, определения критичности изменений, проверки кода)
Я попросил Jev оценить некоторые идеи (от Claude) по использованию моделей принятия решений, это именно то, что вы ожидаете, типичное принятие решений, которое нужно в коде, но более динамичное, чем мог бы дать детерминированный код.
Так много сайтов со списками проектов Jev.
Уже существует много Alternatives/Clones, таких как Laya (MLX), BERT, обученные Qwen LoRA (Kev) модели принятия решений и OpenJev.
Если вы еще этого не сделали, попробуйте!
Navigating a Neo4j Knowledge Graph with Jev была первоначально опубликована в Neo4j Developer Blog на Medium, где люди продолжают обсуждение, отвечая на эту историю.
