Jev и локальный ИИ: как усилить помощника, сохранив секреты компании

Локальная нейросеть читает документы компании, готовит ответы и помогает сотрудникам. Но часть её времени уходит на короткие решения: подходит ли найденная страница, к какой теме относится материал, какой инструмент выбрать дальше. Для этого не всегда нужен длинный ответ большой модели.

Здесь интересен Jev — модель TypeSafe для структурированных оценок. Ей можно поручить отдельные решения, а написание текста и работу с закрытым контекстом оставить локальному ИИ. Разберём, где такая связка полезна и как построить её без отправки чувствительных данных бизнеса.

Исходная подборка awesome-jev — неофициальный каталог сообщества. Она помогает найти проекты, но наличие библиотеки или демонстрации в списке ещё не подтверждает её готовность для корпоративного внедрения. Техническую основу ниже сверяем с документацией TypeSafe на 26 сентября 2026 года. Awesome Jev: unofficial community directory ↗

В API Jev передают контекст задачи — state — и вопросы. Ответы имеют заданную структуру: Choice выбирает вариант, Score оценивает по описанной шкале, Noul возвращает число от 0 до 1 для вопроса «да или нет». Это модель для решений, которые затем использует программа. TypeSafe: Jev and structured decision primitives ↗

Например, локальная модель пишет обзор технологии. Jev можно попросить оценить открытые страницы: относится ли каждая к нужной теме и содержит ли практические сведения. Программа формирует подборку, а локальная модель объясняет, как найденное применить в компании.

Усиление происходит на уровне всей системы. Веса локальной модели от подключения Jev не меняются. Потенциальная польза — меньше нерелевантного контекста, меньше длинных вызовов ради простого выбора и более явное разделение этапов. Будет ли результат лучше и дешевле, нужно измерять на конкретной задаче.

Локальная модель может знать внутренний контекст компании. Внешнему помощнику достаточно поручить ту часть работы, для которой этот контекст вообще не нужен.

В этой статье рассматриваем официальный облачный API TypeSafe. Его интерфейс принимает state и набор вопросов через внешний адрес api.typesafe.ai. Установка клиентской библиотеки на собственный сервер сама по себе не переносит вычисления модели в офис. TypeSafe: hosted System One API ↗

Разработчик сообщает, что не обучает модели на данных пользователей, и отдельно предлагает enterprise-клиентам zero data retention. Это условия обработки и хранения, а не отсутствие передачи. Для нашей архитектуры правило строже: чувствительные данные не должны попадать в исходящий запрос независимо от обещаний провайдера. TypeSafe: data-handling commitments and enterprise ZDR ↗

Нельзя передать договор «только на проверку», получить один балл и считать, что договор остался внутри. Маленький ответ ничего не говорит об объёме отправленного входа. Точно так же внешний проверяющий модуль, которому показывают переписку ради поиска утечек, уже получает эту переписку.

Поэтому Jev не должен решать, разрешено ли ему увидеть документ. Это решение принимается до сетевого вызова, внутри компании.

Предлагаем разделить работу на два контура. Во внутреннем находятся договоры, цены закупки, клиентские карточки, переписка, история задач и локальная база знаний. Во внешнем — заранее разрешённые общедоступные материалы и утверждённые общие вопросы.

Сотрудник формулирует задачу локальному ИИ. Если нужны внешние сведения, программа выбирает разрешённое общее задание, отправляет только публичный контекст, получает оценки и возвращает результаты внутрь. Сопоставление с реальными проектами, расчёты и итоговый документ выполняются локально.

Например, компания изучает резервное копирование. Jev оценивает открытые инструкции по общему вопросу «описана ли здесь процедура восстановления». Названия внутренних систем, объёмы баз, схема сети и результаты аудита ему не нужны. Локальный помощник уже внутри сопоставляет выбранные инструкции с инфраструктурой.

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

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

Локальная модель отвечает лучше, когда получает подходящие источники. В официальном примере TypeSafe отдельный этап оценивает найденные фрагменты перед передачей генератору. Сам принцип можно проверить на открытой документации; результаты чужого примера нельзя автоматически переносить на свою базу. TypeSafe: classifying RAG passages cookbook ↗

Предположим, инженерный отдел собирает общую библиотеку инструкций по вентиляции. Сначала обычный поиск находит страницы. Затем Jev отвечает на узкие вопросы: есть ли порядок обслуживания, перечислены ли ограничения, относится ли материал к выбранному типу системы. Внутренняя модель получает отобранные фрагменты с адресами источников.

