Hacker News Digest

Тег: #typesafe

Постов: 3

Ollaya – Ollama for open-source, Jev-style decision models (ollaya.dev) 🔥 Горячее

Ollaya — это локальная система для запуска моделей принятия решений, которая возвращает калиброванные ответы на типизированные вопросы за миллисекунды. Она работает на собственном оборудовании, поддерживает TypeSafe-совместимый API и позволяет задавать вопросы о тексте или JSON, получая структурированные ответы с вероятностями и метками риска, разрушительности и т.д. Например, модель decider:2b на RTX 4090 отвечает за 178 мс, а пятивопросный запрос к laya занимает ~10 мс end-to-end через HTTP API.

Модели Ollaya — открытые и включают laya (быстрая, мультиязычная), decider (точность на основе Qwen3.5), von (до 8192 токенов контекста), qwen3guard (безопасность) и другие. Все они работают без генерации токенов — ответ формируется за один проход forward pass. Система совместима с TypeSafe SDK: достаточно указать локальный эндпоинт и ключ, и официальные клиенты работают без изменений. Данные остаются на устройстве — идеально для обработки敏感ной информации вроде писем или тикетов. Ollaya доступна как десктопное приложение, CLI и Docker-образ для macOS, Windows и Linux, с поддержкой NVIDIA GPU через CUDA 13 (драйвер R580+). Установка — одна команда: ollaya run laya. Лицензия Apache-2.0, исходный код на GitHub.

by Ardakilic • 25 сентября 2026 г. в 18:33 • 474 points

Оригинал • HN

#apache-2.0#cuda#decider#docker#laya#nvidia#ollaya#qwen3guard#typesafe#von

Комментарии (118)

Laya показывает существенно худшую точность по сравнению с Jev (30.25 против 63.29 на jevbench), особенно на сложных запросах, где теряет уверенность и допускает ошибки. Однако она обеспечивает быструю локальную инференцию на слабом железе (например, GTX 970 с 4 ГБ VRAM), что делает её практичной для персонализированного дообучения и использования устаревшего оборудования. Её легко дообучить на собственных данных, что экономически привлекательно для пользователей, готовых потратить время на сбор корпуса. Laya работает приемлемо на простых классификациях (например, 'mans name'), но точность резко падает при усложнении запросов, в то время как Jev сохраняет стабильность. Ollaya — независимый проект, не связанный с Ollama, цель которого — расширять экосистему локальных моделей принятия решений, а не нарушать её. Пользователи отмечают, что примеры Laya слишком узкие (например, 'refund_requested'), и требуется более богатая семантика для реальных сценариев. Jev и Laya оптимизированы для калиброванных вероятностей и RL-обучения, а не являются простыми rerankers. Рекомендуется добавить метрики нулевого выстрела и задержку для объективного сравнения, поддержать CUDA 12, чтобы избежать апгрейда GPU, и рассмотреть использование kime как более быстрого инференс-движка. Некоторые считают, что для многих задач проще дообучить классификатор на собственном eval-наборе, чем использовать Laya/Jev как готовое решение. Также отмечается, что Laya — обёртка вокруг LLM, а не инновация, и что в эпоху LLM большинство «новых» решений — это лишь упаковка существующих подходов. Ollama может добавить поддержку подобных моделей в будущем, что снижает долгосрочную уникальность Laya. Производительность Laya MultiLang vs Laya En остаётся неочевидной — потенциальная область для улучшения.

OpenAI is well positioned to fast-follow Jev (arcturus-labs.com) 🔥 Горячее 💬 Длинная дискуссия

Jev от TypeSafe использует LLM как классификатор: вместо генерации текста он выдаёт вероятности токенов (например, true/false или вариантов выбора) и нормализует их в ответ. Этот подход, описанный ещё в 2025 году в посте про logprobs, позволяет получать мгновенные калиброванные решения без полной генерации. Jev быстро набрал популярность в AI Gateway от Vercel, став самой быстро adottой моделью в её истории.

Однако OpenAI уже давно использует LLM как неявные классификаторы — например, при tool calling или выборе между действиями. Если они формализуют этот подход и интегрируют его в свои модели, то смогут воспроизвести функционал Jev, добавив его в flagship-модели для быстрого принятия решений, эффективного мышления и улучшенных guardrails. Ключевой вопрос — есть ли у TypeSafe защита (моат), основанная на уникальных данных и процессах обучения. Если нет, OpenAI может быстро скопировать идею и вытеснить Jev, встроив её в свои системы для текста, изображений и речи. Diogo Almeida, CEO TypeSafe, верит, что качество модели обеспечит им долгосрочное преимущество.

by JohnBerryman • 22 сентября 2026 г. в 14:42 • 319 points

Оригинал • HN

#arcturus-labs#classification#guardrails#llm#openai#tool-calling#typesafe#vercel

Комментарии (221)

