IT

Российский образовательный ИИ-стартап “Обучай” привлек 5 млн рублей от ФРИИ в обмен на долю 7%. Постинвестиционная оценка стартапа превысила 71 млн рублей, сообщили в фонде. Привлеченные средства планируется направить на “расширение команды продаж, которая снизит операционную нагрузку на ключевых лиц”. “Обучай” запустили летом прошлого года Константин Чукавин и Кирилл Дьолог. Стартап разрабатывает цифровую образовательную платформу на базе искусственного интеллекта. Она помогает учителям эффективнее готовиться к занятиям: педагог может загрузить календарно-тематический план, на основании которого система сформирует сценарии и материалы уроков, подготовит задания для учеников из 69 вариантов [универсальных и специфичных для отдельных предметов].  Платформа может формулировать запросы в свободной форме и получать ответы, рекомендации, варианты заданий и пояснения по различным образовательным темам. Генерация одного учебного материала [рабочий лист, план урока, презентация, изображение, задание и др.] занимает порядка 26 секунд. При этом платформа ориентирована не на разовую генерацию контента, а на сопровождение полного цикла работы учителя - от планирования учебного года и подготовки урока до выдачи заданий. “Обучай” также интегрирована с открытым банком экзаменационных заданий для подготовки к ОГЭ и ЕГЭ. В будущем стартап намерен увеличить количество пользователей за счет учеников, подключаемых по приглашению учителя. Это позволит подключить автоматическую проверку домашних заданий и адаптировать образовательный контент под уровень конкретного учащегося и класса. Сегодня бизнес-модель “Обучай” - SaaS-подписка с оплатой доступа к платформе от 368 рублей в месяц до 1790 рублей в месяц. Согласно данным сервиса проверки контрагентов Rusprofile, ООО “Обучай” было создано в середине 2026 года. Константин Чукавин и Кирилл Дьолог владеют по 46,5% соответственно. 7% принадлежит ООО “Фрии Инвест”.  @rusven

🔁🌐 TRANSLATED REPOST ➖➖➖ 45-минутный трюк CBP, чтобы скопировать ваш телефон без ордера Контроль слежки · 30.09.2026 Пограничный контроль США нашёл новый способ читать ваши личные сообщения без ордера — просто попросить телефон «на минутку». На сорок пять минут, если быть точным. Томас Кеннеди, аргентино-американский писатель и защитник прав иммигрантов, подал в суд на федеральное правительство. Требование простое: удалить данные, скопированные с моего телефона в международном аэропорту Майами. Согласно семистраничному иску, вот как всё происходило: агент CBP провёл физический досмотр багажа, задавал вопросы о книгах и журналах, а затем потребовал телефон. Классическое «добровольное принуждение» — агент якобы угрожал, что без телефона допрос затянется, а само устройство может быть изъято на неопределённый срок. Выбор, мягко говоря, невелик. Телефон забрали. Его вернули через 45 минут — ровно столько времени, по мнению Кеннеди, потребовалось, чтобы скопировать его содержимое. После этого его отпустили без каких-либо обвинений. Иными словами, не подозреваемый, не нарушитель закона — просто владелец смартфона, который кого-то заинтересовал. И заинтересовал не просто так. Кеннеди работает с Florida Immigration Coalition, Amnesty International и Community Justice Project. Во время допроса его неоднократно спрашивали о роде занятий и о том, не является ли он иммиграционным юристом. Сложно не заметить закономерность, когда вопросы о чьей-то профессии звучат чаще, чем того требует рутинная проверка багажа. Теперь, по словам активиста, в его телефоне по-прежнему хранится значительный объём личной и профессиональной информации — и именно эти данные он требует удалить через суд. Граница — это место, где обычные права почему-то работают вполсилы. Удобно: вам даже не нужно доказывать, что вы нарушили какое-либо правило. Достаточно иметь неподходящую профессию и оказаться не в той очереди на паспортном контроле. Источник: https://arstechnica.com/tech-policy/2026/09/immigration-advocate-sues-border-agents-for-demanding-his-cell-phone/ ➖➖➖ 🔁🌐 Repost & Translated from: Brandmauer Report

