Искусственный интеллект

Мы уже разобрались с тем, что такое BaaS, почему появились Firebase и Supabase, чем они отличаются от обычного backend и можно ли самому собрать что-то похожее.

Как я и говорил в прошлой статье, сегодня мы наконец попробуем самостоятельно собрать альтернативу Firebase с Realtime исключительно на open-source компонентах!

Но важная оговорка: мы не будем делать полный клон Firebase с его тонной функционала, но мы соберем минимальную рабочую альтернативу, которую уже можно подключить к frontend через SDK и использовать почти как Firebase.

Исследователи говорят, что трафик систем ИИ в интернете превысил человеческий. Скрейперы и краулеры собирают данные на сайтах для тонкой настройки или обучения новых моделей, а агентные системы выполняют действия от имени пользователя. Все это дало новый толчок теориям «интернет-апокалипсиса» о неизбежной кончине «человеческой» сети, в том виде, который мы знаем и любим. Разбираемся, что такое «теория мертвого интернета», что на этот счет говорят исследования и статистика, кто считает, что интернет «не умрет, но замерзнет» — и что со всем этим делать?

Развитие ИИ сейчас упирается не в алгоритмы или производительность чипов. Главной проблемой становятся сами вычислительные мощности. Новые дата-центры строят по всему миру, однако вместе с этим возникает дефицит свободных ресурсов, прежде всего, воды и энергии.

На этом фоне начали появляться весьма необычные идеи. Одна из них — перенести часть вычислений в космос. Именно такой подход продвигают Илон Маск и SpaceX. Компания рассматривает создание орбитальных вычислительных узлов, которые будут получать энергию от солнечных панелей, а избыточное тепло сбрасывать напрямую в космос. Концепция выросла из проекта Starlink, но ее цель намного шире — обеспечить инфраструктуру для дальнейшего роста искусственного интеллекта. Разберемся, насколько реалистичны такие планы и какие проблемы они должны решить.

Valkey (форк Redis под крылом Linux Foundation) в релизном цикле 9.1 отдал ИИ-агентам рутину мейнтенанса: бэкпорт-агент сам раскатывает фиксы по веткам 7.2/8.0/8.1/9.0, отдельный агент сканирует provenance кода на конфликт с нынешней лицензией Redis (чтобы в форк случайно не затёк несовместимый код родителя), а агентский поиск багов наткнулся на ещё закрытую CVE. Разбираю не «ИИ заменяет мейнтейнеров», а как это сделали по уму: по словам Мэделин Олсон из AWS, агентов посадили на ограниченный, проверяемый слой (CI + ревью + человек на мерже) — «using AI agents without losing control». Главный вывод для своих проектов: сажать агентов на toil, а не на дизайн.

Продолжение цикла. До этого были базовые цифры и анонс 5 архитектур. Теперь - что сломалось, как чинили, что узнали.

Систему менеджмента качества на предприятии часто воспринимают слишком узко: как набор обязательных процедур, журналов, форм, регламентов, протоколов, подписей и документов для аудита. В такой логике СМК существует рядом с реальной деятельностью предприятия: производство работает, склад принимает, закупки закупают, сервис обслуживает, ERP фиксирует документы, а система качества как будто отдельно ведёт свои формы и подтверждения.

Но у СМК есть гораздо более серьёзный потенциал. Она может быть не документальной надстройкой над предприятием, а живой инженерной моделью качества. Такой моделью, которая показывает, какие предметы качества регулируются, какие требования к ним предъявлены, какие процедуры должны быть выполнены, где в бизнес-процессах возникают события качества и какие доказательные записи подтверждают результат.

Проблема многих СМК не в том, что в них есть документы. Документы нужны. Проблема в другом: документы часто не соединены в предметную систему. Есть протокол, но не всегда видно, какой СМК-предмет он подтверждает. Есть журнал, но не всегда понятно, какое событие качества в нём зафиксировано. Есть процедура, но не всегда ясно, какая доказательная запись должна возникнуть после её выполнения. Есть архив, но не всегда понятно, какие требования реально закрыты, а какие только предполагаются закрытыми.

