IT

Как вам Астра? Я пробую ей давать небольшие баг фиксы на минимальном ризонинге и она работает очень быстро и делает хорошо. Ловлю приятное ощущение, что теперь кучу хвостов можно позакрывать быстро и хорошо (надеюсь, ощущение не обманчиво). Баги исправляются в одном из моих легаси проектов, который я развиваю еще с 2012 года и он ни разу не AI ready (разве что визуальный фидбек настроен). В общем, пока выглядит так, что low (light) ризонинга вполне достаточно для большинства задач, что и бенчмарки подтверждают - DeepSWE, FrontierCode. Единственное что удручает так это быстрый расход лимитов - даже на моей 200$ подписке. С другой же стороны, когда довольно быстро получаешь ожидаемый результат, то может оно того и стоит. Кстати, с более сложной задачей по качественному RAG по большей базе нормативов пока не справилась ни Fable 5.1 max, ни Astra pro - в очередной раз убеждаюсь насколько тяжело до сих пор заодн даже современным моделям разрабатывать сложных агентов, когда нужна предельная точность в ответах. Как у вас ощущения от Астры? Согласны, что low теперь достаточно для большинства задач? @ai_driven

В России начали блокировать протоколы DoH и DoT С середины августа у абонентов «Билайна», «Ростелекома», «Дом.ру» и других зашифрованный DNS от Google и Cloudflare перестал отвечать. Дальше начинается странное. Автор берёт DoT, шлёт запрос и получает мгновенный RST, обрыв сессии. Берёт DoH — TCP поднимается, ClientHello уходит, а потом тишина. Ни ответа, ни сброса. Клиент просто ждёт и падает по таймауту. Одна и та же цель, оба протокола шифрованные, а ломаются совершенно не одинаково. Разгадка в том, что видно фильтру снаружи шифрования. Один протокол торчит на своём отдельном порту, второй прячется в общем потоке HTTPS, и вылавливать его приходится по косвенным признакам. И то, за что DPI цепляется во втором случае, — это поле, которое сам протокол оставляет открытым.

США и Китай готовятся обсуждать безопасность ИИ. По данным Reuters, ссылающегося на два осведомлённых источника, диалог запланирован на середину сентября. США хотят обсудить сотрудничество в отслеживании кибератак под управлением ИИ. Вашингтон предложил американским и китайским ИИ-лабораториям самостоятельно контролировать свои разработки и обмениваться информацией для предотвращения таких атак. Американскую сторону также беспокоит возможное появление китайской модели уровня Claude Mythos, способной проводить кибератаки. С китайской стороны переговоры может возглавить вице-премьер He Lifeng. За последнюю неделю китайский интернет-регулятор публично предупредил о «критических рисках потери контроля над ИИ». А связанный с государственными СМИ блог выступил с критикой позиции Anthropic, подчеркнув, что любые ограничения на передовой ИИ должны в равной степени распространяться на китайские и американские модели. === Логичный вопрос — может быть Китай просто хочет притвориться, что будет вводить какие-либо ограничения, а сам втопит газу? Так может произойти, поэтому важно прийти к мерам, подразумевающим недоверие сторон друг к другу. Такая схема была описана в сценарии AI 2040 (и она подразумевает работу в течении нескольких лет, не по щелчку пальцев). По замыслу авторов, уверенность должна опираться на проверку. Страны декларируют крупные вычислительные мощности, сверяют производство и поставки чипов (благо сейчас >99% AI чипов выходят с одного производства — можно их начинать отслеживать прямо после схода с конвеера), допускают взаимные инспекции и проверки. Задача — ограничить объём неучтённых вычислений настолько, чтобы тайному проекту было трудно обогнать контролируемые разработки. После того, как начнут отслеживать мощности — можно начинать мониторить тренировки самых крупных моделей, проводить аудиты, например, на закрытых бенчмарках. Но чтобы ко всему этому прийти — нужно начинать диалог с малого.

Причина перекосов в уровне балансировки L4-балансировщик выбирает серверную ноду при создании соединения. Дальше http.Transport может переиспользовать это соединение через keep-alive, из за чего может случиться перекос нагрузки на одну ноду. Проблема далеко не новая, но я хочу разобрать отдельные решения подробнее. В чем, собственно, проблема: Для http 1.x свободные соединения в http.Transport переиспользуются по LIFO: логично, что нам выгоднее взять последнее освободившееся. Это видно в реализации http.Transport.queueForIdleConn и в самой модели http.Transport:

