Jev похожа на небольшую революцию в нейронках. Думаю, что мы еще очень много об этом услышим. Буду пробовать и разбираться как прикрутить к моим задачам
👎1
Forwarded from Федор
Jev и OpenJev: зачем агентам модель, которая не умеет говорить
Пока все соревнуются в том, кто лучше генерирует текст, TypeSafe предложила другой слой для агентных систем — Jev.
Jev не пишет ответ токен за токеном. Он получает состояние задачи и набор разрешённых решений, а возвращает одно из трёх типизированных действий:
— выбор из вариантов;
— оценку по шкале;
— ответ «да / нет»;
— плюс вероятность и confidence.
То есть вместо цепочки
можно сделать так:
Для агента это «умный if»: выбрать следующий tool или субагента, решить
Почему это интересно
Многие решения внутри агентного цикла вообще не требуют красивого текста. Нужен быстрый и строго ограниченный выбор. Jev не может вернуть вариант вне заданного списка — но это не означает, что он всегда выбирает правильный вариант. Ошибки смысла остаются, поэтому нужны
TypeSafe заявляет до 193× меньше latency и до 445× меньшую стоимость по сравнению с LLM-workflow. Это собственные eval’ы компании, а не независимый бенчмарк. Цена в early access — $0,042 за миллион входных токенов; оригинальный Jev пока закрытый и работает как внешний US API.
Аналоги уже появились
Под именем OpenJev возникло несколько независимых открытых проектов:
— один читает logits обычной Qwen3.5‑4B: модель один раз понимает контекст, затем параллельно оценивает заранее написанные варианты без генерации текста;
— другой дообучает Qwen3.5‑4B как NLI cross-encoder: «утверждение следует из текста / противоречит ему / нейтрально»;
— обычные reranker-модели решают более узкую задачу — ранжируют найденные документы, но не являются полноценным диспетчером агентного цикла.
Это не клоны Jev. У открытых вариантов пока нет доказанной калибровки вероятностей и нет гарантии, что они повторяют качество/экономику оригинала. Но как локальный decision-layer они уже интересны.
На базовом Mac mini M4 с 16 ГБ 4B-версия в Q4 поместится без проблем. Это не замена Claude/Codex, а небольшой локальный сервис перед ними: дешёво сортирует поток, а сложное и неуверенное отдаёт сильной модели.
Рабочая схема выглядит так:
Для российского корпоративного контура это особенно практично: оригинальный Jev лучше не кормить рабочими документами, а OpenJev-подобный слой можно запускать локально или воспроизводить на российском API со structured output.
Оригинальный Jev · Jev в Vercel AI Gateway · OpenJev browser lab · Qwen3.5‑4B OpenJev
Пока все соревнуются в том, кто лучше генерирует текст, TypeSafe предложила другой слой для агентных систем — Jev.
Jev не пишет ответ токен за токеном. Он получает состояние задачи и набор разрешённых решений, а возвращает одно из трёх типизированных действий:
— выбор из вариантов;
— оценку по шкале;
— ответ «да / нет»;
— плюс вероятность и confidence.
То есть вместо цепочки
LLM → JSON → парсер → retry, потому что JSON сломалсяможно сделать так:
state → Jev → choice / score / boolean → обычный код.Для агента это «умный if»: выбрать следующий tool или субагента, решить
retry / stop / ask human, оценить риск действия, отсортировать источники RAG или проверить, нужен ли ручной контроль.Почему это интересно
Многие решения внутри агентного цикла вообще не требуют красивого текста. Нужен быстрый и строго ограниченный выбор. Jev не может вернуть вариант вне заданного списка — но это не означает, что он всегда выбирает правильный вариант. Ошибки смысла остаются, поэтому нужны
other, пороги confidence и fallback на человека либо сильную LLM.TypeSafe заявляет до 193× меньше latency и до 445× меньшую стоимость по сравнению с LLM-workflow. Это собственные eval’ы компании, а не независимый бенчмарк. Цена в early access — $0,042 за миллион входных токенов; оригинальный Jev пока закрытый и работает как внешний US API.
Аналоги уже появились
Под именем OpenJev возникло несколько независимых открытых проектов:
— один читает logits обычной Qwen3.5‑4B: модель один раз понимает контекст, затем параллельно оценивает заранее написанные варианты без генерации текста;
— другой дообучает Qwen3.5‑4B как NLI cross-encoder: «утверждение следует из текста / противоречит ему / нейтрально»;
— обычные reranker-модели решают более узкую задачу — ранжируют найденные документы, но не являются полноценным диспетчером агентного цикла.
Это не клоны Jev. У открытых вариантов пока нет доказанной калибровки вероятностей и нет гарантии, что они повторяют качество/экономику оригинала. Но как локальный decision-layer они уже интересны.
На базовом Mac mini M4 с 16 ГБ 4B-версия в Q4 поместится без проблем. Это не замена Claude/Codex, а небольшой локальный сервис перед ними: дешёво сортирует поток, а сложное и неуверенное отдаёт сильной модели.
Рабочая схема выглядит так:
жёсткие правила в коде → локальный OpenJev/классификатор → сильная LLM или человек для сложных случаев.Для российского корпоративного контура это особенно практично: оригинальный Jev лучше не кормить рабочими документами, а OpenJev-подобный слой можно запускать локально или воспроизводить на российском API со structured output.
Оригинальный Jev · Jev в Vercel AI Gateway · OpenJev browser lab · Qwen3.5‑4B OpenJev
typesafe.ai
Introducing System One Models & Jev - TypeSafe AI Blog
TypeSafe AI is an AI lab building machine-native intelligence infrastructure for automation, designed to make decisions within software. Try our first System One Model, Jev, in early access.
Концепция внедрения ИИ в судах.docx
26.5 KB
Пока мы тут сидим вайбкодим, смотрите, какой документ интересный у нас приняли
😱2
Forwarded from Machinelearning
🎨 Qwen открыла веса Qwen-Image-2.1: новой модели для генерации и редактирования изображений
Модель построена на 7B-архитектуре и объединяет генерацию и редактирование в одном пайплайне.
Что умеет:
• работает сразу с несколькими референсами - до 10 изображений
• поддерживает точечное редактирование с сохранением лица, объекта или продукта
• нативно генерирует и редактирует RGBA с прозрачностью
• подходит для инфографики, панорам, virtual try-on и продуктовых изображений
• улучшена работа с текстом и типографикой
• ускорен inference, особенно для задач с несколькими входными изображениями
Qwen Image 2.1 обходит Nano Banana 2.0, но пока уступает GPT Image 2.5.
И это впечатляющий результат для модели всего на 7 млрд параметров.
https://huggingface.co/Qwen/Qwen-Image-2.1
Модель построена на 7B-архитектуре и объединяет генерацию и редактирование в одном пайплайне.
Что умеет:
• работает сразу с несколькими референсами - до 10 изображений
• поддерживает точечное редактирование с сохранением лица, объекта или продукта
• нативно генерирует и редактирует RGBA с прозрачностью
• подходит для инфографики, панорам, virtual try-on и продуктовых изображений
• улучшена работа с текстом и типографикой
• ускорен inference, особенно для задач с несколькими входными изображениями
Qwen Image 2.1 обходит Nano Banana 2.0, но пока уступает GPT Image 2.5.
И это впечатляющий результат для модели всего на 7 млрд параметров.
https://huggingface.co/Qwen/Qwen-Image-2.1
Кстати, если работаете с чем-то кроме Claude и ChatGPT посмотрите внимательнее на OpenRouter - там DeepSeek Flash отдают со скидками и без пиковых часов (от 20 до 60% экономия), GLM-5.3 Flash, кстати, стоит еще дешевле DeepSeek, а Qwen 3.8 27 раздают сейчас вообще бесплатно (также, как и модели Gemma, например, но это еще не самые популярные бесплатные локальные модели - там есть и экземпляры побольше и поумнее).
Forwarded from Data Secrets
Яндекс открыл веса новой языковой модели AliceAI-Foundation-80B-A3B-Base
Модель обучена полностью с нуля, без использования весов сторонних опенсорс-моделей. По метрикам она обходит куда более крупные DeepSeek-V4-Flash-Base и Nemotron-3-Super почти по всем направлениям, а среди открытых претрейнов лидирует на IMO AnswerBench и LiveCodeBench. Свою же предыдущую закрытую версию на 235B она обгоняет по фактам, математике, коду и длинному контексту при почти втрое меньшем числе параметров и в семь раз меньшем количестве активных.
Про то, как команда добилась таких результатов, нам удалось послушать на выступлении Екатерины Рединой в субботу на Practical ML Conf. Екатерина работает руководителем группы исследования знаний в службе качества претрейна Alice AI, и вот несколько интересных деталей, которые она раскрыла про процесс претрейна:
1. У команды был собственный scaling law: формула, которая по размеру модели и объему данных предсказывает, какие гиперпараметры (например, batch size) дадут лучший результат. Эта штука максимально важна, потому что перебирать варианты руками слишком дорого.
Чтобы проверить закон, команда обучила модель с вдвое меньшим batch size. Должно было выйти хуже. Но вышло – лучше.
Проблему искали довольно долго, а в итоге она оказалась на поверхности: сам scaling law строился на том, что модели сравнивали по лоссу, но оказалось, что лосс почти не коррелирует с бенчмарками. Все починилось после того, как инженеры пересобрали датасет для эвала.
2. Для обучения использовали оптимизатор Muon – он экономит FLOPs по сравнению с привычным AdamW, но платит за это дорогой операцией: матрицу весов нужно ортогонализовать целиком, а она у них разбита шардами по разным GPU. Значит, перед каждым шагом надо гонять данные по сети: собрать матрицу, обработать, раздать обратно.
Чтобы GPU не простаивали в ожидании, разработчики написали свой конвейер: пока одна группа карт считает ортогонализацию для одной порции весов, другая уже тащит по сети следующую – вычисления и пересылка идут параллельно. Благодаря этой схеме шаг оптимизатора ускорился почти вдвое.
3. Данные были отдельной больной темой: синтетика то и дело подкидывала забавные побочные эффекты – модель могла выучить неправильную ассоциацию всего по одному обучающему примеру. Например, в QA про возраст был скрытый шаблон: живым к ответу приписывали год рождения, а умершим сразу годы жизни. Модель выучила не факт, а сам шаблон, и на вопрос «сколько лет Тарковскому?» вместо возраста выдавала «1932–1986». Фиксили аугментацией.
4. Вместе с моделью в опенсорс выложили два фактологических бенчмарка - WikiWebFacts и HardMultiQAс акцентом на русскоязычный контекст - и протоколы их оценки.
5. AliceAI-Foundation-80B-A3B-Base – это шаг к единой рассуждающей модели (ЕРМ), на которой будут строиться агентские возможности Алисы. За дальнейшими обновлениями и другими новостями от ML-команды Яндекса можно следить в канале @MLunderhood.
Это только часть того, что рассказала Екатерина. Яндекс выпустил большой технический отчет – там подробно расписан весь путь обучения, с абляциями и разборами подводных камней.
Прочитать его полностью можно здесь: https://habr.com/ru/companies/yandex/articles/1083300/
Модель обучена полностью с нуля, без использования весов сторонних опенсорс-моделей. По метрикам она обходит куда более крупные DeepSeek-V4-Flash-Base и Nemotron-3-Super почти по всем направлениям, а среди открытых претрейнов лидирует на IMO AnswerBench и LiveCodeBench. Свою же предыдущую закрытую версию на 235B она обгоняет по фактам, математике, коду и длинному контексту при почти втрое меньшем числе параметров и в семь раз меньшем количестве активных.
Про то, как команда добилась таких результатов, нам удалось послушать на выступлении Екатерины Рединой в субботу на Practical ML Conf. Екатерина работает руководителем группы исследования знаний в службе качества претрейна Alice AI, и вот несколько интересных деталей, которые она раскрыла про процесс претрейна:
1. У команды был собственный scaling law: формула, которая по размеру модели и объему данных предсказывает, какие гиперпараметры (например, batch size) дадут лучший результат. Эта штука максимально важна, потому что перебирать варианты руками слишком дорого.
Чтобы проверить закон, команда обучила модель с вдвое меньшим batch size. Должно было выйти хуже. Но вышло – лучше.
Проблему искали довольно долго, а в итоге она оказалась на поверхности: сам scaling law строился на том, что модели сравнивали по лоссу, но оказалось, что лосс почти не коррелирует с бенчмарками. Все починилось после того, как инженеры пересобрали датасет для эвала.
2. Для обучения использовали оптимизатор Muon – он экономит FLOPs по сравнению с привычным AdamW, но платит за это дорогой операцией: матрицу весов нужно ортогонализовать целиком, а она у них разбита шардами по разным GPU. Значит, перед каждым шагом надо гонять данные по сети: собрать матрицу, обработать, раздать обратно.
Чтобы GPU не простаивали в ожидании, разработчики написали свой конвейер: пока одна группа карт считает ортогонализацию для одной порции весов, другая уже тащит по сети следующую – вычисления и пересылка идут параллельно. Благодаря этой схеме шаг оптимизатора ускорился почти вдвое.
3. Данные были отдельной больной темой: синтетика то и дело подкидывала забавные побочные эффекты – модель могла выучить неправильную ассоциацию всего по одному обучающему примеру. Например, в QA про возраст был скрытый шаблон: живым к ответу приписывали год рождения, а умершим сразу годы жизни. Модель выучила не факт, а сам шаблон, и на вопрос «сколько лет Тарковскому?» вместо возраста выдавала «1932–1986». Фиксили аугментацией.
4. Вместе с моделью в опенсорс выложили два фактологических бенчмарка - WikiWebFacts и HardMultiQAс акцентом на русскоязычный контекст - и протоколы их оценки.
5. AliceAI-Foundation-80B-A3B-Base – это шаг к единой рассуждающей модели (ЕРМ), на которой будут строиться агентские возможности Алисы. За дальнейшими обновлениями и другими новостями от ML-команды Яндекса можно следить в канале @MLunderhood.
Это только часть того, что рассказала Екатерина. Яндекс выпустил большой технический отчет – там подробно расписан весь путь обучения, с абляциями и разборами подводных камней.
Прочитать его полностью можно здесь: https://habr.com/ru/companies/yandex/articles/1083300/
Forwarded from эйай ньюз
Вышел Grok 4.7
Заметный прирост при той же цене и скорости. Маск ранее заявлял что Grok 4.7 должен быть новый претрейн на 2.1 триллиона параметров, но похоже планы поменялись. А тем временм Grok 4.8 с 2.5T параметров должен был закончить тренировку на прошлой неделе и, скорее всего, сейчас уже на стадии RL.
@ai_newz
Заметный прирост при той же цене и скорости. Маск ранее заявлял что Grok 4.7 должен быть новый претрейн на 2.1 триллиона параметров, но похоже планы поменялись. А тем временм Grok 4.8 с 2.5T параметров должен был закончить тренировку на прошлой неделе и, скорее всего, сейчас уже на стадии RL.
@ai_newz