Jev не уникален: его подход — переоткрытие классификации с логитами, уже используемой в индустрии. Он легко реплицируется крупными лабораториями и open-source сообществом: альтернативы вроде Kev и vLLM достигают сопоставимой или лучшей точности, а open-weight версии появились за 24 часа. Jev не предлагает нового архитектурно — его суть в гибкости: изменение классов через промпт без переобучения, что удобнее традиционных классификаторов. Он не заменяет LLM, а дополняет их: снижает токен-потребление и ускоряет классификацию, но сложные рассуждения всё ещё требуют LLM. Преимущество Jev — в эргономике: проще и дешевле embedding-моделей для задач вроде фильтрации email. Однако он не решает фундаментальную проблему масштабной классификации — сбор качественных отрицательных примеров и калибровка. Многие считают, что энтузиазм вокруг Jev обусловлен незнанием базовых ML-техник, таких как логиты, известных давно. OpenAI и другие лаборатории могут добавить такой функционал за день — как embeddings — и сделать его стандартом. Секрет Jev, по мнению некоторых, — не в модели, а в данных и пост-тренировке с RLCD, что делает клоны на RLHF-LLM неэффективными. Открытые модели DeepSeek, Qwen и GLM с интегрированными классификаторами могут быть значимее коммерческого TypeSafe из-за доступности и настраиваемости. Самый реальный путь выживания TypeSafe — приобретение, если они быстро выпустят новые модели и станут привлекательны для крупных игроков. Для использования Jev в workflow (например, через OpenRouter) нужно проверить поддержку API с логитами и нормализацией вероятностей — это не стандарт. Jev похож на Htmx для AI: простой, фокусированный инструмент для конкретной задачи, потенциально стандарт для микросервисных AI-архитектур. Идея Jev не нова — она восходит к BART zero-shot classification и ранним моделям; её повторное открытие показывает возврат индустрии к простым, эффективным решениям.

Introducing System One Models and Jev (typesafe.ai) 🔥 Горячее 💬 Длинная дискуссия

TypeSafe AI представила System One Models — новый класс моделей, ориентированных на быстрые, структурированные решения для автоматизации, а не на генерацию текста. Их первая модель Jev доступна в раннем доступе и достигает уровня интеллекта существующих LLM на задачах типа «System One» (быстрые, типизированные решения), но работает в 100 раз быстрее и эффективнее благодаря новой архитектуре, параллельному сэмплеру и методу обучения Reinforcement Learning for Calibrated Decisions (RLCD). В отличие от LLM, Jev не генерирует строки — он выдаёт type-safe структурированные значения с калиброванными вероятностями и уверенностью, полностью исключая галлюцинации и типовые ошибки. Выход модели определён заранее (например, enum до 255 вариантов), что делает его пригодным для прямого использования в коде без парсинга и валидации.

Jev оптимизирован для задач, где нужны надёжные, быстрые решения на основе неструктурированного входа (текст, состояние программы), например, выбор действия, классификация или конфигурация. Стоимость входа — $0.042 за миллиард токенов (в 5–200 раз дешевле, чем у LLM), выход — бесплатен. Время отклика: 70–500 мс против 3–329 секунд у frontier LLM, что делает его 40–200 раз быстрее при эквивалентном интеллекте. Название отсылает к «System 1» мышлению Канемана и экономисту Уильяму Стэнли Джевонсу, чей парадокс эффективности предвещает взрыв спроса при снижении стоимости интеллекта. TypeSafe планирует расширять доступ и собирать обратную связь от разработчиков о том, какие решения стоит автоматизировать дальше.

by albelfio • 15 сентября 2026 г. в 19:25 • 1693 points

Оригинал • HN

#jev#reinforcement-learning#rlcd#systemone#type-safe#typesafe

Комментарии (459)

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

  • Спор: Jev не может 'не галлюцинировать' — он может выдавать только валидные типы, но при этом ошибаться в логике, например, вернуть корректный, но неверный ответ в классификации, что не отличается от LLM с харнессом.

  • Спор: Сравнение скорости Jev (70-500 мс) с LLM (3-329 с) обманчиво, если LLM выполняет сложный chain-of-thought, а Jev решает узкую структурированную задачу без генерации текста.

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

  • Стоимость ввода $0.042/MTok и бесплатный вывод делают Jev экономически привлекательным для масштабных задач, таких как классификация 1 млн транскриптов, где LLM были слишком дороги.

  • Jev подходит для использования в распределённых системах (например, Kafka), где только ответы с высокой уверенностью (>0.8) должны передаваться дальше, а низкоуверенные — перенаправляться на ручную проверку.

  • Совет: Для применения Jev в продакшене нужно чётко определять, что означают вероятности — они должны отражать не просто уверенность модели, а статистическую надёжность на конкретном распределении данных.

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

  • Использование Jev в качестве 'бедного ранжирования' позволяет стартапам быстро решать задачи вроде ранжирования 1000 статей по релевантности без сложных ML-пайплайнов.

  • Спор: Утверждение, что Jev — не LLM, вводит в заблуждение: документация показывает, что он основан на предобученной LLM с пост-обучением, что делает его производным, а не принципиально иным архитектурным решением.

  • Совет: Для промышленного внедрения Jev нужна интеграция через централизованные платформы (AWS Bedrock, OpenRouter), чтобы избежать сложных процессов compliance и безопасности при добавлении новых вендоров.

  • Jev особенно полезен для задач, где требуется сочетание доменного знания (например, генеалогические имена с правилами Soundex) и гибкости, которую не дают жёсткие if-else деревья.

  • Jev может быть использован для автоматического заполнения Wikidata — подавать свойства как вопросы с вариантами ответов и использовать модель для выбора наиболее вероятного значения.

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

  • Jev позволяет 'дистиллировать' знания из передовых LLM (например, GPT-6) в дешёвую и быструю модель, что делает его экономически эффективным решением для задач, не требующих генерации текста.

  • Спор: Технология Jev не нова — это похоже на GliNER или регрессионные головы на трансформерах, и подобные подходы существовали ещё до LLM, но ранее не получили внимания из-за плохого позиционирования.