🌐 Что такое TCP/IP? Объясняем простыми словами Когда мы отправляем сообщение, открываем сайт или смотрим видео — данные не летят целиком одним большим файлом. Они разбиваются на маленькие части и отправляются через сеть. За это отвечает набор протоколов TCP/IP. 📌 IP (Internet Protocol) — это как адрес на конверте. Он отвечает за: куда отправить данные; какой у устройства IP-адрес; через какие сети пройти. Например: 💻 Компьютер → 192.168.1.10 🌍 Сервер сайта → 8.8.8.8 IP помогает найти путь от отправителя к получателю. 📌 TCP (Transmission Control Protocol) — это как проверка доставки. Он отвечает за: — разбивку данных на части; — проверку, что всё дошло; — повторную отправку потерянных частей; — сборку данных обратно в правильном порядке. Представь, что ты отправляешь книгу по почте: IP говорит: «Вот адрес получателя». TCP проверяет: «Все страницы книги дошли? Ничего не потерялось?» 📦 Пример работы: Ты открываешь сайт: 1️⃣ Браузер получает IP-адрес сервера. 2️⃣ TCP устанавливает соединение с сервером. 3️⃣ Данные сайта отправляются маленькими пакетами. 4️⃣ TCP проверяет доставку. 5️⃣ Браузер собирает страницу. ⚡️ А если нужна скорость, а не идеальная доставка, используются другие протоколы — например UDP. #network

«Объяснить код» — уже мало: Хабр расширяет ИИ-помощника для чтения статей Кнопку «Объяснить код» на Хабре нажали уже больше миллиона раз, а самой фичей воспользовались более 645 тысяч человек. Но код — не единственное, с чем приходится разбираться при чтении технической статьи: иногда хочется быстро понять сам материал, иногда — не продираться через длинную ветку комментариев, а иногда после чтения остаётся вопрос «хорошо, а где это можно применить?». Поэтому мы расширили SourceCraft Code Assistant. Теперь рядом со статьёй можно сделать её краткое содержание, собрать саммари комментариев, попросить объяснить материал простым языком или предложить варианты практического применения. «Объяснить код» при этом никуда не делось. Рассказываем, что именно получает модель в разных режимах, как устроено саммари обсуждения и почему команда собирается смотреть не только на количество нажатий.

70 лет назад, когда компьютеры существовали в основном в государственных и военных лабораториях, уже находились люди, которые понимали: компьютер, это не только штука для расчёта траектории ракеты или взлома шифров. Это ещё и отличный инструмент для бизнеса. Особенно для бизнеса, которому приходится обрабатывать огромное количество информации. Поэтому первый в мире компьютер, созданный специально для офисной работы, появился не в банке, не в страховой компании и даже не на промышленном гиганте. Его создала компания, владевшая сетью чайных и производившая продукты питания. Компания называлась J. Lyons & Co. Задачи у неё были вполне знакомые любому современному предприятию - собирать заказы со множества торговых точек, планировать производство, оценивать эффективность каждой чайной, вести учёт продукции, рассчитывать зарплаты. В общем, почти обычная ERP-система. Только на дворе были 1950-е, а слово ERP ещё никто не придумал. Свой компьютер в Lyons назвали LEO - Lyons Electronic Office (электронный офис Lyons) И это был один из самых ранних компьютеров Великобритании (пишут, что он был третий по счёту. У кого были первые два, я думаю, что вы догадались 😎) Причём компания не просто купила себе очень дорогую железную штуку и торжественно поставила её в отдельной комнате. В Lyons создали специальное подразделение, которое описывало и оптимизировало бизнес-процессы, программировало, обучало сотрудников, внедряло новые решения и исправляло ошибки. То есть фактически создали обычный современный IT-отдел. Только это было более 70 лет назад. Одной из самых сложных задач было планирование производства выпечки. Срок хранения короткий - произведёшь слишком много, получишь списания, слишком мало - потеряешь продажи. Поэтому компании нужно было максимально точно прогнозировать спрос и быстро реагировать на его изменения. Постепенно компьютерное направление превратилось в отдельный бизнес. Появились LEO II, затем LEO III. Несколько десятков машин удалось продать другим компаниям. Но для создания большой самостоятельной компьютерной индустрии этого оказалось недостаточно. В итоге рынок захватили американские производители, прежде всего IBM, а история LEO постепенно превратилась в легенду Британской компьютерной индустрии. Эта история подробно описана в книге A Computer Called LEO: Lyons Teashops and the World’s First Office Computer. Какие выводы можно сделать сегодня из этой истории: 1️⃣ Рынок, общество и бизнес должны «созреть» к инновациям. 2️⃣ Даже если всем очевидно преимущество новой технологии, существует огромная инерция в культуре бизнеса 3️⃣ Недостаточно просто купить компьютеры и ПО. Нужна очень большая и кропотливая работа по описанию процессов и внедрению IT решений. Сейчас стоимость такой работы выше, чем стоимость «железа» и ПО 4️⃣ Такие революционные и капиталоемкие инновации должно поддерживать государство. Иначе рынок будет захвачен компаниями из других государств, которые эти инновации поддержали. Сегодня государственная поддержка стратегических технологий вообще стала совершенно обычным явлением. И хотя Великобритания в 1950-х прошляпила своё лидерство в компьютерах, в её истории есть и обратные примеры. В следующем посте расскажу, как государственная поддержка помогла британским производителям стать мировыми лидерами в производстве… шерстяных шапок. Не переключайтесь. Незаметный бизнес

