ну, не знаю, мне недавно статью завернули в черновики. И она действительно написана с помощью ИИ. Но... на основе моих диалогов в чатах, репозитория на гитхабе, т.е. статья вполне отражала мой личный опыт, но тратить время на переписывание под хабр я не захотел
хорошая статья с пунктами, что можно вытащить из транскрипта с помощь LLM. оставил ссылку под своей статьей о том, как на домашнем компе собрать простую систему речевой аналитики https://habr.com/ru/articles/1078350/
прикольно. а) в последнее время для таких онлайн-тулов делаю webapp - удобно, что всегда типа установлено. примерhttps://antirek.github.io/markdown-viewer/ - webapp, source https://github.com/antirek/markdown-viewer б) возможно, стоит хранить в localStorage с какой-то упрощенной защитой аля пинкод 4 знака. т.к. если это утилита для повседневного использования, то хотелось бы быстро логиниться к какому-то хранилищу
да, важна, схема БД. но та, что реально лежит в проекте, а не нарисованная в документации. потому как, оп, разрабы их меняют по мере необходимости, и если у них там своя команда, и они отдельно принимают решения по архитектуре своего проекта, то ты по факту начинаешь сверять что у вас отличается. у меня в деплое как раз содержится инфо о связях с БД, чтобы понимать сколько там чего используется из железа.
ок, мне тоже "хотелось, чтобы система, её связи, сценарии и документация были одной навигационной моделью", и я ее все это хочу доставать прямо из кода. чтобы документация не догоняла. у меня такое получилось ))
вот примерно шапка моего "пульта" связи кода с железом (ниже не буду показывать, много конкретики) т.е. от репозитория мы получаем артефакты (пакеты, images) и деплоим их на контуры. при этом меня не интересует что конкретные разрабы в конкретных репозиториях пишут, рисуют и реализуют (схемы БД, openapi specs). главное,чтобы потом в деплое были указаны все связи (какие БД, какие внешние сервисы). все сущности, все связи указаны в json. к этому json и другим данным имеет доступ агент, с которым можно проговорить детали, агент в описаниях обязательно рисует схемы в mermaid - очень понятно, подробно.
С4 - вообще странная штука - с одной стороны архитектура на уровне систем, с другой схема таблиц в БД. хотя по идее это уровни разных людей. и если ты строишь архитектуру контура, то у тебя на сервисах API, которые тебе гарантируют контракты взаимодействия. а если строишь ПО, то пожалуйста, рисуй архитектуру программы, схемы БД и т.д. редактор, кстати, да прикольный.
На моей карте 5060 TI 16Gb не взлетело. Далее что мне агент написал:
"Прогнал data/mono3.wav — пайплайн отработал, расшифровки разговора нет.
Файл нормальный: 4.5 МБ, 146 с, 16 кГц mono. Модель его «услышала»: в промпт ушло 914 audio-токенов. Генерация заняла ~76 с, но текст — мусор (air bearing / flying fly / ring…), не реплики двух людей. Сырой ответ лежит в data/mono3.raw.txt.
Это не баг промпта и не «модель не умеет диаризацию». Та же установка ломается и без аудио: на вопрос «столица Франции?» в FP8, в BF16 с CPU-offload и в 8-bit отвечает кашей вроде fire fire / ]*)*.*.*. То есть декодер сейчас не генерирует связный русский текст.
Почему так на этой карте: веса GigaChat Audio 10B — ~24 ГБ BF16, в 16 ГБ VRAM они не влезают. Единственный способ загрузить модель — online FP8 в vLLM, а для DeepSeek-V3 MoE без калиброванных scale это портит маршрутизацию экспертов. Официального CUDA-кванта под Audio нет."
круто! утащил статью к себе в группу https://t.me/chottodev по разработке чатов, делаю не на matrix
круто!
ну, не знаю, мне недавно статью завернули в черновики. И она действительно написана с помощью ИИ. Но... на основе моих диалогов в чатах, репозитория на гитхабе, т.е. статья вполне отражала мой личный опыт, но тратить время на переписывание под хабр я не захотел
в gigaam нет диаризации, вот пример как можно делать диаризацию https://github.com/antirek/calls-pipeline
для Codex нужен vpn?
хорошая статья с пунктами, что можно вытащить из транскрипта с помощь LLM. оставил ссылку под своей статьей о том, как на домашнем компе собрать простую систему речевой аналитики https://habr.com/ru/articles/1078350/
у мну 2 миллиарда за месяц, и это на аккаунте без автономных агентов еще
статья помогла собрать флоу https://github.com/antirek/calls-pipeline
прикольно. а) в последнее время для таких онлайн-тулов делаю webapp - удобно, что всегда типа установлено. примерhttps://antirek.github.io/markdown-viewer/ - webapp, source https://github.com/antirek/markdown-viewer б) возможно, стоит хранить в localStorage с какой-то упрощенной защитой аля пинкод 4 знака. т.к. если это утилита для повседневного использования, то хотелось бы быстро логиниться к какому-то хранилищу
жду такую
зачем приложение? может просто веб-страничку?
круто, пробовали распознавать звонки? с диаризацией справляется?
для кого и webapp годится https://antirek.github.io/markdown-viewer/ только просмотр файлов
сохраню здесь, чтобы было, как варианты примеров
используют дату, а потом change в эту дату, такой semver+
да, важна, схема БД. но та, что реально лежит в проекте, а не нарисованная в документации. потому как, оп, разрабы их меняют по мере необходимости, и если у них там своя команда, и они отдельно принимают решения по архитектуре своего проекта, то ты по факту начинаешь сверять что у вас отличается. у меня в деплое как раз содержится инфо о связях с БД, чтобы понимать сколько там чего используется из железа.
ок, мне тоже "хотелось, чтобы система, её связи, сценарии и документация были одной навигационной моделью", и я ее все это хочу доставать прямо из кода. чтобы документация не догоняла. у меня такое получилось ))
https://youtu.be/OIlGahMszDI Chatto: ADR/FDR/architecture
вот примерно шапка моего "пульта" связи кода с железом (ниже не буду показывать, много конкретики) т.е. от репозитория мы получаем артефакты (пакеты, images) и деплоим их на контуры. при этом меня не интересует что конкретные разрабы в конкретных репозиториях пишут, рисуют и реализуют (схемы БД, openapi specs). главное,чтобы потом в деплое были указаны все связи (какие БД, какие внешние сервисы). все сущности, все связи указаны в json. к этому json и другим данным имеет доступ агент, с которым можно проговорить детали, агент в описаниях обязательно рисует схемы в mermaid - очень понятно, подробно.
С4 - вообще странная штука - с одной стороны архитектура на уровне систем, с другой схема таблиц в БД. хотя по идее это уровни разных людей. и если ты строишь архитектуру контура, то у тебя на сервисах API, которые тебе гарантируют контракты взаимодействия. а если строишь ПО, то пожалуйста, рисуй архитектуру программы, схемы БД и т.д. редактор, кстати, да прикольный.
На моей карте 5060 TI 16Gb не взлетело. Далее что мне агент написал:
"Прогнал
data/mono3.wav— пайплайн отработал, расшифровки разговора нет.Файл нормальный: 4.5 МБ, 146 с, 16 кГц mono. Модель его «услышала»: в промпт ушло 914 audio-токенов. Генерация заняла ~76 с, но текст — мусор (
air bearing / flying fly / ring…), не реплики двух людей. Сырой ответ лежит вdata/mono3.raw.txt.Это не баг промпта и не «модель не умеет диаризацию». Та же установка ломается и без аудио: на вопрос «столица Франции?» в FP8, в BF16 с CPU-offload и в 8-bit отвечает кашей вроде
fire fire/]*)*.*.*. То есть декодер сейчас не генерирует связный русский текст.Почему так на этой карте: веса GigaChat Audio 10B — ~24 ГБ BF16, в 16 ГБ VRAM они не влезают. Единственный способ загрузить модель — online FP8 в vLLM, а для DeepSeek-V3 MoE без калиброванных scale это портит маршрутизацию экспертов. Официального CUDA-кванта под Audio нет."
https://t.me/chottodev - разарабатываем компоненты для чата: ui, отдельно движок, дополнительные сервисы