Особенно удобен фоновый вариант: заранее обработать публичную библиотеку по утверждённой общей рубрике. Тогда конкретный запрос сотрудника вообще не передаётся наружу. Во время работы локальный поиск использует подготовленные признаки вместе с собственным индексом.

Договоры, закрытые инструкции, внутренние запросы и результаты поиска по ним остаются в локальном контуре. Если без них нельзя оценить релевантность, нужен локальный ранжировщик или локальная модель. Отправлять закрытые фрагменты внешнему ранжировщику — такая же передача данных, как отправлять их чат-боту.

Jev можно дать уже опубликованную страницу сайта или специально одобренный для внешней обработки текст. Вопросы должны быть узкими: понятен ли предмет услуги, указано ли следующее действие, различаются ли описание функции и обещание результата.

Локальная модель готовит варианты улучшений с учётом внутреннего позиционирования. Jev оценивает только разрешённую публичную версию по общей шкале. Финальное решение принимает редактор: оценка не заменяет знание продукта и проверку фактов.

Это полезнее, чем поручать внешнему сервису анализ всей маркетинговой папки. Черновики будущих запусков, бюджеты, сегменты клиентов и план продаж могут быть коммерчески чувствительными, хотя итоговая статья будет публичной. Статус «готовится к публикации» ещё не означает «можно отправлять любому провайдеру».

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

Внешнему модулю достаточно опубликованных названий и характеристик. Остатки, себестоимость, скидки поставщиков, история покупок и клиентская потребность в запрос не входят. Сопоставление публичной карточки с внутренним артикулом хранится отдельно внутри системы.

Даже высокая оценка сходства не доказывает взаимозаменяемость оборудования. Размеры, допуски и обязательные технические условия проверяются по исходным данным; спорную замену подтверждает специалист. Этот сценарий помогает подготовить каталог к работе локальной модели, но не передаёт внешнему ИИ право выбирать поставку.

Можно создать набор полностью синтетических обращений: запрос инструкции, просьба уточнить срок, вопрос о совместимости. Jev предлагает категории или оценки по заранее заданной рубрике, а команда сравнивает их с человеческой разметкой и ответами локальной модели.

Так удобно искать неоднозначные формулировки, проверять маршрутизацию и подбирать примеры для промпта. Оценки Jev остаются мнением второго инструмента, а не эталоном истины. Контрольный набор размечают люди, а качество на закрытых реальных задачах проверяют локально.

Синтетический пример должен быть действительно вымышленным. Замена фамилии в настоящей претензии сохраняет обстоятельства, сумму и конфликт. Копирование реального разговора с просьбой «обезличь» во внешний сервис тоже не подходит: передача уже произошла.

Локальный агент может строить план, а Jev — выбирать один из заранее разрешённых переходов на открытом сайте: «руководство», «ограничения», «примеры». Программа выполняет только допустимое действие, затем локальная модель читает результат и продолжает работу.

Для такого пилота нужен отдельный браузерный процесс без рабочих авторизаций и корпоративных вкладок. Внешнему модулю передаётся ограниченное текстовое представление разрешённой страницы. Полный экран, DOM личного кабинета, история переписки и поля CRM в этот сценарий не входят.

Jev 1.13 принимает текст, а не изображения или аудио. Если демонстрация работает со скриншотом или голосом, подготовку текста выполняет другой компонент, чей маршрут данных тоже нужно проверить. Английский — основной язык обучения; качество русскоязычных задач следует оценивать отдельно. TypeSafe: model version, text input and language support ↗

Скрытые действия страницы также важны: публичная форма может отправить сообщение или оформить заказ. Поэтому для первого пилота разумно ограничиться чтением документации. Любая операция с последствиями требует отдельного разрешённого маршрута и подтверждения.

Представим вымышленную заявку: «Заказчик задержал оплату за объект, просит отсрочку; договор содержит особое условие». Если заменить заказчика на CLIENT_17, содержание конфликта и договорное условие всё ещё выходят наружу. Добавление точной суммы и даты делает запись ещё узнаваемее.

Можно оставить лишь общий вопрос «как классифицировать запрос отсрочки». Но если категория уже известна из подготовки запроса, внешняя модель не добавляет пользы. А если для решения нужен текст спорного пункта, задачу следует целиком выполнить локально.

Именно здесь проходит практическая граница. Удаление лишнего контекста иногда позволяет вынести простое решение наружу, а иногда уничтожает смысл задачи. Не нужно любой ценой находить применение Jev: локальная обработка может быть правильнее и проще.

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

