Forwarded from Остриков пилит агентов
Важные секции, которые должны быть в наших PRD
Плиз проверьте, что эти блоки точно есть, и давайте их располагать в след структуре, чтобы было проще читать:
1. Назначение сервиса
Формат: один абзац, который коротко описывает суть и назначение сервиса, какую задачу он решает на большом ландшафте всей системы.
Planner - отвечает за заведение и запуск новых кампаний для взаимодействия с пользователями через агентов. Отбирает пользователей по сегментам и запускает по ним кампании
2. Глоссарий основных сущностей сервиса
Формат: набор пар термин - описание. Нужно, чтобы всем говорить на одном языке дальше по документу.
Task - задача для агента на общение с пользователем с конкретной целью. Агент должен ее стартануть в определенное время, и довести до завершения
Session - сессия разговора агент-пользователь, начинается с сообщения агента и заканчивается спустя последнее сообщение человека/агента через 2 часа
3. Как внешний мир видит этот компонент
И на каком языке с ним общается. Тут детально расписывается вся внешняя апишка сервиса и другие входящие потоки данных.
4. Модель БД сервиса
Детальное описание всех таблиц, полей, смысла полей, foreign keys constraints и индексов. Пишем все - nullable/not null/default итд. Самая важная секция, max attention - самая дорогая цена ошибки
5. Sequence flow всех основных процессов
По всем процессам есть расписанная по шагам последовательность действий, которые происходят в сервисе, в четкой структуре
6. Внешние сервисы, в которые мы ходим изнутри сервиса
Все внешние системы, в которых мы дергаем ручки/отправляем файлы/пишем в чужие очереди итд.
Главное отличие от пункта 3 - в нем наш сервис как черный ящик, и мы описываем как внешний мир его видит и использует. Тут - наоборот.
- хранилище офферов - забираем оффер в json описании при заведении новой кампании
7. Мониторинги, за которыми мы будем следить и которые будут нам звонить если что-то идет не так
Пишем только криты, которые если происходят, мы в любое время дня и ночи сразу собираем звонок и решаем инцидент
- в табличке messages скопилось больше 500 сообщений от пользователей в статусе NEW, которые мы не разгребаем более 10 минут (то есть процессинг упал)
Зачем такая духота?
Важно, чтобы до программирования (передачи PRD в клод код) мы детально понимали логику будущего сервиса на всех уровнях, без участков "ну тут хуле делать, пусть клод сам затащит"
Второй момент - верю, что при идеально написанном PRD клод будет писать сервис за один промт, а потом потребуется лишь незначительная шлифовка. Если не пишет, будем править claude.md, пока не напишет))
И последнее, ваш PRD может иметь другие доп секции, но убедитесь что текущие присутствуют обязательно и оформлены один в один в том же формате
———
Сидел потел, пробовал оцифровать правила наших PRD для будущих сервисов, без помощи нейронок 🫠
Есть что-то важное, что забыл? За лучший комментарий отправлю Кабанчика бесплатно по России (без шуток)
#prd
Плиз проверьте, что эти блоки точно есть, и давайте их располагать в след структуре, чтобы было проще читать:
1. Назначение сервиса
Формат: один абзац, который коротко описывает суть и назначение сервиса, какую задачу он решает на большом ландшафте всей системы.
Planner - отвечает за заведение и запуск новых кампаний для взаимодействия с пользователями через агентов. Отбирает пользователей по сегментам и запускает по ним кампании
2. Глоссарий основных сущностей сервиса
Формат: набор пар термин - описание. Нужно, чтобы всем говорить на одном языке дальше по документу.
Task - задача для агента на общение с пользователем с конкретной целью. Агент должен ее стартануть в определенное время, и довести до завершения
Session - сессия разговора агент-пользователь, начинается с сообщения агента и заканчивается спустя последнее сообщение человека/агента через 2 часа
3. Как внешний мир видит этот компонент
И на каком языке с ним общается. Тут детально расписывается вся внешняя апишка сервиса и другие входящие потоки данных.
POST /api/v1/offers/create - добавление нового оффера
{"offer_type": "bonus100", "offer_name": "xyz", ...}
PUT /api/v1/campaign/start - ручной запуск компании
{"id": "ieur-er4r4r-4r4"}
4. Модель БД сервиса
Детальное описание всех таблиц, полей, смысла полей, foreign keys constraints и индексов. Пишем все - nullable/not null/default итд. Самая важная секция, max attention - самая дорогая цена ошибки
== tasks (задачи на общение с пользователями) ==
id: bigint - pk
user_uuid: text - index
created_at: timestamp
...
== messages (сообщения чатов) ==
id: bigint - pk
task_id: bigint (fk -> tasks.id) - index
text: text // текст сообщения
role: test // автор сообщения, человек или агент
created_at: timestamp
...
id_task_id - unique constarint
5. Sequence flow всех основных процессов
По всем процессам есть расписанная по шагам последовательность действий, которые происходят в сервисе, в четкой структуре
1. Горутина обработки ответа на сообщение
- подтягиваем прошлую историю переписки из кеша переписок, если кеш пуст, достаем из messages)
- достаем заранее созданные инстанс агента из мапы агентов
- достаем информацию (user context) по пользователю из кеша пользователей (если нет, идем в avalon за данными)
- динамически собираем промт агента, добавляя туда историю, данные пользователя
- запускаем цикл агента, получаем новое сообщение
- сообщение сохраняем в messages + кеш
- отправляем сообщение в whatsup gateway
2. Создание новой кампании
...
6. Внешние сервисы, в которые мы ходим изнутри сервиса
Все внешние системы, в которых мы дергаем ручки/отправляем файлы/пишем в чужие очереди итд.
Главное отличие от пункта 3 - в нем наш сервис как черный ящик, и мы описываем как внешний мир его видит и использует. Тут - наоборот.
- хранилище офферов - забираем оффер в json описании при заведении новой кампании
7. Мониторинги, за которыми мы будем следить и которые будут нам звонить если что-то идет не так
Пишем только криты, которые если происходят, мы в любое время дня и ночи сразу собираем звонок и решаем инцидент
- в табличке messages скопилось больше 500 сообщений от пользователей в статусе NEW, которые мы не разгребаем более 10 минут (то есть процессинг упал)
Зачем такая духота?
Важно, чтобы до программирования (передачи PRD в клод код) мы детально понимали логику будущего сервиса на всех уровнях, без участков "ну тут хуле делать, пусть клод сам затащит"
Второй момент - верю, что при идеально написанном PRD клод будет писать сервис за один промт, а потом потребуется лишь незначительная шлифовка. Если не пишет, будем править claude.md, пока не напишет))
И последнее, ваш PRD может иметь другие доп секции, но убедитесь что текущие присутствуют обязательно и оформлены один в один в том же формате
———
Сидел потел, пробовал оцифровать правила наших PRD для будущих сервисов, без помощи нейронок 🫠
Есть что-то важное, что забыл? За лучший комментарий отправлю Кабанчика бесплатно по России (без шуток)
#prd
Forwarded from SimpleAGI
Собеседование на AI-инженера в банк: три вещи, которые реально проверяют
Собрал в кучу инфу по теме AI-инженера. "Горячая" тема, судя по рилсам)
Типичная вакансия: Python, LLM, RAG, агенты, production. Но на собесе не проверяют знание этих слов. Проверяют три вещи:
1. Trade-off мышление - не "лучший подход", а "лучший для этой ситуации"
2. Production-фокус - как это будет жить, ломаться и стоить денег
3. Язык домена - говоришь ли ты на языке бизнеса, а не только на языке ML
___
1. Trade-off мышление
Нет "лучшего" решения. Есть решение, оптимальное для конкретных ограничений.
Chunking в RAG
Зрелый ответ: "Зависит от типа вопросов. Для фактовых - мельче, для аналитических - крупнее."
Retrieval
В проде почти всегда hybrid - потому что dense пропускает точные совпадения (аббревиатуры, коды), а sparse не понимает семантику.
Агент vs Граф
Для банка граф почти всегда лучше - регулятор любит предсказуемость.
Треугольник оптимизации
- Streaming - реальная latency та же, но UX кардинально лучше
- Кэширование мгновенные ответы, но риск устаревших данных
- Роутинг по сложности простые вопросы на дешёвую модель. 80% запросов обычно простые - экономия существенная
- Reranking - quality +, но latency -
___
2. Production-фокус
Сделать прототип — легко. Поддерживать систему, которая не деградирует - сложно.
Что может пойти не так
Безопасность агентов
Loop guard - мастхэв. Агент может решить, что ему нужно 50 вызовов API на простой вопрос.
Verifier - обязательный компонент
Собрал в кучу инфу по теме AI-инженера. "Горячая" тема, судя по рилсам)
Типичная вакансия: Python, LLM, RAG, агенты, production. Но на собесе не проверяют знание этих слов. Проверяют три вещи:
1. Trade-off мышление - не "лучший подход", а "лучший для этой ситуации"
2. Production-фокус - как это будет жить, ломаться и стоить денег
3. Язык домена - говоришь ли ты на языке бизнеса, а не только на языке ML
___
1. Trade-off мышление
Нет "лучшего" решения. Есть решение, оптимальное для конкретных ограничений.
Chunking в RAG
| Стратегия | Плюс | Минус | Когда выбирать |
|----------------|--------------------|--------------------|--------------------------|
| Мелкие чанки | Точнее поиск | Теряем контекст | Фактовые вопросы |
| Крупные чанки | Больше контекста | Шум в retrieval | Аналитические вопросы |
| Parent-child | И точность, и контекст | Два индекса, сложнее | Когда критично качество |
Зрелый ответ: "Зависит от типа вопросов. Для фактовых - мельче, для аналитических - крупнее."
Retrieval
| Метод | Плюс | Минус |
|------------------|----------------------|------------------------------------------|
| Dense (векторный) | Понимает семантику | Может пропустить exact match |
| Sparse (BM25) | Точный match | "РКО" ≠ "расчётно-кассовое обслуживание" |
| Hybrid | Лучшее из двух | Сложнее настройка |
В проде почти всегда hybrid - потому что dense пропускает точные совпадения (аббревиатуры, коды), а sparse не понимает семантику.
Агент vs Граф
| Подход | Плюс | Минус |
|---------------------|-------------------------------|-------------------------------------------------|
| Свободный агент | Гибкость | Непредсказуемость, дорого, сложно тестировать |
| Граф (state machine) | Воспроизводимость, аудируемость | Нужно продумать все пути заранее |
Для банка граф почти всегда лучше - регулятор любит предсказуемость.
Зрелый ответ: "Сначала смотрю, можно ли графом. Агент - когда реально нужна гибкость, а не красивая архитектура."
Треугольник оптимизации
QUALITY
△
/|\
/ | \
▽──┴──▽
LATENCY COST
- Streaming - реальная latency та же, но UX кардинально лучше
- Кэширование мгновенные ответы, но риск устаревших данных
- Роутинг по сложности простые вопросы на дешёвую модель. 80% запросов обычно простые - экономия существенная
- Reranking - quality +, но latency -
___
2. Production-фокус
Сделать прототип — легко. Поддерживать систему, которая не деградирует - сложно.
Что может пойти не так
| Проблема | Что происходит | Как заметить |
|-------------------|------------------------------------------|--------------------------------------|
| Устаревший индекс | Регламенты обновились, база старая | Рост ответов "информации нет" |
| Изменение модели | Провайдер обновил модель | Скачок метрик после апдейта |
| Падение интеграций | CRM или бэкенд недоступен | Рост таймаутов |
| Смена паттернов | Пользователи спрашивают о новом | Незнакомые вопросы в логах |
Безопасность агентов
| Механизм | Зачем |
|-------------------|--------------------------------------------------|
| Allowlist tools | Только разрешённые инструменты |
| Loop guard | Лимит шагов, времени, стоимости |
| Human-in-the-loop | Подтверждение на чувствительных действиях |
Loop guard - мастхэв. Агент может решить, что ему нужно 50 вызовов API на простой вопрос.
Verifier - обязательный компонент
Generate → Verify → Respond
Forwarded from Остриков пилит агентов
This media is not supported in your browser
VIEW IN TELEGRAM
Кто на стажировку в команду Claude Cowork к Борису Черни?
Только не в Claude Cowork, а в LocalDesk.
И не к Борису, а к Валере @neuraldeep
Если вдруг кто пропустил, Валера Ковальский и куча народа уже 10 дней пилят свой Cowork, который работает на вашем компе на любых моделях.
https://github.com/vakovalskii/LocalDesk
https://t.iss.one/neuraldeep/1858
https://t.iss.one/neuraldeep/1874
Как задрот агентских циклов, давно хотел закопаться, как все устроено, только сегодня с утра дошли руки:
- в каждый запрос к LLM передаётся 15-45 tool definitions в зависимости от настроек - модель видит все доступные инструменты сразу (удачи слабым моделькам на 45 тулах☕️ )
- цикл работает до тех пор, пока в ответе есть tool_calls - если массив пустой, выводим финальный ответ и завершаемся
- ответ читаем в режиме стриминга: текст пушим в UI сразу, но tool_calls накапливаем - аргументы приходят чанками, JSON парсим только после полного ответа
- модель может вернуть несколько tool calls в одном ответе (parallel_tool_calls: true), но выполняем их строго последовательно через for await - параллелизация не реализована💡
- после выполнения каждого tool результат добавляется в массив messages как { role: 'tool', content: output }, на следующей итерации модель видит полный контекст
- контекст растёт монотонно: system prompt + все user messages + все assistant messages + все tool results, truncation и summarization отсутствуют💡
- tool results не обрезаются - если read_file вернул 5000 строк, все 5000 строк попадают в контекст💡
- loop detection: sliding window из 5 последних вызовов, если 5 подряд одинаковых tool names - инжектим hint "Попробуй другой подход", даём 5 retry, потом принудительный стоп
- batch tool calls (2+ инструмента в одном ответе) сбрасывают счётчик loop detection - считаются намеренным поведением модели
- не можем отправить новое сообщение, чтобы дать подсказку агенту в середине цикла, должны отменить выполнение или дожидаться конца💡
Очень круто! Но самое крутое впереди. Многие спрашивают, как вкатиться в разработку агентов, с чего начать. Можно начать с простых примеров на коленке, которые были в этом посте. Но это ни разу не похоже на продакшен, просто мини проектики, пощупать самую основу.
А LocalDesk - похоже.
Смотрите, в тех местах, где стоят💡 можно придти и сделать лучше - оптимизировать расход токенов, увеличить скорость за счет параллельности, сделать компакшен контекста.
Хотите более серьезных приключений - можно сделать субагентов, поддержать MCP, прикрутить донаты в конце концов!
Кстати, именно так и выглядит реальная разработка агентов в проде, на само ядро не тратится много времени, а на управление памятью, оптимизации контекста, детализацию в логах, трассировки - полно. А потом еще начинаются корзинки и evals, и совсем потрачено…
Так что если кто-то хотел "поизучать агентов пару часиков на выхах", вот самый лучший способ.
Еще раз ссылка на GitHub
И чатик, где идет движуха: @neuraldeepchat
———
Пойду тоже запилю что-то, а то Валера здороваться перестанет...
Только не в Claude Cowork, а в LocalDesk.
И не к Борису, а к Валере @neuraldeep
Если вдруг кто пропустил, Валера Ковальский и куча народа уже 10 дней пилят свой Cowork, который работает на вашем компе на любых моделях.
https://github.com/vakovalskii/LocalDesk
https://t.iss.one/neuraldeep/1858
https://t.iss.one/neuraldeep/1874
Как задрот агентских циклов, давно хотел закопаться, как все устроено, только сегодня с утра дошли руки:
- в каждый запрос к LLM передаётся 15-45 tool definitions в зависимости от настроек - модель видит все доступные инструменты сразу (удачи слабым моделькам на 45 тулах
- цикл работает до тех пор, пока в ответе есть tool_calls - если массив пустой, выводим финальный ответ и завершаемся
- ответ читаем в режиме стриминга: текст пушим в UI сразу, но tool_calls накапливаем - аргументы приходят чанками, JSON парсим только после полного ответа
- модель может вернуть несколько tool calls в одном ответе (parallel_tool_calls: true), но выполняем их строго последовательно через for await - параллелизация не реализована
- после выполнения каждого tool результат добавляется в массив messages как { role: 'tool', content: output }, на следующей итерации модель видит полный контекст
- контекст растёт монотонно: system prompt + все user messages + все assistant messages + все tool results, truncation и summarization отсутствуют
- tool results не обрезаются - если read_file вернул 5000 строк, все 5000 строк попадают в контекст
- loop detection: sliding window из 5 последних вызовов, если 5 подряд одинаковых tool names - инжектим hint "Попробуй другой подход", даём 5 retry, потом принудительный стоп
- batch tool calls (2+ инструмента в одном ответе) сбрасывают счётчик loop detection - считаются намеренным поведением модели
- не можем отправить новое сообщение, чтобы дать подсказку агенту в середине цикла, должны отменить выполнение или дожидаться конца
Очень круто! Но самое крутое впереди. Многие спрашивают, как вкатиться в разработку агентов, с чего начать. Можно начать с простых примеров на коленке, которые были в этом посте. Но это ни разу не похоже на продакшен, просто мини проектики, пощупать самую основу.
А LocalDesk - похоже.
Смотрите, в тех местах, где стоят
Хотите более серьезных приключений - можно сделать субагентов, поддержать MCP, прикрутить донаты в конце концов!
Кстати, именно так и выглядит реальная разработка агентов в проде, на само ядро не тратится много времени, а на управление памятью, оптимизации контекста, детализацию в логах, трассировки - полно. А потом еще начинаются корзинки и evals, и совсем потрачено…
Так что если кто-то хотел "поизучать агентов пару часиков на выхах", вот самый лучший способ.
Еще раз ссылка на GitHub
И чатик, где идет движуха: @neuraldeepchat
———
Пойду тоже запилю что-то, а то Валера здороваться перестанет...
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DziS Science | Data Science
Привет всем!👋
Когда мы говорим про длительные вычисления, всегда заходит речь о кешировании результатов выполнения.
И лучшим решением является сохранение кэша не в оперативной памяти (как это делает
Итак,
При вызове декоратор хэширует аргументы функции и проверяет, есть ли результат для хэша на диске. Если есть, то моментально загружает с диска и возвращает результат. В противном случае декоратор сохраняет результат на диск и возвращает результат.
Разберем на примере:
🔸 Создаем объект памяти, куда будем сохранять наш кэш. За путь к кэшу отвечает атрибут
🔸 Декорирование функции происходит с помощью декоратора
🔸 Запустим тест 1 раз
🔸 Код будет исполняться 10 секунд. Второй запуск уже будет использовать результаты кеширования:
🔸 Код будет только разгружать уже предварительно рассчитанный результат работы модели.
✔️ В качестве дополнительных техник можно использовать сжатие с помощью
✔️ Также, часто мы передаем в функцию аргументы, которые не влияют на результат вычислений, но меняют хеш. Например, флаг
Например для какой-то функции
Однако, есть и неприятные эффекты.
❌ Например, если внутри функции есть np.random без фиксации сида, кэширование "заморозит" первое случайное значение навсегда. Это может убить эксперимент.
Кэш можно удалить классическим
По традиции, ставь 🔥, если понравилось!
#ds_лайфхаки
Когда мы говорим про длительные вычисления, всегда заходит речь о кешировании результатов выполнения.
И лучшим решением является сохранение кэша не в оперативной памяти (как это делает
functools.lru_cache), а запись на диск с помощью joblib.Memory.Итак,
joblib.Memory - декоратор, который оборачивает функцию, сохраняя кэш напрямую на диск. При вызове декоратор хэширует аргументы функции и проверяет, есть ли результат для хэша на диске. Если есть, то моментально загружает с диска и возвращает результат. В противном случае декоратор сохраняет результат на диск и возвращает результат.
Разберем на примере:
locationfrom joblib import Memory
import time
import numpy as np
memory = Memory(location='./cache_store', verbose=0)
@memory.cache. Для примера обернем очень "тяжелую" функцию, которая спит 10 секунд.@memory.cache
def foo(x, y):
time.sleep(10)
return x**2 + y**2
x,y = np.ones((1000, 1)), np.ones((1000, 1))
res1 = foo(x,y)
x,y = np.ones((1000, 1)), np.ones((1000, 1))
res2 = foo(x,y)
compress, задавая параметр от 1 до 9, который держит баланс между скоростью чтения и размером.memory = Memory(location='./.cache_store', verbose=0, compress=3)
verbose или количество потоков n_jobs. Если ты изменишь verbose=True на verbose=False, joblib подумает, что аргументы изменились, и пересчитает всё заново. Это нам не надо.Например для какой-то функции
process_data@memory.cache(ignore=['verbose', 'n_jobs'])
def process_data(data, param=1, verbose=False, n_jobs=4):
...
Однако, есть и неприятные эффекты.
Кэш можно удалить классическим
rm -rf, либо программно memory.clear(warn=False)По традиции, ставь 🔥, если понравилось!
#ds_лайфхаки
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from КПД
На GPU Mode недавно вышла 3-х часовая лекция про RL, Агентов и фреймворк для создания и работы со средами OpenEnv.
Выступают рассказчики из unsloth, лицехватс и разработчики торча.
Довольно содержательно и познавательно. В частности, разбираются характерные нюансы и проблемы обучения с подкреплением.
Выступают рассказчики из unsloth, лицехватс и разработчики торча.
Довольно содержательно и познавательно. В частности, разбираются характерные нюансы и проблемы обучения с подкреплением.
Forwarded from КПД
Качественный и иллюстративный получасовой видеообзор субквадратичных аналогов внимания.
В частности, разобраны:
• Linear Attention
• Gated Linear Attention
• Gated Delta Net
• Titan
В частности, разобраны:
• Linear Attention
• Gated Linear Attention
• Gated Delta Net
• Titan
Forwarded from Голос из-под шторки | Миша Левченко
Мозгосвалка
Когда тебе понятно, зачем выступаешь и для кого (и даже может на какой площадке) – самое время для мозгосвалки. Этот простой приём помогает набрать контента для доклада.
Для этого приёма сначала находишь любую свободную максимально неструктурированную поверхность. Можно любую программу для вайтбординга (например, мне нравятся freeform и excalidraw), можно большой лист нелинованой бумаги. Я предпочитаю использовать рукописные медиумы а не печатать, потому что так веселее и можно что-то порисовать.
Затем пишешь посередине листа тему доклада в том виде, в котором она есть у тебя в голове, большими красивыми буквами. Почему большими и красивыми? Чтобы чуть-чуть расписаться. А затем начинаешь делать буквально то, что описано в названии приёма: сваливать туда свой мозг.
Фигачить просто всё что знаешь по теме и всё что может быть связано с нею. Быть может, прикрепишь туда какие-то заметки. А может – вспомнишь анекдот в тему. Или нарисуешь эскиз схемы, которая поможет описать концепцию более понятно для слушателя.
После того как борда наполнена идеями, можно будет потихоньку начинать заниматься самой главной работой при составлении доклада – искать структуру и опорную метафору. Но сейчас важно выплеснуть как можно больше, потому что отрезать лишнее проще чем высасывать доп контент по требованию.
Ниже пример парочки моих борд для докладов которые я не так давно готовил. Если готовишь сейчас какой-то доклад – делись в комментах.
Когда тебе понятно, зачем выступаешь и для кого (и даже может на какой площадке) – самое время для мозгосвалки. Этот простой приём помогает набрать контента для доклада.
Для этого приёма сначала находишь любую свободную максимально неструктурированную поверхность. Можно любую программу для вайтбординга (например, мне нравятся freeform и excalidraw), можно большой лист нелинованой бумаги. Я предпочитаю использовать рукописные медиумы а не печатать, потому что так веселее и можно что-то порисовать.
Затем пишешь посередине листа тему доклада в том виде, в котором она есть у тебя в голове, большими красивыми буквами. Почему большими и красивыми? Чтобы чуть-чуть расписаться. А затем начинаешь делать буквально то, что описано в названии приёма: сваливать туда свой мозг.
Фигачить просто всё что знаешь по теме и всё что может быть связано с нею. Быть может, прикрепишь туда какие-то заметки. А может – вспомнишь анекдот в тему. Или нарисуешь эскиз схемы, которая поможет описать концепцию более понятно для слушателя.
После того как борда наполнена идеями, можно будет потихоньку начинать заниматься самой главной работой при составлении доклада – искать структуру и опорную метафору. Но сейчас важно выплеснуть как можно больше, потому что отрезать лишнее проще чем высасывать доп контент по требованию.
Ниже пример парочки моих борд для докладов которые я не так давно готовил. Если готовишь сейчас какой-то доклад – делись в комментах.
Forwarded from эйай ньюз
Qwen 3 TTS
Алибаба опубликовала веса модели для синтеза голоса с 0.6B и 1.7B параметров. Веса идут в нескольких вариантах: Voice Design позволяет запромптить желаемый голос, Custom Voice идёт с 9 готовыми голосами для китайского, английского, корейского и японского. Кроме этого опубликовали базовые веса модели, для клонирования голосов и как основу для файнтюна.
Модель тренировали на 5 миллионах часов аудио на 10 языках, в том числе русском. Поддержка модели уже есть в vLLM и mlx audio, кроме этого она доступна по API.
Веса
Демо
Блогпост
@ai_newz
Алибаба опубликовала веса модели для синтеза голоса с 0.6B и 1.7B параметров. Веса идут в нескольких вариантах: Voice Design позволяет запромптить желаемый голос, Custom Voice идёт с 9 готовыми голосами для китайского, английского, корейского и японского. Кроме этого опубликовали базовые веса модели, для клонирования голосов и как основу для файнтюна.
Модель тренировали на 5 миллионах часов аудио на 10 языках, в том числе русском. Поддержка модели уже есть в vLLM и mlx audio, кроме этого она доступна по API.
Веса
Демо
Блогпост
@ai_newz
Forwarded from дAI потестить!
Ищем модельки для ComfyUI на автомате
Я устал искать модели для чужих ворков в ComfyUI, поэтому запилил GPT's. Кидаешь json - получаешь ссылки на модельки и путь к ним в ComfyUI (потому что заботушка). Ничего лишнего - только список.
А здесь оставлю промпт для ненавистников GPT's (поддерживаю):
P.S. Gemini pro справляется более чем. Остальные не тестил.
Я устал искать модели для чужих ворков в ComfyUI, поэтому запилил GPT's. Кидаешь json - получаешь ссылки на модельки и путь к ним в ComfyUI (потому что заботушка). Ничего лишнего - только список.
А здесь оставлю промпт для ненавистников GPT's (поддерживаю):
Роль: ты парсер ComfyUI workflow (JSON). Вход: полный JSON воркфлоу ComfyUI (как в export). Задача: найти все модели/файлы, которые используются в воркфлоу, и вывести для каждой: название файла/модели → папка ComfyUI → прямая ссылка(и) на скачивание. Где искать в JSON: по нодам загрузки моделей (Loader/Checkpoint/VAE/Lora/ControlNet/CLIP/UNet/IPAdapter/Embedding/Upscale и т.п.) по полям, где встречаются имена файлов: ckpt_name, checkpoint, model_name, vae_name, lora_name, control_net_name, clip_name, clip_vision_name, unet_name, ipadapter_name, embedding, upscale_model, а также любые строки с расширениями .safetensors .ckpt .pt .pth .bin .onnx Нормализуй и дедуплицируй: одинаковые файлы выводи 1 раз. Для каждой найденной модели определи папку назначения в ComfyUI: Checkpoint/CheckpointLoader → ComfyUI/models/checkpoints/ VAE/VAE Loader → ComfyUI/models/vae/ LoRA → ComfyUI/models/loras/ ControlNet/T2I-Adapter → ComfyUI/models/controlnet/ Embedding/Textual Inversion → ComfyUI/models/embeddings/ Upscaler/ESRGAN/SwinIR → ComfyUI/models/upscale_models/ CLIP → ComfyUI/models/clip/ CLIP Vision → ComfyUI/models/clip_vision/ UNet/Diffusion model (SD3/FLUX и т.п.) → ComfyUI/models/unet/ (если в воркфлоу явно указан другой тип — подбери ближайшую стандартную папку) IP-Adapter → ComfyUI/models/ipadapter/ Ссылки на скачивание: если в имени есть явный источник/репо — используй его иначе найди самую вероятную официальную страницу/файл (приоритет: HuggingFace → GitHub Releases → официальный сайт → Civitai) и дай прямую ссылку на файл (или страницу, если прямой ссылки нет) Формат ответа: только список, по 1 строке на модель: - <Тип> — <Имя файла/модели> — <Папка ComfyUI> — <Ссылка(и)> Никаких пояснений, абзацев, таблиц, пролога/эпилога — только список.
P.S. Gemini pro справляется более чем. Остальные не тестил.
Forwarded from Data Blog
Материалы для чтения.
Вчера потребовалось понять, как считать доверительный интервал для пропорции.
Эта задача возникает, когда у вас есть пропорция, посчитанная по N наблюдениям (скажем, число ответивших «да» в эксперименте). Дать одно число нечестно — при прочих равных эксперимент зависит от случайности. Поэтому всегда и везде, ДИ требуется.
В моем случае эта задача возникла рядом с анализом attack success rate (ASR) (успешной атаки на модель) в двух конфигурациях эксперимента. Какое-то время я изучала статьи, и меня эта метрика всегда вводила в ступор — она устоявшаяся, а меня все случаи оценки пропорций настораживают ещё от доли неправильных ответов из ML (accuracy). Поэтому, чтобы быть в ступоре поменьше (и потому что ДИ — это единственный корректный метод предоставления результата), было решено добавить больше формальности.
Обычные интервалы называются Wald intervals и проблема, которая заставила задуматься и не использовать их— это то, что в базовой постановке ДИ может выйти за [0,1], а значений больше 1 и меньше 0 для пропорции быть не должно. Эта проблема связана с симметричностью интервала.
У статистики на многое есть решение — и, оказалось, есть решение и на это. Вместо обычного ДИ, который приближает распределение пропорции нормальным, можно использовать Wilson score интервал. Интервалы Вильсона асимметричны за счет сдвига и добавления знаменателя — полная формула красиво объяснена тут. Интуитивно построение таково — если наблюдаемая пропорция близка к 0 или 1, то неопределённость в сторону границы меньше, чем в сторону центра. В питоне из коробки их тоже можно посчитать (см. statsmodels).
Пока копалась, нашла забавный учебник о том, что такое рисерч. В нем описано, как строить эксперименты, зачем ставить RQ, почему нужны доверительные интервалы и прочие базовые, но нужные вещи, которые помогают приземлиться при планировании эксперимента. Кроме того, в нем много практических задач (и в том числе объясняются те-самые-ДИ). Может, пригодится и вам.
Вчера потребовалось понять, как считать доверительный интервал для пропорции.
Эта задача возникает, когда у вас есть пропорция, посчитанная по N наблюдениям (скажем, число ответивших «да» в эксперименте). Дать одно число нечестно — при прочих равных эксперимент зависит от случайности. Поэтому всегда и везде, ДИ требуется.
В моем случае эта задача возникла рядом с анализом attack success rate (ASR) (успешной атаки на модель) в двух конфигурациях эксперимента. Какое-то время я изучала статьи, и меня эта метрика всегда вводила в ступор — она устоявшаяся, а меня все случаи оценки пропорций настораживают ещё от доли неправильных ответов из ML (accuracy). Поэтому, чтобы быть в ступоре поменьше (и потому что ДИ — это единственный корректный метод предоставления результата), было решено добавить больше формальности.
Обычные интервалы называются Wald intervals и проблема, которая заставила задуматься и не использовать их— это то, что в базовой постановке ДИ может выйти за [0,1], а значений больше 1 и меньше 0 для пропорции быть не должно. Эта проблема связана с симметричностью интервала.
У статистики на многое есть решение — и, оказалось, есть решение и на это. Вместо обычного ДИ, который приближает распределение пропорции нормальным, можно использовать Wilson score интервал. Интервалы Вильсона асимметричны за счет сдвига и добавления знаменателя — полная формула красиво объяснена тут. Интуитивно построение таково — если наблюдаемая пропорция близка к 0 или 1, то неопределённость в сторону границы меньше, чем в сторону центра. В питоне из коробки их тоже можно посчитать (см. statsmodels).
Пока копалась, нашла забавный учебник о том, что такое рисерч. В нем описано, как строить эксперименты, зачем ставить RQ, почему нужны доверительные интервалы и прочие базовые, но нужные вещи, которые помогают приземлиться при планировании эксперимента. Кроме того, в нем много практических задач (и в том числе объясняются те-самые-ДИ). Может, пригодится и вам.
corp.ling.stats
Binomial → Normal → Wilson
Introduction One of the questions that keeps coming up with students is the following. What does the Wilson score interval represent, and how does it encapsulate the right way to calculate a confid…