Как построить RecSys и не разорить бизнес? Расскажет Иван Плешаков, Data Scientist (Яндекс Маркет, MARS) и автор телеграм-канала Канал Доброго Вани | Data Science.
⚡️Разберем основы рекомендательных систем:
→ User2Item и Item2Item системы;
→ основные этапы рекомендательного пайплайна;
→ ключевые подходы в рамках каждого из этапов;
→ метрики для разработки и бизнеса.
⏰ Запускаем трансляцию в среду, 4 марта, в 12:00.
Смотрите на YouTube, в ВК или прямо в этом канале — и задавайте вопросы Ивану!
⚡️Разберем основы рекомендательных систем:
→ User2Item и Item2Item системы;
→ основные этапы рекомендательного пайплайна;
→ ключевые подходы в рамках каждого из этапов;
→ метрики для разработки и бизнеса.
⏰ Запускаем трансляцию в среду, 4 марта, в 12:00.
Смотрите на YouTube, в ВК или прямо в этом канале — и задавайте вопросы Ивану!
👍7❤3🔥3👎1
🦞 OpenClaw на своём сервере: полная инструкция
Записали с фаундером alfaci.xyz Александром Агафонцевым подробный видео-гайд — как безопасно развернуть OpenClaw в Docker-контейнере на изолированном сервере и подключить Telegram-бота.
Что внутри:
— Установка Docker и сборка образа с нуля
— Подключение API Anthropic (Claude) и Telegram
— Device Pairing — почему бот не отвечает и как это починить
— Настройка «личности» агента через identity.md, soul.md и user.md
— Создание собственных скиллов
— Типичные ошибки при запуске (Trusted Origins и др.) и их решение
— Честный разбор проблем с безопасностью: промпт-инъекции, утечки ключей, трояны в форках
⚠️ Главное правило: НЕ ставьте OpenClaw на личный компьютер. Только изолированный сервер + Docker. В видео объясняем почему.
OpenClaw — мощнейший open-source AI-агент, который умеет буквально всё. И проблема в том, что он умеет буквально всё. Поэтому показываем, как использовать его с умом.
🎬 Смотрите на YouTube или RuTube!
📦 GitHub: github.com/openclaw/openclaw
📄 Docker-документация: docs.openclaw.ai/install/docker
#OpenClaw #AI #Docker #Telegram #ИИагент
Записали с фаундером alfaci.xyz Александром Агафонцевым подробный видео-гайд — как безопасно развернуть OpenClaw в Docker-контейнере на изолированном сервере и подключить Telegram-бота.
Что внутри:
— Установка Docker и сборка образа с нуля
— Подключение API Anthropic (Claude) и Telegram
— Device Pairing — почему бот не отвечает и как это починить
— Настройка «личности» агента через identity.md, soul.md и user.md
— Создание собственных скиллов
— Типичные ошибки при запуске (Trusted Origins и др.) и их решение
— Честный разбор проблем с безопасностью: промпт-инъекции, утечки ключей, трояны в форках
⚠️ Главное правило: НЕ ставьте OpenClaw на личный компьютер. Только изолированный сервер + Docker. В видео объясняем почему.
OpenClaw — мощнейший open-source AI-агент, который умеет буквально всё. И проблема в том, что он умеет буквально всё. Поэтому показываем, как использовать его с умом.
🎬 Смотрите на YouTube или RuTube!
📦 GitHub: github.com/openclaw/openclaw
📄 Docker-документация: docs.openclaw.ai/install/docker
#OpenClaw #AI #Docker #Telegram #ИИагент
🔥15❤6👍3⚡2🤡2👏1
Vanderbilt University (входит в Top-20 университетов США) выпустил на Coursera 5-часовой курс Claude Code: Software Engineering with Generative AI Agents. Vanderbilt занял нишу полуприкладного, полу-академического обучения Generative AI и стал одним из крупнейших поставщиков AI-курсов на Coursera. Сам курс о том, как превратить AI в «команду разработчиков». Учит строить приложения целиком через большие промпты, запускать несколько AI-агентов параллельно в разных Git-ветках, генерировать несколько решений (Best-of-N), автоматически проверять код и масштабировать разработку с помощью Claude Code. По итогам обучения обещают переход от AI-подсказок к полноценной AI-оркестрации разработки и кратному росту продуктивности. Язык — английский. Доступен по подписке Coursera Plus.
Coursera
Claude Code: Software Engineering with Generative AI Agents
Offered by Vanderbilt University. Master AI-Assisted ... Enroll for free.
👍20
Нужен ли ИИ-агентам свой Stack Overflow?
Недавно Эндрю Ын (Andrew Ng) анонсировал Context Hub или коротко chub. Это открытая утилита, призванная снабжать кодинг-агентов свежей документацией по API. Проект стремительно набирает популярность на GitHub, собрав более 8,5 тысяч звезд, а база поддерживаемых API выросла до 1000 с лишним документов. Главный маркетинговый посыл проекта: создание среды, где агенты смогут обмениваться реальным опытом работы с кодом, формируя общую базу знаний.
Однако технический аудит репозитория проведенный нашими экспертами показывает, что текущая реализация пока заметно отстает от заявленного видения.
Что мы имеем на самом деле:
База данных это LLM-кэш, а не уникальный опыт. Сейчас внутри лежат просто качественно переформатированные официальные доки (LLM-саммари). В них нет неявного знания (tacit knowledge) или разбора краевых случаев из продакшена. Порядка 60% этого контента избыточно, так как современные модели вроде Opus 4.6 или GPT-5.4 и без того им владеют.
Аннотации остаются локальными. В коде видно, что пометки сохраняются исключительно на машине пользователя (в директории ~/.chub/annotations/) и никак не синхронизируются между разными агентами.
Примитивный механизм обратной связи. Заявленный "обмен знаниями" пока сводится к простым меткам (outdated, incomplete) и рейтингам полезности, которые уходят мейнтейнерам в виде телеметрии. Агент не может передать в общую базу специфическую деталь, например, почему конкретный метод выдает ошибку при определенных условиях.
Можно сказать, что Эндрю Ын нащупал правильную идею, коллективная память агентам действительно нужна. Сама CLI-часть написана добротно, код вполне production-ready.
Установить утилиту можно командой:
npm install -g @aisuite/chub
Увы, но пока "Stack Overflow для ИИ" это скорее красивый питч, чем реальность. На данный момент, это просто удобный агрегатор документации с зачатками системы фидбека, но за развитием проекта Context Hub однозначно стоит внимательно следить.
Недавно Эндрю Ын (Andrew Ng) анонсировал Context Hub или коротко chub. Это открытая утилита, призванная снабжать кодинг-агентов свежей документацией по API. Проект стремительно набирает популярность на GitHub, собрав более 8,5 тысяч звезд, а база поддерживаемых API выросла до 1000 с лишним документов. Главный маркетинговый посыл проекта: создание среды, где агенты смогут обмениваться реальным опытом работы с кодом, формируя общую базу знаний.
Однако технический аудит репозитория проведенный нашими экспертами показывает, что текущая реализация пока заметно отстает от заявленного видения.
Что мы имеем на самом деле:
База данных это LLM-кэш, а не уникальный опыт. Сейчас внутри лежат просто качественно переформатированные официальные доки (LLM-саммари). В них нет неявного знания (tacit knowledge) или разбора краевых случаев из продакшена. Порядка 60% этого контента избыточно, так как современные модели вроде Opus 4.6 или GPT-5.4 и без того им владеют.
Аннотации остаются локальными. В коде видно, что пометки сохраняются исключительно на машине пользователя (в директории ~/.chub/annotations/) и никак не синхронизируются между разными агентами.
Примитивный механизм обратной связи. Заявленный "обмен знаниями" пока сводится к простым меткам (outdated, incomplete) и рейтингам полезности, которые уходят мейнтейнерам в виде телеметрии. Агент не может передать в общую базу специфическую деталь, например, почему конкретный метод выдает ошибку при определенных условиях.
Можно сказать, что Эндрю Ын нащупал правильную идею, коллективная память агентам действительно нужна. Сама CLI-часть написана добротно, код вполне production-ready.
Установить утилиту можно командой:
npm install -g @aisuite/chub
Увы, но пока "Stack Overflow для ИИ" это скорее красивый питч, чем реальность. На данный момент, это просто удобный агрегатор документации с зачатками системы фидбека, но за развитием проекта Context Hub однозначно стоит внимательно следить.
👍13💩2
Google Stitch обновился и движется в сторону полноценной AI-native среды для дизайна
Теперь можно начинать даже не с wireframe, а с идеи, бизнес-цели, нужного ощущения или референсов.
В Stitch появился бесконечный canvas, новый design agent, agent manager для параллельной работы с несколькими идеями, голосовое управление, DESIGN.md для переноса правил дизайн-системы между проектами, а также переход от дизайна к коду через MCP, SDK, skills и экспорт в dev-инструменты.
Отдельно интересно, что Stitch умеет почти мгновенно превращать статические экраны в интерактивные прототипы, можно быстро собирать user flow и сразу их проверять.
Для эксперимента мы взяли презентацию продукта, на основе её текстового описания сгенерировали UX-требования и загрузили их в Stitch. Результат получился очень достойный: интерфейсы оказались во многом похожи на те, которые мы сами проектировали, а местами даже сильнее.
Еще один шаг к процессу, где AI помогает не только рисовать интерфейсы, но и думать вместе с дизайнером, ускоряя путь от идеи до прототипа с дней до минут.
Теперь можно начинать даже не с wireframe, а с идеи, бизнес-цели, нужного ощущения или референсов.
В Stitch появился бесконечный canvas, новый design agent, agent manager для параллельной работы с несколькими идеями, голосовое управление, DESIGN.md для переноса правил дизайн-системы между проектами, а также переход от дизайна к коду через MCP, SDK, skills и экспорт в dev-инструменты.
Отдельно интересно, что Stitch умеет почти мгновенно превращать статические экраны в интерактивные прототипы, можно быстро собирать user flow и сразу их проверять.
Для эксперимента мы взяли презентацию продукта, на основе её текстового описания сгенерировали UX-требования и загрузили их в Stitch. Результат получился очень достойный: интерфейсы оказались во многом похожи на те, которые мы сами проектировали, а местами даже сильнее.
Еще один шаг к процессу, где AI помогает не только рисовать интерфейсы, но и думать вместе с дизайнером, ускоряя путь от идеи до прототипа с дней до минут.
👍4🔥2😱2
На GitHub появился бенчмарк, который измеряет насколько эффективно Claude Code генерирует код на разных языках
На GitHub появился репозиторий mame/ai-coding-lang-bench, и это, пожалуй, первый количественный бенчмарк, который отвечает на вопрос "какой язык лучше для AI-кодинга”. Claude Code реализует упрощенный Git на 13 языках, по 20 прогонов на каждый, две фазы (с нуля + расширение функциональности). Автор, коммитер Ruby, честно предупреждает о bias и выкладывает сырые данные.
Лидеры: Ruby (73s, $0.36), Python (74s, $0.38), JavaScript (81s, $0.39). Все динамические. Go четвертый (101s, $0.50).
Самая показательная находка, которую из первых принципов не угадаешь: TypeScript почти вдвое медленнее чистого JavaScript (133s против 81s) и на 60% дороже. Та же семантика, но статическая типизация превращается в прямой налог на генерацию. Python с mypy добавляет 67% overhead. Ruby со Steep замедляется в 2-3.2 раза. Механика понятна: типы добавляют модели дополнительное пространство ограничений, которое надо удовлетворять одновременно с бизнес-логикой, и это конвертируется в токены и доллары. OCaml и Haskell генерируют самый короткий код, но по скорости в нижней половине: когнитивная плотность языка стоит дорого.
Ограничения в исследовании существенные: Задача мелкая (мини-git), один автор, нет CI/CD, нет валидации другими моделями. Как поведет себя генерация на проекте в десятки тысяч строк с реальными зависимостями, мы не знаем. И главное: бенчмарк измеряет стоимость прототипирования, а не стоимость владения кодом, что обычно гораздо более трудоемко. Статическая типизация может проигрывать при генерации, но ее ценность на этапе поддержки и рефакторинга здесь не учтена.
Эффективность AI-генерации (и последующей AI-поддержки) становится таким же свойством языка, как runtime-производительность или эргономика для разработчика.
Стратегия "прототип на динамическом языке, миграция на статический для продакшена" возможно не лишена смысла.
На GitHub появился репозиторий mame/ai-coding-lang-bench, и это, пожалуй, первый количественный бенчмарк, который отвечает на вопрос "какой язык лучше для AI-кодинга”. Claude Code реализует упрощенный Git на 13 языках, по 20 прогонов на каждый, две фазы (с нуля + расширение функциональности). Автор, коммитер Ruby, честно предупреждает о bias и выкладывает сырые данные.
Лидеры: Ruby (73s, $0.36), Python (74s, $0.38), JavaScript (81s, $0.39). Все динамические. Go четвертый (101s, $0.50).
Самая показательная находка, которую из первых принципов не угадаешь: TypeScript почти вдвое медленнее чистого JavaScript (133s против 81s) и на 60% дороже. Та же семантика, но статическая типизация превращается в прямой налог на генерацию. Python с mypy добавляет 67% overhead. Ruby со Steep замедляется в 2-3.2 раза. Механика понятна: типы добавляют модели дополнительное пространство ограничений, которое надо удовлетворять одновременно с бизнес-логикой, и это конвертируется в токены и доллары. OCaml и Haskell генерируют самый короткий код, но по скорости в нижней половине: когнитивная плотность языка стоит дорого.
Ограничения в исследовании существенные: Задача мелкая (мини-git), один автор, нет CI/CD, нет валидации другими моделями. Как поведет себя генерация на проекте в десятки тысяч строк с реальными зависимостями, мы не знаем. И главное: бенчмарк измеряет стоимость прототипирования, а не стоимость владения кодом, что обычно гораздо более трудоемко. Статическая типизация может проигрывать при генерации, но ее ценность на этапе поддержки и рефакторинга здесь не учтена.
Эффективность AI-генерации (и последующей AI-поддержки) становится таким же свойством языка, как runtime-производительность или эргономика для разработчика.
Стратегия "прототип на динамическом языке, миграция на статический для продакшена" возможно не лишена смысла.
👍10❤1👏1💩1🥴1
OpenClaw и переход к AI-агентам: почему теперь всё решает обвязка, а не модель
Сейчас в эфире — Андрей Носов, ведущий ИИ‑архитектор, PhD Communication Science, автор телеграм‑канала «Эй ай надзор».
Говорим о том, какие инженерные решения позволяют превратить «умную, но непредсказуемую» модель в надёжного цифрового сотрудника:
→ как меняется архитектура системы при переходе от LLM‑чатбота к полноценному агенту;
→ какие механизмы контроля действий агента обязательны в production‑среде;
→ как добиться предсказуемости поведения агента и соблюдения SLA;
→ почему observability и аудит в агентных системах — это не роскошь, а необходимость;
→ как обвязка помогает соответствовать требованиям регуляторов и бизнес‑логике.
Подключайтесь к трансляции и пишите вопросы в комментариях — самые интересные зададим гостю в прямом эфире!
👉 Youtube
👉 ВКонтакте
Сейчас в эфире — Андрей Носов, ведущий ИИ‑архитектор, PhD Communication Science, автор телеграм‑канала «Эй ай надзор».
Говорим о том, какие инженерные решения позволяют превратить «умную, но непредсказуемую» модель в надёжного цифрового сотрудника:
→ как меняется архитектура системы при переходе от LLM‑чатбота к полноценному агенту;
→ какие механизмы контроля действий агента обязательны в production‑среде;
→ как добиться предсказуемости поведения агента и соблюдения SLA;
→ почему observability и аудит в агентных системах — это не роскошь, а необходимость;
→ как обвязка помогает соответствовать требованиям регуляторов и бизнес‑логике.
Подключайтесь к трансляции и пишите вопросы в комментариях — самые интересные зададим гостю в прямом эфире!
👉 Youtube
👉 ВКонтакте
🔥3👍2🤡2👏1
🤖 Чем отличается антропоморфная интерпретация LLM от других популярных интерпретаций? Расскажет Владимир Крылов, доктор технических наук и научный консультант по применению ИИ в разработке ПО.
Разберем:
→ В чем состоит самая развитая на сегодня интерпретационная модель PSM (Persona Selection Model) — модель выбора персонажа
→ Как выглядят в этой модели взаимоотношения LLM: помощника как персонажа и ИИ-ассистента
→ Как связаны агентность и свобода воли в терминах PSM
→ Как формируются персоны при обучении LLM
А также посмотрим на одно из исследований автора, связанного с PSM, который использует разработку симулякров.
⏰ Запускаем трансляцию сегодня, 26 марта, в 13:00.
Смотрите на YouTube, RuTube или прямо в этом канале — и задавайте вопросы лектору в комментариях! Владимир Крылов ответит на них в отдельном интервью.
Разберем:
→ В чем состоит самая развитая на сегодня интерпретационная модель PSM (Persona Selection Model) — модель выбора персонажа
→ Как выглядят в этой модели взаимоотношения LLM: помощника как персонажа и ИИ-ассистента
→ Как связаны агентность и свобода воли в терминах PSM
→ Как формируются персоны при обучении LLM
А также посмотрим на одно из исследований автора, связанного с PSM, который использует разработку симулякров.
⏰ Запускаем трансляцию сегодня, 26 марта, в 13:00.
Смотрите на YouTube, RuTube или прямо в этом канале — и задавайте вопросы лектору в комментариях! Владимир Крылов ответит на них в отдельном интервью.
🔥11💩1
Media is too big
VIEW IN TELEGRAM
🤖 Чем отличается антропоморфная интерпретация LLM от других популярных интерпретаций? Рассказал Владимир Крылов, доктор технических наук и научный консультант по применению ИИ в разработке ПО.
В лекции:
→ В чем состоит самая развитая на сегодня интерпретационная модель PSM (Persona Selection Model) — модель выбора персонажа
→ Как выглядят в этой модели взаимоотношения LLM: помощника как персонажа и ИИ-ассистента
→ Как связаны агентность и свобода воли в терминах PSM
→ Как формируются персоны при обучении LLM
Также посмотрим на одно из исследований автора, связанное с PSM, в котором используется разработка симулякров.
🎥 Запись доступна здесь и на других площадках:
YouTube
RuTube
ВКонтакте
ЯндексМузыка
Mave
В лекции:
→ В чем состоит самая развитая на сегодня интерпретационная модель PSM (Persona Selection Model) — модель выбора персонажа
→ Как выглядят в этой модели взаимоотношения LLM: помощника как персонажа и ИИ-ассистента
→ Как связаны агентность и свобода воли в терминах PSM
→ Как формируются персоны при обучении LLM
Также посмотрим на одно из исследований автора, связанное с PSM, в котором используется разработка симулякров.
YouTube
RuTube
ВКонтакте
ЯндексМузыка
Mave
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍1🤡1
Кажется, что всё просто: получили embedding, положили в базу, нашли ближайшие векторы — и поиск готов.
Но на практике сразу начинаются вопросы.
Почему обычные индексы здесь не работают?
Зачем нужны HNSW, IVF и approximate search?
Почему один индекс даёт быстрый ответ, но теряет качество, а другой — ест память и долго строится?
⚡️Анна Авдюшина, кандидат технических наук и инженер центра «Сильный ИИ в промышленности» университета ИТМО, расскажет, как на самом деле устроен векторный поиск в базах данных, почему nearest neighbor search — это отдельный класс задач и какие компромиссы приходится принимать между скоростью, точностью и стоимостью хранения.
Поговорим про:
→ exact search и approximate nearest neighbor search
→ HNSW, IVF и базовую логику векторных индексов
→ recall, latency, memory footprint и trade-off’ы
→ как это работает в реальных системах поиска, RAG и рекомендациях
⏰ Запускаем трансляцию завтра, 2 апреля, в 12:00.
Смотрите на YouTube, в ВК или прямо в этом канале — и задавайте вопросы Анне!
Но на практике сразу начинаются вопросы.
Почему обычные индексы здесь не работают?
Зачем нужны HNSW, IVF и approximate search?
Почему один индекс даёт быстрый ответ, но теряет качество, а другой — ест память и долго строится?
⚡️Анна Авдюшина, кандидат технических наук и инженер центра «Сильный ИИ в промышленности» университета ИТМО, расскажет, как на самом деле устроен векторный поиск в базах данных, почему nearest neighbor search — это отдельный класс задач и какие компромиссы приходится принимать между скоростью, точностью и стоимостью хранения.
Поговорим про:
→ exact search и approximate nearest neighbor search
→ HNSW, IVF и базовую логику векторных индексов
→ recall, latency, memory footprint и trade-off’ы
→ как это работает в реальных системах поиска, RAG и рекомендациях
⏰ Запускаем трансляцию завтра, 2 апреля, в 12:00.
Смотрите на YouTube, в ВК или прямо в этом канале — и задавайте вопросы Анне!
👍12🔥4👎1
Локальный Copilot в VS Code: пошаговая инструкция
Записали с Сергеем Алатиным, ML‑инженером компании Loymax, подробный видео-гайд: как локально развернуть Copilot в VS Code с помощью модуля Continue — быстро, без отправки данных в облако и с сохранением функционала официального решения.
За 20 минут разберём весь процесс от установки до полноценной работы:
→ Установка модуля Continue в VS Code как обычного расширения.
→ Настройка конфигурационного файла: разбираем ключевые параметры.
→ Работа с правилами, промптами и контекстом.
→ Практическое знакомство с основными инструментами (chat, edit, apply, autocomplete)
→ Разбор 3 режимов работы чата: режим агента, режим планирования, чат-режим.
→ Демонстрация работы инструментов на демо‑файлах.
→ Разбор типичных ошибок и ограничений локального Copilot — и как их обойти.
🎬 Смотрите на YouTube или RuTube!
Записали с Сергеем Алатиным, ML‑инженером компании Loymax, подробный видео-гайд: как локально развернуть Copilot в VS Code с помощью модуля Continue — быстро, без отправки данных в облако и с сохранением функционала официального решения.
За 20 минут разберём весь процесс от установки до полноценной работы:
→ Установка модуля Continue в VS Code как обычного расширения.
→ Настройка конфигурационного файла: разбираем ключевые параметры.
→ Работа с правилами, промптами и контекстом.
→ Практическое знакомство с основными инструментами (chat, edit, apply, autocomplete)
→ Разбор 3 режимов работы чата: режим агента, режим планирования, чат-режим.
→ Демонстрация работы инструментов на демо‑файлах.
→ Разбор типичных ошибок и ограничений локального Copilot — и как их обойти.
🎬 Смотрите на YouTube или RuTube!
🔥8👍7💩1
Media is too big
VIEW IN TELEGRAM
Кажется, что всё просто: получили embedding, положили в базу, нашли ближайшие векторы — и поиск готов.
Но на практике сразу начинаются вопросы.
Почему обычные индексы здесь не работают?
Зачем нужны HNSW, IVF и approximate search?
Почему один индекс даёт быстрый ответ, но теряет качество, а другой — ест память и долго строится?
⚡️Анна Авдюшина, кандидат технических наук и инженер центра «Сильный ИИ в промышленности» университета ИТМО, рассказала, как на самом деле устроен векторный поиск в базах данных, почему nearest neighbor search — это отдельный класс задач и какие компромиссы приходится принимать между скоростью, точностью и стоимостью хранения.
Поговорим про:
→ exact search и approximate nearest neighbor search
→ HNSW, IVF и базовую логику векторных индексов
→ recall, latency, memory footprint и trade-off’ы
→ как это работает в реальных системах поиска, RAG и рекомендациях
🎥 Запись доступна здесь и на других площадках:
YouTube
RuTube
ВКонтакте
ЯндексМузыка
Mave
Но на практике сразу начинаются вопросы.
Почему обычные индексы здесь не работают?
Зачем нужны HNSW, IVF и approximate search?
Почему один индекс даёт быстрый ответ, но теряет качество, а другой — ест память и долго строится?
⚡️Анна Авдюшина, кандидат технических наук и инженер центра «Сильный ИИ в промышленности» университета ИТМО, рассказала, как на самом деле устроен векторный поиск в базах данных, почему nearest neighbor search — это отдельный класс задач и какие компромиссы приходится принимать между скоростью, точностью и стоимостью хранения.
Поговорим про:
→ exact search и approximate nearest neighbor search
→ HNSW, IVF и базовую логику векторных индексов
→ recall, latency, memory footprint и trade-off’ы
→ как это работает в реальных системах поиска, RAG и рекомендациях
YouTube
RuTube
ВКонтакте
ЯндексМузыка
Mave
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥4👍3🤡1