type Transport struct {
    ///
 idleConn     map[connectMethodKey][]*persistConn // most recently used at end
    ///

В отдельных кейсах типо #79664, LIFO может приводить к перекосу: если одна из нод отвечает немного медленнее остальных, её соединение позже возвращается в idle pool и оказывается последним использованным. Следующий запрос снова забирает его, нода опять отвечает дольше — и так по кругу. В данном кейсе мы минует L4 - ведь новых соединений нет и выбирать ему просто нечего. Периодическая ротация соединений встряхнет L4 (рис 1) В вышеописаном issue предлагают добавить новый параметр, который ограничит число запросов на одно соединение (MaxRequestsPerConn), чтобы они периодически закрывались и снова проходили через балансировщик. Например, можно периодически вытеснять активно переиспользуемые соединения через вероятностное включение Request.Close. Подобную задачу давно решают на инфраструктурном уровне, например, в nginx есть upstream параметры keepalive_requests - которое ограничивает число запросов и keepalive_time типо время жизни соединения. Поэтому часть подобных проблем по 10+ лет не доезжает до http.Transport: их уже умеет решать инфра снаружи. Балансировка на уровне пулов (рис 2,3) Можно поступить грубее и держать несколько независимых http.Transport и распределяться между ними. Так устроен clbtransport: снаружи это обертка, которая внутри ротирует запрос между несколькими пулами. Перед каждым запросом сравнивается два кандидата: один по round-robin, второй рандомный. Запрос уходит в тот пул, где меньше незавершённых запросов на пул (это кстати Power of Two Choices). К тому же пулы периодически пересоздаются в фоне с jitter, чтобы минимизировать одновременное закрытие и создание кучи соединений. Но внутри каждого пула остаётся LIFO, а конкретную ноду по-прежнему выбирает L4 только при создании соединения. Кастомная балансировка на уровне отдельного RPC - на примере gRPC (рис 4) В http2 привязка к соединению становится ещё важнее: через одно соединение одновременно может идти множество стримов. Видимо поэтому в gRPC балансировку вынесли в клиент благодаря отдельным моделям: Resolver, который получает адреса доступных нод (аля service discovery), Picker - модель, которую выбирает подходящее соединение (`SubConn`) для каждого запроса. Клиент может поддерживать соединения сразу с несколькими нодами напрямую, если перед каждым запросом вызывать Picker, который выбирает подходящий SubConn по заданной стратегии - например round-robin или least-request, который тоже использует Power of Two Choices. Но в отличие от clbtransport, здесь выбор происходит уже между конкретными нодами, а не между пулами с агрегированным счётчиком активных запросов на каждый пул. Не буду пересказывать то о чем можно почитать в доке gRPC. И подробнее про реализацию кастомного grpc балансировщика На этих примерах хорошо видно, что балансировка зависит в том числе от уровня, где она вызывается. В http.Transport для http 1.x L4 участвует только при создании соединения. Пока keep-alive соединение переиспользуется, новый выбор ноды не происходит - для этого нужно открыть новое соединение. В gRPC балансировку встроили прямо в клиентскую модель: он поддерживает соединения с несколькими нодами и выбирает подходящее для каждого запроса. Нравится..

Compile by Training Нейрокомпилятор. Превращает текстовое описание задачи в маленькую локальную нейросеть, выполняющую поставленную задачу PAW (Program-as-Weights) работает так: «программа» это веса лоры поверх общей нейросети-интерпретатора (~0.6B). Интерпретатор один для всех программ. Лора весит копейки, ее можно хранить, версионировать и комбинировать как обычный файл, но исполняется она нейросетью Сборка: промпт → черновик → учитель генерирует примеры → интерпретатор дообучается на них → готовая .paw-функция. На все около минуты Годно для любых задач которые можно описать как функцию от входа к выходу На FuzzyBench-Hard — 83.6% семантической точности. Уже работает в многосайтовом помощнике, 3D-аватаре с голосовым управлением и переводчике с английского на выдуманный язык Claudish Гитхаб Демо #coding

Вчера была пятница, и в Яндексе прошел традиционный еженедельный хурал 🙂 Много лет назад эта очень интересная традиция корпоративной культуры родилась как-то случайно из обычных планерок, но оказалась очень живучей и очень востребованной — а по мере роста компании и все более важной. Первые годы существования хурал был интересной частью моей собственной работы: я хуралы активно готовил и в большинстве случаев сам и вел. Теперь это — серьезная работа нескольких команд, и очень здорово, что об этом сняли фильм, который не только внутри показывают, но и выложили в публичный доступ на Кинопоиск. Фильм любопытный и не слишком долгий; интересующимся корпоративными культурами бигтехов будет интересно посмотреть:) https://www.kinopoisk.ru/film/13409687/