Именно здесь начинается предметно-ориентированный инженерный подход к СМК. Его суть в том, что система качества должна строиться не от папки документов, а от предметов качества, требований, единичных документированных процедур, событий качества, доказательных записей, реквизитов, статусов, маршрутов, приёмки и архива. То есть СМК должна отвечать не только на вопрос «какие документы у нас есть?», а на более строгий вопрос: какие предметы качества мы обязаны доказательно удерживать, какими событиями качества они подтверждаются и какие записи можно предъявить как доказательство?

В прошлый раз я рассказал про GraphKAN, первую тернарную KAN с весами {-1, 0, +1}, которая выдала 96.15% на MNIST при 15 КБ. (ссылка).

С тех пор проект переродился. Рассказываю, что изменилось и почему.

Привет, Хабр! Меня зовут Андрей, и сегодня я хочу поделиться, как устроен пайплайн автонарезки выступлений с конференций (со спикером, субтитрами и его слайдами): где помогает LLM, почему субтитры рисуются через drawtext, а не .ass, и как собрать композицию «спикер + субтитры + слайд» одним проходом ffmpeg. С конкретным решением и граблями, на которые я сам наступил

Сейчас только ленивый не делает свой нодовый редактор.

Я решил помочь всем быть ещё ленивее и сделать вилку для макаронного монстра: открытый конструктор, в котором сам нодовый редактор собирается из готовых частей, а ноды перестают быть пленниками одной программы и превращаются в переносимые штуки. Ноду можно скачать, поставить себе, кинуть другому человеку, бросить в библиотеку, собрать из нескольких цепочку — а потом свернуть эту цепочку обратно в одну ноду.

Проект называется SnarkRoute. Рабочий публичный кусок сейчас живёт как BoojumRoute Lab — локальный блочный редактор маршрутов. А под ним лежит то, ради чего всё и затевалось: Open Route Protocol, переносимый формат для описания AI-, model- и API-воркфлоу.

На днях встретился с бывшими коллегами-налоговиками, которые, как и я, недавно ушли со службы. Обсудили то, что сейчас происходит в ФНС, региональных инспекциях, как в целом себя ощущает бизнес.

И по нашему мнению пока на ПМЭФ заявляют, что с налоговой нагрузкой все в порядке и палку никто не перегнул, на самом деле все гораздо менее радужно, а то будущее которое нам готовит, грозит и вовсе «похоронить» малый и средний бизнес.

Пет‑проект ни к чему не обязывает. Никто не ждёт аптайма, можно неделю не заходить. Сломалось, починишь на выходных. Всё меняется, когда за продукт начинаешь отвечать: чужие люди платят деньги, присылают свои фотографии и рассчитывают, что всё сработает. Игрушка становится обязательством.

Дальше про этот переход. Как вечерний бот в Telegram оброс вторым ботом, потом сайтом, общим кошельком, биллингом и мониторингом, и в какой момент я из человека, который балуется на выходных, превратился в того, кто отвечает за работающий сервис.

Я не фуллстек‑разработчик: пять лет я строю системы машинного обучения и языковые модели в финансах. Добрую половину того, что ниже (фронт, боты, продукт, маркетинг), до этого проекта я не трогал. И главный сюрприз оказался не в коде.

В результате одного из множества обсуждений инфоповодов про поднятие цен на подписки и тредов связанных с экономикой моделей возник вопрос о цене токена:

Ниже какой цены токен в принципе не может стоить?

По идее в сухом остатке мы платим за амортизацию железа и электричество умноженное на время работы сервера и это, конечно же, не “реальная цена токена”, скорее нижняя граница, эдакий бэдрок, ниже которого токен физически не может стоить. Чтобы упростить расчёт решил не учитывать обучение моделей, зарплаты, аренду, маркетинг, юридические услуги и прочие прелести бизнеса.