Российский нейрочип от НТЦ «Модуль» НИИАС строит для РЖД комплекс «ЧИЖ», который сшивает картинку с четырёх камер и ищет объекты на путях. Держалось всё на Jetson Nano, а в марте 2022-го NVIDIA с российского рынка ушла. Подобрали отечественную замену, запустили и увидели, что Jetson быстрее примерно в пять раз. Дальше хуже: YOLOv4 на новом железе не поднимается вовсе, часть слоёв ускоритель не поддерживает. Детектор переучили на YOLOv5. Обычно такое в пресс-релизы не попадает, и тем интереснее читать. Цифры по остальному полю автор тоже не подслащивает: у чипа 2019 года 512 гигафлопс, а сопоставимой публичной метрики с нынешними Jetson Orin Nano и Huawei Ascend нет вовсе, свести их в один ряд не получается. При этом из всех российских разработок для нейросетей это единственный кремний, который можно купить и поставить в промышленную систему прямо сейчас.

Я уже давно юзаю Orca как основной ADE, но вот недавно на стриме у друзей узнал о еще одном — bb (это название) В стоке он выглядит как Codex, но главная фишка что весь UI состоит из TypeScript компонентов которые агенты могут переписывать/добавлять под себя Всё, что можно сделать в интерфейсе, доступно через CLI, SDK и HTTP API. Агент может сам запускать треды, менять внешний вид, допиливать интерфейс и тд Например мне щас в Orca не хватает предпросмотра ссылок в чате, а в bb это можно сделать опусом за 10 мин Хотя это вообще самое примитивное, вон видел как люди встраивают Grok Bot в интерфейс bb 😮 В целом мастхев для тех кому в работе нужны кастомные виджеты поверх харнеса, и не хочется мучаться с терминальным UI ☕️ Скачать (macOS) | GitHub P.s есть еще встроенный account pooler, чтобы автоматом переключать учетки Claude/Codex когда кончается лимит @tips_ai #tools

