Новый релиз! 🥳 Давно я нового софта не рилизил, поэтому пора! OpenRoughCut v0.1.2

Это программа для того чтобы подготавливать сырое видео к монтажу. Софт автоматически определяет тишину и вырезает ее. Так же есть возможность определить повторные дубли и оставить только последний. На выходе получаете готовый проект для своей монтажной программы где можете продолжить более точную работу.

😍 Эта штука уже экономит мне часы монтажа, так что я в диком восторге.  Есть версии по Mac и Windows, нормально тестировал только на Mac c M1 Pro процессором 😅 ✨ https://orc.yhub.net/ ✨ Проект с открытым кодом, так что если найдете баги — буду благодарен за issues на github Свята место | 10МДК | ВЕБМастер | YHub

Что-то я чувствую себя как в этом эпизоде. Я опять проверяю границы агентов. @softwarevlogger прислал мне репозиторий и сказал: «Я это сделал тремя промптами». Смотрю — а там идея пересекается с тем, что делаю я. Я просто скормил знания о своём проекте и об этом репозитории и сказал: изучи, сопоставь, а классные идеи, которых у нас нет, — укради. И fabble украл эти идеи, делегировал опусам (я, кстати, до сих пор не смотрел, но вижу, что апа постоянно перегружается и интерфейс меняется). Ещё один из опусов попросил разрешения на изменения в ридонли-системе памяти, на основе которой я всё построил. Как я понял, в своей системе поиска локальных видео я покрыл ещё один use case. Но я еще не смотрел 🤓

ИИ-Wiki: Код, продукты, жизнь (ч.1) За последние месяцы четыре разные команды реализовали одну и ту же идею Wiki для ИИ: OpenWiki, DeepWiki, AutoWiki,, GBrain. Работает просто: LLM читает набор источников, компилирует их в поддерживаемый набор markdown-страниц и обновляет эти страницы по мере изменения источников. Агенты читают эти страницы вместо того, чтобы заново выводить всё из сырого материала на каждый вопрос. Паттерн стал категорией, а системы, построенные на его основе, всё чаще называют просто «агентными вики». Вот что это такое на самом деле, что построила каждая команда, где это ломается и с чем это постоянно путают. Идея: компилировать при поступлении, а не при запросе Начнём с проблемы, потому что паттерн — прямой ответ на неё. Стандартный способ передать модели базу знаний — это поиск (retrieval). Вы загружаете документы, разбиваете на чанки и создаёте эмбеддинги, а при запросе извлекаете релевантные фрагменты и отвечаете. Это работает, но имеет структурный изъян: ничего не накапливается. Каждый вопрос начинается с сырых фрагментов, так что модель каждый раз заново выводит одно и то же понимание, и десятый вопрос о кодовой базе не дешевле и не лучше первого. LLM Wiki инвертирует этот порядок: вместо того чтобы собирать знания при запросе из сырых кусков, LLM собирает их один раз при поступлении в долговечные страницы и затем поддерживает их. Когда поступает новый источник, модель читает его, обновляет затронутые страницы, пересматривает и отмечает противоречия с уже написанным, выводя его один раз и затем обновляя. Архитектура состоит из трёх слоёв: 1) Сырые источники неизменяемы: статьи, документы, репозитории, данные. Модель читает их и никогда не редактирует. 2) Вики — это созданный LLM markdown, которым ИИ полностью управляет: резюме, страницы сущностей, концепций, перекрёстные ссылки и т.п. 3) Схема — это конфигурационный файл (CLAUDE.md, AGENTS.md или аналогичный), который сообщает модели, как организована вики и какие рабочие процессы запускать, что превращает её в проводника, а не просто в чат-бота с доступом к файлам. Над всем этим работают три операции: – приём источника и размещение его по затронутым страницам; – запрос к вики с возможностью сохранять хорошие ответы как новые страницы, чтобы исследование тоже накапливалось); – периодическая проверка, выискивающая противоречия, устаревшие утверждения и потерянные страницы. Что на самом деле построили лаборатории и различия между реализациями. DeepWiki — вики как общедоступная утилита. Замените github.com на deepwiki.com в URL любого публичного репозитория, и вы получите сгенерированную, навигабельную вики этой кодовой базы: обзор архитектуры, индекс файлов, граф зависимостей и поиск с ссылками на исходный код. AutoWiki придерживаются подхода, что документация должна быть артефактом сборки, а не побочным проектом. Она строится из исходного кода, организована вокруг того, как кодовая база работает на самом деле, и обновляется при изменении репозитория. AutoWiki выполняет двухпроходный анализ и работа распределяется между специализированными агентами, каждый из которых охватывает один аспект репозитория с достаточным контекстом для создания хорошей страницы. OpenWiki перешли от кода ко всему LangChain открыли исходный код OpenWiki и расширили его до OpenWiki Brains с двумя режимами: Code Brain — исходный вариант для репозиториев, и Personal Brain, который строит вики из ваших собственных подключённых источников. Этот второй режим — самое интересное. Personal Brain принимает данные из Gmail, Notion, git-репозиториев, X, Hacker News и веб-поиска и синтезирует их в локальную markdown-вики, к которой обращается агент. Категория перешла от «документируй мой репозиторий» к «скомпилируй мою рабочую жизнь». GBrain: персональная open-source версия GBrain применяет ту же форму к личной базе знаний, а не к кодовой базе: markdown в git-репозитории, файл схемы и автоматически поддерживаемый граф перекрёстных ссылок сущностей. Никакой векторной базы, никакого сервиса — просто файлы, которые модель и человек могут читать.