Но давайте обо всём по порядку.

Сайты под управлением ИИ: что это на самом деле и сколько стоит. Часть 1

Это вторая часть из трёх. В первой мы разбирались с концепцией: что такое сайт под управлением ИИ на самом деле, чем он не является, сколько стоит, есть ли инференс в рантайме (спойлер: для посетителя — нет). Если читали — отлично. Если нет — здесь будет понятно и без неё, потому что речь пойдёт про другое: про механику.

Здесь я хочу честно показать, как у нас устроено под капотом: где живёт модель, как она правит код, почему она физически не может одним неудачным запросом снести прод, чем гарантируется, что сгенерированный код вообще валиден, и как мы развели версионирование кода и контента, чтобы откат дизайна не уносил с собой свежие статьи. Всё на примере живых стеков, которые как раз и работают под этим управлением.

Если вы строили RAG в 2023, ваш стек выглядел плюс-минус одинаково. BERT-семейство (BGE, e5) для семантики, BM25 для буквальных совпадений, cross-encoder для реранкинга, какой-нибудь Qdrant сверху. Этим жили два года, и многие до сих пор так живут.

Но если посмотреть, кто реально гоняется в продакшене у команд, которые ушли вперёд, ландшафт другой. Энкодеров там почти нет. Эмбеддит файнтюненная LLM. Реранкер — тоже LLM. Инференс на SGLang, а не на ONNX. И вся обвязка перестроилась под это.

Эта статья про то, что поменялось и как переиспользовать этот стек у себя. Особенно если вы работаете в узком домене, где готовых датасетов нет.

Я часто вижу в комментариях выражения, типа "ИИ не заменит программиста, потому что ИИ выдаёт недетерминированный результат". Но ведь и человек не выдаёт детерминированный результат. Много ли вы знаете людей, которые могут написать программу на тысячу с лишним строк, а затем повторить её байт в байт? Ладно, согласен - это возможно. Ну а на 10 тысяч?

Из опыта общения с ИИ могу сказать, что ИИ более детерминирован в своём поведении, чем многие люди, несмотря на свою вероятностную природу. Теория вероятностей плохо предсказывает результат бросания одной монеты - "орёл" или "решка", зато хорошо предсказывает, что на миллион бросков "орлов" будет не менее 400 тысяч, впрочем, как и "решек".

Для отдельного программиста результат работы ИИ-агента по генерации кода - это как один бросок монеты. Код может быть годный, а может и нет. Для ИТ-индустрии в целом такой вопрос даже не стоит - код годный. ИИ создают код не хуже, чем это делают "кожаные". Да, с кодирующими ИИ-агентами нужно общаться несколько по-другому, чем с программистами, но код они генерируют не хуже, а лучше. В целом лучше. Так что, если ваша работа заключается в переписывании спецификаций, написанных другими людьми, то можете считать, что вы уже безработный.

"Хау, я всё сказал!" (с) ЧБЗ

В последние годы купить новую видеокарту стало заметно сложнее и дороже. Одной из причин стал бурный рост систем искусственного интеллекта, для которых требуются огромные объемы вычислительных ресурсов. Крупные компании активно скупают графические ускорители для своих дата-центров, что влияет и на обычный рынок. В результате многие владельцы компьютеров не спешат с обновлением и продолжают использовать уже имеющееся железо или ищут недорогие варианты на вторичном рынке.

В мире open-source эта ситуация привела к довольно неожиданному результату. Разработчики Linux продолжают поддерживать видеокарты, которым уже почти два десятилетия, адаптируя драйверы под современные версии системы. Любопытно, что помогает им в этом технология, которую многие считают одной из причин нынешнего дефицита ускорителей, — генеративный искусственный интеллект. Недавняя история с доработкой драйвера для видеокарт AMD, выпущенных еще в 2007–2010 годах, наглядно показывает, как подобные инструменты используются в реальной разработке. Мы уже писали новость об этом, а теперь давайте разберемся подробнее.

