TabFM умеет получать предсказания по таблицам без обучения на конкретном датасете — и на бенчмарках уже обходит настроенный бустинг. Разбираемся, насколько убедительны эти результаты, где у модели заканчивается преимущество и что изменится для тех, кто держит табличный ML в проде.
AI-агенты - это цикл обмена сообщениями между пользователем и языковой моделью (LLM), где для ответа пользователю модель может обратиться к доступным ей напрямую инструментам (tools) или через настроенные для неё MCP. Каждое такое взаимодействие дописывает историю диалога. Для простоты часто считают, что вся эта история и уходит в любой следующий вызов модели - иначе она «не вспомнит», о чём шла речь, и криво соберёт ответ.
История «не резиновая» - у современных моделей контекстное окно может быть огромным, но умение работать с длинным логом сильно зависит от того, насколько он структурирован. Плюс накопленная история разговора и реальный контекст, который модель видит на очередном ходе, не всегда одно и то же. В последнее время это один из фокусов развития агентских систем в рамках context engineering: что сжать, что оставить снаружи, что подтянуть инструментами только когда нужно.
В этой статье хочу рассказать про эволюцию подхода работы с длинной историей и где мы находимся сейчас. Примеры будут на LangChain - на открытом стеке легко посмотреть реализацию, которая в готовых продуктах часто спрятана. При этом LangChain достаточно популярный, развивающийся фреймворк - остальные либо делают похожие вещи, либо сами опираются на него как на базу.
Это моя первая публикация на Хабре, который я читаю уже лет 10... Так что, если честно, даже немного трясусь от волнения. Всё равно что смотреть футбол и выйти на поле в составе моего любимого Кайрата. Но постараюсь без лирики и перейду к делу.
Итак, в 2026 году уже всем как будто понятно, что потенциальные клиенты всё чаще выбирают банк не в поиске, а в диалоге с нейросетью (хотя многие с этим до сих пор почему‑то спорят). На выходе клиент получает короткий список из трёх‑четырёх названий.
Так как я занимаюсь аналитикой данных, мне стало интересно, по какому принципу этот список собирается, как эти данные обрабатываются, и кто вообще попадает в этот заветный шорт‑лист.
Ниже я описываю, как за пару вечеров собрал на Python замер видимости банков Казахстана в пяти ИИ‑ассистентах, на что напоролся и к каким выводам в итоге пришел. Код и формулы прилагаю, цифры можно перепроверить, если у вас будет желание.
Наверное уже многие знают, что в силу недавно вступивших в ЕС законов, регулирующих использование ИИ, провайдеры LLM обязаны помечать ИИ-сгенерированные тексты. Та же Claude недавно обновила справочную информацию о работе своей помечалки сгенерированного ИИ контента, в том числе и текста. Но в подробности его работы почему-то вдаваться не стала, как и размещать в публичном доступе средства добавления и обнаружения этих самых вотермарок.
Не то чтобы я часто балуюсь текстовым нейрослопом, но сама идея того, что твой текст могут им объявить чисто случайно или в следствии того, что ты отредактировал иишкой его часть, меня не сильно радует. Поэтому в этой статье мы разберемся, как собственно эти метки работают, и как с ними бороться.
Недавно я решил проверить на себе классический сюжет: может ли нейронка зарабатывать на бирже. Не «взял стратегию с ютуба», а как положено инженеру: собрал данные Мосбиржи, построил честный walk‑forward пайплайн, зашил комиссии в каждую цифру и стал измерять.
Эта статья — про самый неочевидный урок, который я получил. Он не про рынок и не про архитектуры. Он про то, что результат бэктеста нейронной сети — случайная величина с разбросом в десять процентных пунктов годовой доходности, и если вы это не учитываете, все ваши выводы — шум.
Подозреваю, что этим страдает заметная часть статей вида «я обучил LSTM на котировках и получил X% годовых». Проверить легко: спросите автора, что будет, если поменять random seed.
Прогулка по подземельям — это минималистичная, но при этом очень интересная и сложная головоломка из игры MIT Mystery Hunt 2014 года. Она представляла собой видеоигру со множеством уровней, каждый из которых был подземельем с различными препятствиями и врагами, которые игроку нужно было преодолеть, чтобы добраться до выхода. Пройти первые несколько уровней не представляло особого труда — их главной целью было познакомить игрока с основными механиками игры. Однако затем сложность и оригинальность уровней резко возрастали, и каждый их них представлял собой уже далеко не тривиальную задачу.
В статье описывается Python пакет peacepie — экспериментальная фреймворк, реализующий акторную модель с динамически загружаемыми акторами из внешних пакетов во время выполнения. Основная область применения — автоматизация, бэкенд. Акторы, реализованные во внешних пакетах, демонстрируют необычайную подвижность благодаря своей изолированной природе.
Поскольку пакет представляет собой автономный модуль кода, его легко перемещать между различными процессами или даже узлами в распределённой системе. Это свойство делает акторы, созданные на основе таких пакетов, чрезвычайно гибкими и независимыми от конкретной среды выполнения.
Увы, у меня нет профильного математического образования (я вообще гуманитарий), потому любой стандарт по криптографии для меня ничто иное, как поросячья латынь. А после детального изучения приходит горькое осознание, что это я лезу в калашный ряд со свиным рылом... И вот прилетела задача, решить которую промптом не получится (я пробовал, честно), а потому надо лезть в калашный ряд ISO9797-1 и смотреть, что там такое делается. Результаты изучения решил расписать здесь, т.к. может кому-то будет полезно, а может кто-то из crypto-лордов укажет на недочеты/ошибки.
Привет, Хаброжители! Извлечение ценности из данных — сложный процесс. Чтобы превратить данные в информацию, бизнес-аналитик должен уметь работать с различными технологиями, включая базы данных, языки программирования и коммерческие аналитические инструменты.
Преодолейте разрыв между миром технологий и бизнеса. Сосредоточьтесь на развитии необходимых навыков с помощью R и Python на примерах из реальной жизни. Узнайте, какие методологии стоит использовать для успешной реализации проектов.
После моей прошлой статьи в Telegram-бот за один день пришли 60 человек. Я тогда подумал: ну всё, полетело. Спойлер: не полетело.
Сейчас в базе почти 300 аккаунтов, за неделю возвращаются 11 человек, средний DAU 7, а реферальная программа привела троих. Разбираю честную воронку, ошибки с метриками, странный парадокс обратной связи и V2, которая должна проверить одну конкретную вещь: получится ли удержать хотя бы четыре возвращения из семи.
Привет! Меня зовут Кристина, я MLOps-инженер в Туту. Занимаюсь тем, что помогаю рекомендательным системам добраться до прода со всеми компромиссами, горящими дедлайнами и новыми идеями.
Эта статья — про один из таких запусков.
В идеальном ML-мире запуск рекомендаций выглядит примерно так: полгода проектируют хранилище признаков (Feature Store), настраивают, откуда и как берутся данные, гоняют тяжёлые расчёты фичей и моделей, а отдельная команда следит, не деградирует ли модель из‑за изменений в данных.
В реальном бизнесе у тебя есть 5 недель до старта высокого сезона, два инженера, DS и задача: сделать так, чтобы пользователь, который купил билет, сразу увидел релевантный отель. Рассказываем, как мы собрали работающую RecSys v1 на привычном стеке: Kafka, MongoDB, ClickHouse. При этом мы сознательно отказались от перфекционизма ради скорости.
Инженерный вызов здесь не в масштабе и не в алгоритмах, а в контексте. Cross-sell в travel — это не «похожие товары».
Пример
Пользователь купил билет Москва → Сочи на 10–17 июля: значит, нужно показать отели именно в Сочи, именно на эти даты.
Коллаборативная фильтрация без контекста поездки — «похожие пользователи → похожие отели» — не знает ни город, ни даты, ни то, что заказ только что оплачен и его ещё нет в DWH.
Нужен подход, где контекст конкретной поездки — куда, когда, с кем — задаётся явно до ранжирования.
«Правильный» путь — Feature Store и полноценная ML-платформа, занял бы 4–6 месяцев. Бизнесу нужно было проверить гипотезу на живом трафике. Мы собрали v1 на том, что уже работало в проде, с некоторыми компромиссами и без иллюзий насчёт идеальной архитектуры.
Увидел провал на графике → открыл Google или Twitter → полдня собираешь версии "почему". Знакомо? Детектор аномалий сам по себе даёт только точки на оси времени, а вопрос "почему" как был ручным, так и остаётся.
В этот раз я прогнал WhyTrend не на паре аккуратных точек из Google Trends, а на полном ряде BTC за 4.5 года — и заодно на двух разных LLM. Результат оказался неожиданным: модель меньшего размера дала в три раза больше настоящих объяснений, чем более крупная. Расскажу, что случилось и почему.
У меня есть руководитель, который очень хорошо ревьюит документы. Настолько хорошо, что один его проход по моим текстам породил 73 комментария. За один день.
Первая реакция была ожидаемая: сесть и править. Вторая пришла минут через десять и оказалась продуктивнее: это же датасет.
Дальше — история о том, как замечания одного конкретного человека превратились в чек-лист из 16 правил, чек-лист — в этап конвейера, а следующая партия документов ушла без единой правки по старым паттернам. С кодом, промптами и одним неудобным вопросом в конце.
Сервис диагностики двигателей автомобилей по звуку ставил «поломку» в 71% случаев. Я грешил на дешёвые телефоны, но проблемой оказалась тишина
RSS растёт к лимиту контейнера, tracemalloc показывает прежние 180 МБ, а gc.collect() ничего не меняет. Разберём, как в такой ситуации отделить утечку Python-объектов от нативных аллокаций и удержания памяти системным аллокатором — и понять, где именно искать причину до OOMKilled.
REST Битрикс24 можно удобно использовать из Python — для интеграций, миграций, аналитики и служебных скриптов.
Разбираем библиотеку a24wh: шесть функций, которые упрощают запросы, пагинацию, batch-вызовы и обработку ошибок.
Привет, Хабр! (И тебе, 1С-ник, который открыл статью только чтобы убедиться, что пока точно не надо изучать новый продукт. И тебе, питонист, который сейчас будет морщиться. И тебе, мобильный разработчик, который уверен, что без Kotlin/Swift нормальное приложение не родится - держи кружку крепче.)
Эта статья будет посвящена технологии, на которой можно написать своё мобильное приложение за пару дней. И я вам на примере реализованного мною полноценного проекта логистического приложения покажу, что сейчас из себя представляет эта технология на нашей родной КИРИЛЛИЦЕ, и что на ней можно сделать прямо сейчас. И самое главное, как…
Приветствую, Хабр! Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК Infowatch.
В этой статье мы построим основу лаконичного фреймворка для UI-автотестов. Настроим запуск браузера, подготовим авторизацию, создадим Page Object и напишем тест. Здесь не будет лишних обёрток и сложной инфраструктуры, не будет даже ИИ и прочего хайпа. Только проверенные решения на базе Playwright, готовые к использованию.
Главная идея — максимально использовать возможности самого Playwright, а не строить вокруг него собственный слой абстракций.
Рассмотрим следующую задачу:Пусть есть металлическая равномерно заряженная и очень тонкая(высота пренебрежимо мала по сравнению с размерами) прямоугольная пластина размера 2a на 2b. Поверхностная плотность заряда σ>0. Требуется определить
электрическое поле E(x0,y0,z0), созданное этой пластиной в любой точке x0,y0,z0 трёхмерного евклидова пространства. А также рассмотреть случай пластины в форме эллипса.
Это история о том, к чему привело моё желание иметь часы, которые в магазине не купишь.
Ещё с детских лет у моей кровати всегда стояли какие-нибудь дешёвые часы с красными семисегментными индикаторами и функцией радио, купленные в Walmart или Target. Это всегда были дешёвые, простые и живучие модели — вот только все они неизменно требовали ручной подстройки при переходе не летнее/зимнее время и при сбое питания. И после недавнего такого сбоя, когда я в очередной раз стоял у тумбочки, зажав кнопку «TIME» и лихорадочно нажимая кнопку «HOUR», моё терпение лопнуло: «Мы прожили уже четверть 21-го века. Должен же быть какой-то более совершенный способ!»
В моём представлении идеальные часы должны уметь сами настраивать время. Они должны автоматически переходить на летний/зимний режим (или нет, в зависимости от того, чем закончится этот законопроект) и компенсировать погрешность хода, всегда показывая точное время вплоть до миллисекунд. Плюс они должны показывать это время на семисегментном дисплее красными цифрами — не синими, не зелёными, не жёлтыми и уж точно не белыми. И всё это не должно требовать установки всяческих мусорных шпионских приложений.