На пилоте мы предложили бы отдельный исходящий шлюз — программный компонент, через который разрешены обращения к Jev. Его задача не «поверить модели», а собрать запрос только из допустимых источников и полей.

• Публичные материалы хранятся отдельно от внутренних документов. Признак допустимости задаётся доверенным процессом, а не текстом самой страницы.
• Схема запроса допускает ограниченные поля и размеры. История диалога, вложения и закрытые записи не подмешиваются автоматически.
• Проверяются все части запроса: state, вопросы, критерии, примеры, адреса страниц. В URL могут оказаться служебные параметры и идентификаторы.
• Локальная проверка на секреты служит дополнительным барьером. Неопределённый статус означает запрет отправки и переход к локальной обработке.
• Модель не получает ключ API и не может самостоятельно расширять набор отправляемых полей. Другие исходящие пути также ограничиваются.
• Журнал содержит версию политики, идентификатор операции, объём и результат проверки. Полные тела запросов не копируются бесконтрольно в стороннюю аналитику.

Это проектные требования к интеграции, а не уже встроенные свойства Jev или гарантия отсутствия утечек. Их проверяют на фактическом сетевом трафике, включая повторные попытки, обработку ошибок и мониторинг.

Choice и Score возвращают confidence, вычисляемую из распределения ответов. Это отдельная величина; её нельзя читать как подтверждённую точность на задачах вашей компании. У Noul отдельного поля confidence нет. Пороги подбирают по контрольным примерам. TypeSafe: confidence and probability distributions ↗

Пусть система уверенно выбрала категорию открытой статьи. Можно предложить этот тег редактору. Но такая же уверенность в выборе инструмента не даёт права удалить файл или отправить клиенту письмо. Права и допустимость действия проверяет приложение независимо от оценки.

В документации Jev 1.13 отмечены слабые места: точные вычисления, сравнение дат, сложные косвенные рассуждения и влияние враждебного содержимого на решение. Расчёты и правила доступа нужно оставлять в коде; чужая страница не должна превращаться в инструкцию агенту. TypeSafe: Jev 1.13 known failure modes ↗

Для проверки сравните один и тот же набор задач: локальный помощник самостоятельно и тот же помощник с Jev на разрешённом внешнем этапе. Составьте эталон вручную, включите неоднозначные случаи и попытки встроить инструкции в публичный текст.

Измеряйте не только скорость отдельного API-вызова. Нужны качество конечного ответа, доля полезных источников, время до принятого результата, расходы, число обращений к большой модели и нагрузка на человека. Отдельный критерий — отсутствие запрещённых данных в перехваченном исходящем трафике.

Проверка должна включать отказ сервиса. Тайм-аут не даёт основания отправить больше контекста или переключиться на другой внешний сервис с полной историей. Работа продолжается локально, возвращается на проверку человеку или останавливается с понятным статусом.

На дату проверки документация указывает версию jev-1.13.0. Для воспроизводимого пилота лучше фиксировать версию: алиас latest может начать отвечать иначе после обновления. Не следует переносить пороги на новую модель без повторной оценки. TypeSafe: model version, text input and language support ↗

В текущем прототипе AI Office уже есть локальная работа с документами, поиск с учётом прав доступа, проверяемые расчёты и подтверждение предложения перед созданием локальной задачи. Подключение Jev, описанный шлюз и сценарии публичного браузерного агента пока не реализованы. Это возможное развитие архитектуры, которое нужно отдельно проектировать и испытывать.

Первым кандидатом мы бы выбрали подготовку открытой справочной библиотеки. Jev помогает отбирать публичные материалы по общей рубрике; локальный ИИ использует их вместе с разрешённым внутренним контекстом. Закрытые документы не отправляются на внешний отбор, а ответы Jev не открывают доступ к новым данным.

Затем можно проверить публичный каталог или редакторский процесс. Если компания не допускает никаких внешних обращений, аналогичную роль стоит поручить локальному классификатору, ранжировщику или обычным правилам. Архитектура разделения задач полезна и без Jev.

Для AI Office ценность такой связки — в управляемой специализации. Один компонент пишет и рассуждает, другой помогает с узкими оценками, код проверяет правила, а человек подтверждает значимые действия. Начать можно с одного открытого источника, одной рубрики и понятного критерия качества — и только после проверки решать, нужен ли компании этот внешний помощник.