Как научиться предсказывать что угодно? 🔮 На видео спикер рассказывает, что его команда научилась за три дня до расставания предсказывать, что девушка бросит парня. Когда я впервые увидел это в трансляции, то понял только часть проблемы: спикер вообще не шарит, а команда решает странные задачи и пилит такие же фичи 😅 Тогда моего руководительского опыта не хватило, чтобы задуматься о процессах внутри компании — меня просто поразил уровень абсурда. Причём настолько, что эта история догнала меня даже спустя семь лет. Но сейчас, когда я строю собственную компанию, меня гораздо больше беспокоит другой вопрос: какие процессы внутри компании привели к тому, что топ-менеджмент рассказывает об этом на конференции как об успешном кейсе? 🤔 Начнём с самого кейса. Пока я не пересмотрел видео, у меня были разные гипотезы о том, как они собрали целевую переменную: — может быть, провели опрос? — спарсили социальные сети? — а как тогда собрали хард-негативные сэмплы? Но нет. Судя по видео, аналитики придумали сегмент на основе набора косвенных признаков. С какой точностью этот сегмент отражал реальность? Правильно: никто не знает 🙃 Дальше, вероятно, построили модель, которая научилась предсказывать эту синтетическую целевую переменную. И здесь появляется ещё один уровень неопределённости. Сначала мы с неизвестной точностью восстанавливаем целевую переменную по косвенным признакам. Затем с некоторой точностью обучаем модель предсказывать уже эту восстановленную переменную. То есть модель предсказывает не само расставание, а предположение аналитиков о расставании. На ошибку при создании таргета накладывается ошибка самой модели. Поэтому итоговое качество относительно реального события становится ещё менее понятным 🎯 Следующий вопрос: как проверяли лики? Не протекли ли в модель те же признаки, на основе которых изначально восстановили целевую переменную? 🫠 Ну и самое интересное: как измерили эффект? Никак. Модель встроили в рекомендательную систему, в которой, судя по рассказу, нет прозрачно рассчитанного финансового эффекта 💸 Итак, рецепт, как научиться предсказывать что угодно: 1. Конструируете целевую переменную с неизвестной точностью. 2. Обучаете модель предсказывать этот синтетический таргет. 3. Получаете два слоя ошибки: в разметке и в самой модели. 4. Встраиваете модель в продукт, где невозможно оценить её эффект в деньгах. 5. Рассказываете об успешном кейсе на конференции. 6. Готово — вы великолепны! 🚀 Всё это звучит смешно ровно до того момента, пока вам самим не приходится собирать такие фантастические сегменты и обучать на них модели. Напишите в комментариях, если знаете достоверный источник данных для такого сегмента. Особенно интересно, где взять качественные хард-негативные сэмплы 👇

Я думаю, что нас ждет локальная llm как часть операционной системы. Мы в Steelman тренируем модели на computer use тректориях, поэтому активно догфудим дату. У нас есть навайбкоженный мной рекордер для записи экрана и системных ивентов с тонной кастомной логики. Установщик у него такой: "дай своему клоду/кодексу эту ссылку и скажи поставить, вот конфиг и ключи." Для обновления: "скажи своему этому пусть обновит." Я уже не помню когда последний раз разбирался в деталях как что-то поставить или настроить. А помните старые времена, до докера, когда частью навыков программиста было понять, как на одной машине установить две версии постгресса? Хорошо, что этот кошмар позади. Другой пример. Я поставил себе на Rog Ally X Готику 2 (точнее фанатский мод Archolos), но она жутко лагала. Запряг клода, он там нашел какой-то патч, чтобы перевести игру на современный DirectX. Все стало летать и графика стала лучше. Думаю смержить мегапак модов на New Vegas и заставить их запуститься оно тоже может. В общем, я думаю это новая норма. Причём мне кажется такой помощник/инсталлятор не обязан быть Фейбл 5.1. Я думаю и небольшая модель справится. И я думаю это может поменять как делается и дистрибьютится софт. Раньше вся работа ложилась на разработчика. Он должен сделать билд под все платформы которые хочет поддерживать и постоянно всё тестировать. Предполагается, что клиент не может и пальцем пошевелить. Однако в мире где к каждому компьютеру прилагается LLM разработчик может делать лишь некоторое ядро функционала, а затем каждый клиент допилит под себя всё необходимое, чтобы это запустилось на конкретно его утюге. Возможно это будет частью процесса инсталляции. В детстве мы смотрели за ползунком прогресса установщика где в основном была распаковка. А в будущем будем смотреть за ползунком, а под капотом там пережатый в 300 шакалов GLM Flash пишет драйвера.