🎦 Про сериалы Ушла эпоха, Netflix перешел со своих мегамудреных рекомендательных алгоритмов на ллмки и предлагаю посмотреть почему — может быть вам отзовется для ваших проектов на работе. Раньше ранжированием занималась классическая дискриминативная модель, которую годами обвешивали тысячами вручную сконструированных фичей, их кросс-взаимодействиями и отдельными архитектурами под каждую задачу, а теперь будет внутренняя ллм. 🤔Почему? Старый стек перестал успевать за бизнесом. Чтобы добавить новый тип контента (игры, лайвы, подкасты) или новую поверхность в интерфейсе, приходилось переделывать фичи, архитектуру, инфру и заново гонять эксперименты. LLM же уже знает мир и умеет понимать контент, так что эти способности не нужно строить с нуля. Кроме того, рекомендациями можно управлять промптом, а не обучать под каждый кейс новую модель. 🇹🇱 Кратенько про архитектуру Обучение идёт в две фазы. Сначала open-source LLM дообучают на данных Netflix, и получается foundation-модель, которая понимает каталог и зрителей. Потом эту модель регулярно дообучают уже под ранжирование. На вход ей подаётся текст: история просмотров, метаданные тайтлов и контекст (устройство, время, страна), причём история оформлена как диалог пользователя с рекомендателем. Токены модель не генерирует. Вместо этого catalog-aware head за один forward pass выдаёт скоры сразу для всего каталога, поэтому выдумать несуществующий тайтл она не может в принципе. В проде это крутится на vLLM в режиме prefill-only, без декодинга и beam search. Чтобы модель думала о долгосрочном удержании и соблюдала баланс между фильмами, играми и лайвами, в лосс добавили веса от reward-моделей. GRPO тоже пробовали, и он давал прирост, но обучение с ним оказалось слишком дорогим. 🔢 Числа GenRec обучали на данных Phase 2, которых примерно в 40 раз меньше, чем у прод-модели, и всё равно офлайн MRR вырос на 1.6%. A/B-тест шёл четыре недели на ~10% трафика и показал статзначимый рост как краткосрочных, так и долгосрочных метрик. Обе фазы вносят заметный вклад: Phase 1 даёт +10–20% к MRR по сравнению с обычной OSS-моделью, а Phase 2 добавляет сверху ещё 35–50%. Бэкбоны тестировали от ~1B до ~10B параметров, и качество монотонно росло и с объёмом данных, и с размером модели, так что скейлинг-законы работают и в рекомендациях. Отдельно поработали над контекстом: его ужали с ~5000 до ~1700 токенов почти без потери качества, и инференс подешевел примерно втрое. Получается совсем не нужно было городить этот зоопарк фичей и эвристик, а можно было просто хорошо покрутить модельку. Думайте. #AI @techn0danya

Утро началось с письма счастья от OpenAI. Суть письма со скриншота примерно в следующем:

Теперь за $200 ты будешь получать в два раза меньше токенов. Вот тебе модель GPT-6.1-sol – начинай экономить. Можешь вот ещё по $500 в месяц тратить, если экономия тебе претит. Но там будет лишь немногим больше лимитов, чем у тебя сейчас (но мы их отберём в конце октября, потому что можем)

Интересно, что пару дней назад я говорил об этом на эфире. Кстати, вот тут есть в записи. Повторю мысль в текстовом формате:

Если у вас код в компании разрабатывается при помощи подписочных планов на внешние сервисы (Codex/Claude Code и т.д.) – это хрупкая конструкция. В любой момент провайдер может увеличить стоимость подписки, снизить лимиты или даже в одностороннем порядке изменить качество ответа моделей (мощности понадобились для раскатки новых моделей, например)

В качестве контр-аргумента я получил примерно следующее:

Ну, до этого момента ведь всё работало только лучше с каждым новым релизом!

И вот сегодня утром получаю подтверждение своим словам. Не хотел я оказаться прав так быстро... Проговорю ещё раз, как сохранить устойчивость агентных пайплайнов: 1. Отслеживание работы AI-агентов и её качества – must have. В этом деле может помочь, например, Langfuse (писал про него тут). Там недавно, кстати, v4 вышла. 2. Для разных этапов пайплайна – разные модели от разных вендоров. Это, в целом, немного увеличивает устойчивость процесса. Так как, благодаря наличию конкуренции, вендоры пока что чудят по одному, а не все и сразу (но скорость в AI-индустрии растёт, всё может измениться). 3. Для каждой выбранной модели должно быть обоснование в цифрах, почему она лучше всего подходит для данного этапа пайплайна и для неё зафиксировано соотношение цена/качество. 4. Если часть агентов у работает через oAuth и использует подписку, то стоит узнать, как изменятся расходы в случае, если придётся перейти на использование по API. Так как аккаунты иногда банят. 5. Иметь запасной план. На какую модель переходить определённому этапу пайплайна, если текущая станет недоступна. Как изменится при этом соотношение цена/качество. 6. Постоянно проводить работы по снижению зависимости от закрытых LLM. Как по подписке, так и по API. Потому что в любой момент их могут убрать из доступа или понёрфить. Относятся эти пункты, прежде всего, к ситуации, когда результат работы AI-агентов уйдёт конечному пользователю. Внутренние продукты только для себя или для коллег отдела могут обладать куда менее строгими требованиями.