Как мы внедряли ИИ-диспетчера для ЖКХ, а получили таск-трекер для среднего бизнеса ЖК Clever Park в Екатеринбурге пришёл к нам с обычной для управляющих компаний болью: жители пишут в домовой чат, звонят диспетчеру, и всё это сыплется вперемешку. «Нет горячей воды», «не открывается шлагбаум», «сосед шумит с ремонтом» – десятки сообщений, часть из них про одно и то же. Мы собрали движок, который читает чаты жителей, объединяет дубли и раскладывает обращения по категориям. Поток заявок на живого диспетчера упал почти вдвое, чат дома стал спокойнее, а заявки обрабатываются быстрее. Дальше выяснилось, что боль системная. В России 34 000 управляющих компаний, и почти все до сих пор без инструментов оперативного реагирования, при том что за нарушение сроков и правил можно поймать штраф до 300 т.р. Так родился Домовей (https://domovey.ru/): ИИ диспетчер с таск-трекером и обработкой обращений как текстом, так и голосом. При этом рынок оказался конкурентнее, чем мы думали. Домиленд, Диспетчер24, голосовые роботы – игроков хватает. Но мы не лезем строить универсальный суперапп для девелоперов со всем на свете. Мы делаем одно: разбираем обращения быстрее и дешевле, чем существующие решения. А потом случилось неожиданное. Оказалось, та же механика нужна средним производственным компаниям, у которых вся рабочая переписка живёт в чатах. Задачи, ответственные, сроки, статусы – всё тонет в ленте Телеграма или MAX. По сути у нас получился таск-трекер, где источник задач – сам чат. Внедрять ради этого неповоротливый Битрикс мало кто хочет, и мы неожиданно стали для них альтернативой. И вот мы на перепутье: докручивать ИИ-диспетчера для ЖКХ или разворачиваться в ИИ таск-трекер для SMB? Что думаете?

В последнее время все актуальнее вопрос: а может перейти на open source модель и снизить зависимость/убрать риски, ну или сэкономить —> сделал для вас скилл по мотивам ответа на такой же вопрос для своих пайплайнов: https://github.com/BayramAnnakov/oss-migration-eval что делает: 1) анализирует самые "жирные" пайплайны 2) определяет, по какой метрике будем сравнивать модели (что такое "правильно") 3) составляет "золотой датасет", чтобы заранее определить, на каких кейсах будем сравнивать 4) берет шортлист кандидатов на основе лидербордов artificialanalysis (по качеству) и openrouter (по популярности) 5) прогоняет модели, считает точность на золотом датасете 6) (опционально) может погонять в режиме autoresearch промпты, чтобы даже на слабой модельке добиться гуд результатов 7) и советует что брать :) удачи! P.S. до выхода kimi k3 на моих пайплайнах победила kimi k2.6

Мир с ИИ лишает людей смыла или отмазок? Давайте синхронизируемся где мы сейчас находимся: 1. Любая офисная или цифровая работа может и будет автоматизирована с помощью ИИ. Это на 20% техническая задача и на 80% задача слома привычек, консенсуса и экономической диффузии. 2. Крайне маловероятно что AGI в определении "ИИ может делать любую экономически значимую задачу не хуже, чем 90% людей ей занимающихся сегодня" займет больше чем 3-4 года. 3. Это значит, что любой бизнес в цифровой сфере будет изменен до неизнаваемости. 4. ИИ не может заменить ответственность, энергию и сильное желание. 5. Корпорации нерациональны. Рациональное поведение — это радикальная перестройка того как работают компании, пересборка процессов и команд. В корпорациях мотивации разнонаправленны и мало у кого есть яйца и власть делать структурные изменения. 6. Оффлайн пока что в безопасности и будет меняться медленнее, но инновации в офлайне (роботы, сенсоры) так же ускоряются вследствие развития ИИ. Итого: старые правила перестали работать, но мир будет какое-то время. Если раньше всегда можно было ничего не делать с отмазкой, мол, родился не в той стране, родители плохие, злые, бедные, коллектив плохой, начальник дурак, то сегодня все уравнены. Сегодня лучшее время что-то создавать, потому что никогда у отдельного человека без капитала и власти не было столько ресурсов. Но создавать цифровые продукты - это воевать против гравитации, их все равно сделает ИИ лучше. Сегодня, скорее всего, последнее время в истории чтобы создавать цифровые продукты, ибо сам процесс будет автоматизирован со временем благодаря масштабным фабрикам софта и сервисных решений.

Facebook Ads MCP Если вы занимаетесь трафиком, то возможно вам пригодится. MCP-сервер для рекламы - это размещенный на хостинге Meta сервер⁠, который позволяет управлять рекламой Meta непосредственно из ИИ-агента. https://mcp.facebook.com/ads Для кого? Рекламодатели, использующие ИИ-ассистентов и желающие управлять рекламой Meta через интерфейс чата, а не через Ads Manager или программный код Разработчики, создающие рекламные рабочие процессы на основе ИИ, которым необходим структурированный доступ к возможностям рекламы. Наверное самое интересное это сигналы и A/B-тесты, но я не спец. Подробно тут: https://developers.facebook.com/documentation/ads-commerce/ads-ai-connectors/ads-mcp-server/ads-mcp-server-overview @cgevent

🤖 Nous Research разогнала Hermes Agent до скорости ртути Hermes Agent обновлён до версии v0.19.0 Quicksilver - холодный старт агента упал в 5 раз, а рискованные команды теперь одобряет отдельный ИИ-ревьюер вместо человека. Что нового: ✧ Пароли можно доставать прямо из Bitwarden и 1Password, а не из .env файла ✧ Ответ агента переживёт падение шлюза - доставка теперь гарантирована ✧ 450+ контрибьюторов и почти 2250 коммитов в одном апдейте Заодно тихо откатили собственный firewall для защиты учётных данных, который сами же выкатывали раньше. У самого масштабного релиза в истории проекта тоже есть слепые пятна. 🔗 Разобрали, что реально изменилось в крупнейшем апдейте открытого ИИ-агента ✴️ Читайте нас в MAX

Для того чтобы погонять Fable 5, пришлось вернуть подписку на Клода. В целом чувствуется, что модель сильнее Opus 4.8 (это проявляется в мелких деталях, подробнее писал в ИИ-лаборатории нашего клуба), но глобально ничего не меняется. Но вот что меня поразило, так это мои ощущения от использования Claude Code: как же я отвык от human in the loop, сидеть и постоянно контролировать - это не мое. У меня сейчас для работы сделано два оркестратора. Один реализует проектный SDLC, второй - общего назначения. Они связаны друг с другом и могут обмениваться заданиями и статусом выполнения, в общем агенте есть общий чат куда прилетают отчеты о выполнении. Развиваю проекты инкрементами, которые выглядят примерно так:

$soerdev add spec "Новая фича"
$soerdev refine spec
$soerdev plan
$soerdev run

Это реализация цикла Human ON the loop. Логика такая: добавляем драфт спеки, обсуждаем детали, фиксируем план, запускаем цикл до выполнения критериев останова. В работу не вмешиваюсь, но вижу в чате и телеграм боте что происходит. И знаете что? Это реально удобно! Теоретически что-то подобное можно настроить и в CLI-агентах, но все равно придется допиливать харнес для отправки сообщений в телеграм, делать свой аналог гейтов, делать скилы и промпты. А так все зашито в оркестратор soerdev.

Почему при обеднении домохозяйств проблемы возникают даже у B2B/B2G бизнеса и причем тут ИИ Сегодня я хочу обсудить, как сокращение персонала в больших масштабах повлияет на B2B бизнесы. Не буду полемизировать, насколько я верю в масштаб сокращений людей из-за ИИ. Предположим, что производители LLM правы. В итоге будут сокращены десятки процентов людей. И предположим, что эти люди не найдут новой работы. Я знаю предпринимателей, которые смотрят на все это и говорят: “Ну да, люди потеряют работу. Мне то какое дело. Я ведь продаю в B2B/B2G”. Сегодня я хочу вам показать, что это будет для вас проблема тоже. Есть такая формула расчета ВВП страны по расходам. По этой формуле ВВП - это сумма конечного потребления домохозяйств, инвестиций, государственных расходов и чистого экспорта (экспорт минус импорт). Интересно в этой формуле то, что все слагаемые в конечном счете оплачены домохозяйствами. Инвестиции нужны, чтобы создать средства производства, которые потом станут частью себестоимости продукции, то есть это часть, которую домохозяйства оплатят в будущем. Государственные расходы - это собранные налоги, причем налоги компаний будут заложены в себестоимость продукции, которые купят домохозяйства. Чистый экспорт - это расходы домохозяйств в другой стране. Почему смотрим на ВВП? Потому выручка всех компаний в нем учтена. Теперь возвращаемся к вашей B2B/B2G компании. Ваша выручка становится себестоимостью другой компании, а их выручка - себестоимостью другой компании, и так до того момента, пока товар не купит домохозяйство. Если у домохозяйств становится меньше денег, они меньше покупают. Таким образом рано или поздно упадет и ваша выручка. Если произошло краткосрочное снижение доходов, то можно взять кредит. Государство может выпустить больше займов. Можно проинвестировать впрок до тех пор, пока экономика и доходы домохозяйств восстановятся. Но ИИ-оптимисты же говорят не об этом. Они говорят, что десятки процентов людей потеряют работу навсегда. Соответственно если они не получат другую работу или на них не свалятся дивиденды, то им нечего будет тратить. Теперь посмотрим на компании, которые сократили людей. Допустим, они сократили 10% расходов. Часть этих денег они отдадут LLM-провайдерам (обычно 10-20% от сэкономленного, то есть 1-2%). Остальное выплатят в виде дивидендов своим акционерам. Акционеры могут потратить эти деньги на машины, дома, яхты. Но у этих расходов есть предел. И чем богаче человек, тем больший процент дохода уходит на инвестиции, то есть в создание средств производства, а не на потребление.  А теперь представьте, что эта ситуация длится десятилетиями. Нет смысла инвестировать в средства производства, которые будут делать продукцию, которую никто не купит. В лучшем случае будут стоять заброшенными цеха. Либо их будут демонтировать, как сейчас целыми кварталами демонтируют недостроенную недвижимость в Китае (это прям отдельно интересная история, но лучше почитайте профильных экономистов). Зачем я рассказал вам это? Если хотите, чтобы у вашего бизнеса было все хорошо, все хорошо должно быть и у ваших клиентов, и у обычных людей, которые живут рядом с вами. Это не значит, что не нужно оптимизировать процессы в вашей компании и повышать производительность труда. Но полезно помнить, что если все будут заняты только этим, если всем будет плевать на то, найдут ли сокращенные вами люди работу, то рано или поздно костлявая невидимая рука рынка дотянется и до благополучия вашей компании и вашего собственного благополучия. Подумайте об этом. Возможно вам придут идеи, как вы можете сбалансировать ситуацию.  Но есть и хорошая новость. Я верю, что у этой задачи есть решение. Нужно только хорошенько подумать. Как говорила Сарра Коннор: “Будущее не определено”. От нас с вами зависит то, как будут жить наши дети. Плодотворных вам размышлений! #economicsforstartups

Sales Navigator и ИИ-агенты для современного лидгена Sales Navigator – это отдельный платный модуль в LinkedIn, который содержит в себе мини-CRM, кастомные ленты и даже свой внутренний мессенджер. Но главная ценность Sales Nav – это конечно же поиск с 50+ фильтрами (здесь можно почитать разбор по фильтрам и даже посмотреть видео). Sales Nav по задумке Linkedin нельзя экспортировать. Т.е. у Linkedin предусмотрен экспорт, но только на самом дорогом плане и только в определённые CRM системы: Salesforce, HubSpot, и Microsoft Dynamics. И никто его никогда не использует. Поэтому на рынке были исторически десятки сервисов, которые позволяли парсить Sales Nav из-под своего аккаунта: LinkedHelper, Evaboot, Phantombuster, Getprospect и т.д. Мы пользовались GetProspect, но конкретно у этого инструмента были 2 минуса: 1/ у него случаются ошибки время от времени (например, он выдумывает, совершенно неправильную компанию или должность человека), 2/ как у всех туллов для автоматизации из-под собственного аккаунта, есть риск блокировок. С развитием ИИ-агентов вопрос с парсингом Sales Nav стал решаться в разу проще. Почему? 1/ Тебе не нужна больше выбрасывать $100-120 за подписку и за инструмент (еще долларов $15-50 сверху) 2/ Ты не рискуешь своим аккаунтом, т.к. всё работает программно из-под специально сделанных для этого профилей Сейчас на RapidAPI есть три разных актора, к которым “цепляются” ваши ИИ-агенты и достают нужные вам данные (Раз, Два и Три). Причём такие объёмы, которые можно доставать через RapidAPI, раньше нам и не снились – от 25,000 контактов в сутки. Причём можно вообще обходиться без собственного доступа к Sales Nav, т.к. У акторов есть MCP, через который агент сам может собрать нужную ссылку. Так что когда есть доступ к таким инструментам, уже и сам доступ к Sales Nav как-будто становится не так уж и нужен. #li_outreach #email_outreach

ЭВМ в народном хозяйстве: поколения, тяжёлая промышленность и энергетика К началу 80-х у «Татнефти» работала иерархическая трёхуровневая система, где датчики на скважинах связывались с кустовыми вычислительными центрами, а те сходились на сердце всего хозяйства в Альметьевске. Локальная сеть тянулась не по одному зданию, а между десятками объектов на сотни километров. По тем временам считайте интернет, только за 15 лет до отраслевой модели уровней, которую промышленность опишет позже. Проблема была в последней миле. До каждой скважины в тайге и болотах кабель не дотягивался, релейки помогали не везде. И тогда данные с удалённых объектов носили в прямом смысле на собственных ногах, в стальном ящике с застёжками и ручкой, прародителе флешки. Посмотрим, как из таких чемоданчиков и американской ЭВМ собралась работающая сеть задолго до термина «корпоративная».

Взвод менеджеров Вынесу из коментов пару текстов от Дениса Лучанского. Он, в отличие от многих, мешки ворочает с ИИ и пишет вот что: Новое приложение chatGPT с солом 5.6 просто работает на компе как взвод менеджеров. Отличие только в ЗП и перерывах на сон и перекуры. За 20 баксов в месяц в браузере читает любые облачные приложения, собирает данные из нескольких источников в браузере, формирует заказы для десятков магазинов клиентов (может для любого количества), разрабатывает или добавляет в портфель новые продукты (сейчас расширяю портфель с 13 до 40 SKU за две-четыре недели, чтобы увеличить маржинальность одной доставки в торговую точку), управляет рекламными кампаниями в соцсетях (видит дневные продажи точки, сравнивает с затратами на рекламу, и принимает решения, как улучшить ROAS), может постить в любых соцсетях от моего имени всякую дичь 🤪, чуть позже отдам ему бизнес-процесс роста бизнеса почти весь. Это нереально круто. Кожаные отдыхают, служба идет. Теперь можно в одну рожу пилить нереально крутые бизнесы, и быстро выходить на недостижимый раньше уровень. 20, блять, баксов в месяц. Про текеномику: Да, да. Токены могут закончиться быстро, если промпт «сделай мне бизнес». 😂 И глюки могут сильно влиять, если задачи для ИИ ставит гуманитарий «яхудожникятаквижу» 🥹 Но 1) все эти несложные задачи решаются дешевой моделью, не по API, а несложными запросами по расписанию. Нет расхода токенов за рамками тарифа за 20 баксов в месяц. 2) Конечно же пока остается проверка кожаным, но она занимает мизерное время по сравнению с вариантом «сделать самому». Ошибки в начале запуска нового процесса бывают, но они быстро вылавливаются и исправляются. 3) Все процессы очень простые, и основаны на данных. Я не очень полагаюсь на творчество моделей, а в основном на холодный расчет и объективные показатели на основе данных. Например, одна сеть присылает заказы на мэйл в очень упрощенном виде. ИИ проверяет ежедневно почту, и при получении заказа делает накладные, и отправляет заявки на отгрузки на склад. Если мэйл не пришел вовремя, система поднимает шухер на несколько кожаных участников процесса. Все просто, нет вариантов для творчества. Тупая функция администратора. 4) сбор данных из источников - это не парсинг бреда из интернетов. Мне сети дают подключения к системам обмена информацией о движении товаров/заказах, но они разные, и мне проще промптом попросить ИИ вытащить товарный запас в точке с веб-страницы, где я залогинился в систему, чем кодить коннекторы, да еще клянчить доступ у сети, которая надменно считает себя крупным ритейлером, а зажравшийся перегруженный надменный ИТ-шник снизойдет до моего запроса через месяц. 5) я знаю свою область очень хорошо, и не внедряю ИИ во все процессы без разбора, у меня нет показателей на максимальное использование ИИ где попало. Я трачу инференс очень сфокусированно - в первую очередь на текущем ограничении бизнеса. Поэтому мне не нужен миллион на ИИ. Но отдача от ИИ максимальная. P.S. Денис занимается продуктами питания, а не этим вот вашим цифровым бизьнесом. @cgevent