Это продолжение поста “Две нейросети по 15 КБ” - там были базовые цифры. А тут уже личная история: как делалось, что пошло не так, и что выяснилось по пути.

Май 2024 года. Выходит статья “KAN: Kolmogorov-Arnold Networks”. И происходит то, что бывает раз в несколько лет - кто-то предлагает альтернативу MLP.

Не модификацию и не лайфхак - альтернативу.

В MLP каждый нейрон делает weight × input + bias, и все 80 лет развития - это вариации на тему “как сделать этот вес точнее, быстрее, разреженнее”. KAN предлагает другое: заменить линейный вес на обучаемую функцию. Вроде мелкий трюк, а на практике - меньше параметров при той же точности и встроенная интерпретируемость.

К 2026 году уже появились QuantKAN (4-битное квантование), KANtize (2-3-битные B-spline таблицы), BiKA (аппаратный акселератор, вдохновленный KAN). И все они, по сути, про одно - сделать KAN меньше, чтоб работал не только на GPU.

Граница в три бита - она же психологическая. Ниже 4 бит у всех начинается «а вдруг всё сломается». И знаете что? Обычно так и есть. Любой, кто квантовал нейросети в 2 бита, знает: точность падает. Не чуть-чуть - катастрофически.

Но {-1, 0, +1} - это даже не два бита, это log₂(3) ≈ 1.58 бита. Формально - между binary и ternary, а по ощущениям - чистое безумие.

Ну я и решил попробовать.

Если вы работаете с Claude Code или Cursor на большом проекте, знаете боль: просишь “найди, где обрабатывается авторизация”, а агент гоняет grep по ключевым словам. Если функция называется validateUserSession, а вы спросили про “авторизацию” — grep её не найдёт. Это ограничение текстового поиска, и его решает семантический поиск через эмбеддинги. Я уже разбирал CodeGraph и SocratiCode из этой ниши, теперь поставил третий — cocoindex-code. Зацепил тем, что ставится в две команды без Docker и баз данных. Прогнал на своём проекте, разобрался с AST-чанкингом и сравнил с аналогами.

Автоматическая генерация структурированных академических конспектов из аудиозаписей лекций по точным и естественным наукам затруднена для локальных малых языковых моделей (small language models, SLM). Транскрипт лекции продолжительностью ≈1,5 ч составляет около 15–20 тыс. токенов и формально умещается в контекстное окно современных локальных SLM, однако при обработке такого контекста single-call SLM систематически деградируют: теряют фрагменты из середины последовательности, не удерживают структуру и галлюцинируют термины и формулы. Это проявление эффекта Lost in the Middle: точность извлечения информации описывает U-образную кривую — высока на краях контекста и падает в середине; в наших условиях используются SLM, поведение которых так же описано в статье, и оно характеризуется выраженным забыванием не только из середины, но также и из начала контекста. Более того, на бюджете 8 ГБ VRAM single-call длинного транскрипта практически неприменим*, что делает декомпозицию не оптимизацией, а необходимым условием работоспособности.

Раньше ценность специалиста в продуктовой разработке — неважно, аналитик это, владелец продукта, разработчик или инженер сопровождения, — во многом мерили тем, сколько деталей он держит в своём контекстном окне: подводные камни конкретного домена, как работает функционал легаси-системы, грабли, на которые он однажды уже наступал. По сути это был сжатый контекст одной-двух областей, накопленный дорогой ценой — годами жизни. Сейчас ровно по этому месту бьёт ИИ: токены, которые раньше приходилось загружать в мозг годами узкой практики, теперь подтягиваются почти даром, из ИИ-модели. Похоже, что дефицитным становится не объём контекстного окна и не глубина знаний в одной области, а то, чем это окно заполнено: много смежных доменов, лежащих рядом, и способность видеть, как они стыкуются в той системе, которую ты создаешь с помощью ИИ. Опыт точно никуда не девается, но, возможно, перестаёт быть решающим преимуществом.