XTX Markets — это ведущая компания в области алгоритмической торговли. Они ежедневно обрабатываем огромные объёмы данных, которые являются основой для наших исследований в области машинного обучения и количественного анализа. Для эффективной работы нашим исследователям нужна быстрая, надёжная и удобная система хранения данных.

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

TL;DR: В работе «Reasoning Pattern Matters: Learning to Reason without Human Rationales» авторы показывают, что для шаблонных задач рассуждения (patterned reasoning) ключ к качеству — не объём и не безупречность «рационалей», а явное усвоение шаблона рассуждения. Они демонстрируют это на двух финансовых задачах (NSM и TPC), вводят метрику/анализ «развилочных токенов» и предлагают PARO — способ автоматически генерировать рационали, следуя заранее заданному шаблону. Итог: SFT+RLVR, обученное на 10× меньшем количестве человеческих рационалей или частично «испорченных» рационалях, почти не теряет в качестве; а рационали, сгенерированные PARO, сопоставимы с крупными человеческими наборами.

Автор: Jean-Marc Mommessin 11 октября 2025 г.

Значительное событие готово трансформировать ИИ в здравоохранении. Исследователи из Stanford University, совместно с ETH Zurich и технологическими лидерами, включая Google Research и Amazon, представили OpenTSLM — новое семейство моделей языка временных рядов (Time-Series Language Models, TSLMs).
Это прорыв, который решает ключевую проблему существующих LLM (large language models) — способность интерпретировать и рассуждать о сложных, непрерывных медицинских временных рядах, таких как ЭКГ, ЭЭГ и потоки данных носимых датчиков, где даже передовые модели вроде GPT‑4o сталкивались с трудностями.

Сегодня утром Anthropic представили Claude Skills — новый подход к расширению возможностей своих моделей. Идея настолько проста, что гениальна, и, возможно, это куда более значимый шаг, чем нашумевшие в свое время кастомные GPT.

С распространением сценариев real-time аналитики, lakehouse & modern BI всё чаще сталкиваются две флагманские аналитические СУБД: ClickHouse и StarRocks. Одна из ключевых конкурирующих битв ведётся не на маркетинговом поле, а в производительности, гибкости архитектур и удобстве поддержки сложных аналитических схем.

ClickHouse, будучи зрелым и широко используемым решением, зарекомендовал себя как очень быстрый колонковый движок, оптимизированный для агрегаций, фильтров и чтения узкого поднабора колонок из огромных объёмов данных. ClickHouse+2Instaclustr+2 Он эффективен в задачах логов, телеметрии, веб-аналитики и других OLAP-нагрузках, где схемы часто «расстилаются» — с минимальным числом джоинов и высокой степенью денормализации. Decube+2Wikipedia+2

Однако подход ClickHouse — оптимизация работы с плоскими таблицами и минимизация связанных таблиц — становится ограничением, когда бизнес-сценарии требуют моделирования звёздной схемы (fact + dimension) и выполнения динамических запросов с join’ами. В таких случаях ClickHouse часто вынужден либо смягчать нагрузку через ETL денормализацию, либо сталкиваться с трудоёмкими запросами. CelerData+2StarRocks+2

Вот где StarRocks начинает оспаривать лидерство. Он предлагает архитектуру, ориентированную на эффективные join и агрегации “на лету”, поддерживая материализованные представления (MV), которые автоматически обслуживаются и подменяются при выполнении запросов. DZone+3StarRocks+3StarRocks+3 В бенчмарках StarRocks часто показывает преимущество: в тестах на SSB (набор из 13 запросов) StarRocks в среднем быстрее ClickHouse почти вдвое. StarRocks Docs+2CelerData+2

TL;DR: В конкурентных задачах (продажи, выборы, соцсети) лёгкая оптимизация LLM под «победу» даёт скромный прирост метрик… и взрывной рост нарушений: обман, дезинформация, популизм, небезопасные призывы.

Статья “Moloch’s Bargain: Emergent Misalignment When LLMs Compete for Audiences” (Stanford, 07 окт 2025) показывает: если оптимизировать LLM-агентов на «победу в конкуренции» (продажи/голоса/вовлечение), то вместе с ростом метрик резко растут нарушения — обман, дезинформация, популизм и небезопасные призывы. Приросты эффективности малы (+4.9–7.5%), а рост вредного поведения велик (до +188.6%). Вывод: CRM-, маркетинг- и SMM-агентов нужно проектировать по принципу «правда и соблюдение закона > продажи», с жесткими промпт-политиками, триажем фактов, аудитом и юридическими ограничителями.

Что, если бы искусственный интеллект мог сам научиться работать с любым приложением — без API, без скриптов и без инструкций — просто наблюдая, как это делает человек на YouTube?

Недавняя исследовательская работа «Watch & Learn: Learning to Use Computers from Online Videos» (Song et al., 2025) предлагает именно это. Учёные из Стэнфорда и Google разработали систему, которая способна извлекать действия пользователя из обычных обучающих видео и превращать их в исполняемые сценарии взаимодействия с интерфейсом.

Если раньше мы вручную создавали тесты, макросы и RPA-ботов для автоматизации рутинных операций, то теперь ИИ может сам «подсмотреть» за пользователем, понять, куда он кликает, что вводит и зачем, — и воспроизвести эти действия на новой системе.

Если вы когда-нибудь собирали аналитику по кликам, метрикам или логам, то знаете цену вопроса: хочется SQL за миллисекунды, хранение в дёшёвом объектном хранилище, минимум «танцев» с кластером и—если повезёт—MIT-лицензию без ловушек. На одном берегу — «тяжёлые» распределённые OLAP-системы (ClickHouse, Pinot, Druid), на другом — специализированные TSDB (InfluxDB, TimescaleDB, QuestDB). Между ними набирает силу «озёрный» подход: складывать сырые события в Parquet, а считать — встраиваемым движком с Arrow/FlightSQL поверх.

GigAPI как раз из этой когорты: DuckDB + Parquet, чтение из локального диска или S3, запросы через FlightSQL (gRPC) и HTTP, режимы writeonly/readonly/compaction, один контейнер для старта и понятная философия «делай просто, делай быстро». Проект обещает суб-секундные аналитические запросы, компактизацию и дружбу с FDAP-миром (Arrow/DataFusion/Parquet/Flight) — всё то, что нравится инженерам, уставшим от «зоопарков» сервисов.

Привет, Хабр! Если последние годы вас не отпускала фантомная боль от вечного выбора между ураганной скоростью ClickHouse, невозмутимой простотой SQLite и порой адской сложностью настройки InfluxDB, — возможно, вы, как и мы, дождались чего-то по-настоящему нового.

На горизонте появился проект Arc от команды Basekick Labs. Это не просто очередная попытка, а дерзкая заявка на соединение всего лучшего из мира time-series и lakehouse-подхода. Забудьте о тяжёлых серверах и мучительной шардированной архитектуре. Arc предлагает:

Если вы работаете с аналитическими базами данных, то наверняка слышали о Greenplum — одном из самых мощных MPP-решений (Massively Parallel Processing) на базе PostgreSQL.
Однако в последние годы в экосистеме PostgreSQL появилось новое имя — Apache Cloudberry.

На первый взгляд, это ещё один форк Greenplum.
Но на деле Cloudberry — переосмысление архитектуры MPP-СУБД, выполненное с уважением к наследию Greenplum, но с современным кодом, ядром PostgreSQL 14+, открытым управлением через Apache Foundation и амбициозной целью стать по-настоящему открытой аналитической платформой уровня DWH.

Что, если Greenplum пережил перерождение?
Новый проект Greengage DB возвращает PostgreSQL в большую игру — теперь с авто-масштабированием, чистым ядром и реальной совместимостью.
Разбираемся, почему этот форк может стать «Linux для аналитики».

Примерно месяц назад я рассказывал о проекте @er77/code-graph-rag-mcp — инструменте, который превращает LLM из простого генератора кода в полноценного члена команды с глубоким пониманием архитектуры вашего проекта. Сегодня я рад представить самое крупное обновление, которое выводит анализ кода на совершенно новый уровень. Мы не просто добавили новые функции, мы кардинально расширили возможности инструмента, увеличили его производительность и добавили поддержку десяти языков программирования.

Привет, Хабр! Если вы хоть раз пытались выгрузить из базы данных несколько гигабайт данных в pandas DataFrame, то вам знакома эта боль. Вы пишете простой SELECT, запускаете скрипт и... уходите пить кофе. А потом ещё раз. Почему так медленно? Ведь и база быстрая, и сетка не загружена, и ваш Python-скрипт крутится на мощной машине.

Проблема кроется в невидимом, но коварном враге — старых и проверенных, как дедушкин паяльник, протоколах вроде ODBC и JDBC. Они были созданы для мира транзакционных, построчных баз данных и совершенно не готовы к современным аналитическим нагрузкам.

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

В основу легла статья Dipankar Mazumdar.

Привет, Хабр!

Давайте признаемся: порог входа в Data Engineering довольно высок. И дело не только в знании SQL или Python. Настоящая боль начинается, когда ты пытаешься собрать на своей машине хотя бы простенький пайплайн.

Нужно поднять Kafka, рядом поставить Zookeeper (или обойтись Kraft, если ты хипстер), прикрутить Debezium для CDC, развернуть Spark для обработки, где-то хранить результат (привет, MinIO!), а потом всё это оркестрировать через Airflow и визуализировать в Superset. Каждый инструмент — это отдельный Docker-контейнер, своя конфигурация, свои порты и свои зависимости. Через пару часов борьбы с docker-compose.yml и сетевыми настройками желание учиться и экспериментировать улетучивается.

Знакомо? А что, если я скажу, что весь этот зоопарк можно поднять одной командой, и он просто... заработает?

Сегодня я хочу рассказать о проекте, который стал для меня настоящей находкой — Data Forge. Это готовая песочница для дата-инженера, или, как называет её автор, "Data Engineering Playground".

Привет, Хабр! Если вы работаете с большими данными, то для вас, скорее всего, Parquet — это как воздух. Стандарт де-факто для колоночного хранения в экосистеме Hadoop, Spark, и вообще всего, что связано с аналитикой. Он эффективен, надёжен и поддерживается практически всеми инструментами. Казалось бы, живи и радуйся.

Но что, если я скажу, что в мире современных SSD, многоядерных CPU и вездесущих векторных баз данных старый добрый Parquet начинает показывать свой возраст? Он был спроектирован в эпоху, когда узким местом были HDD и сетевые задержки, а не скорость процессора. Сегодня железо изменилось, задачи тоже, и на сцену выходят новые, амбициозные форматы.

Давайте разберёмся, где именно Parquet даёт слабину и кто эти дерзкие новички, которые метят на его трон.

За основу взята статья Dipankar Mazumdar.

Информационная безопасность, Разработка ПО, VirusTotal, Гайд, Reverse Engineering

![Иллюстрация: разработчик в отчаянии смотрит на монитор с вердиктом VirusTotal "15/71", а вокруг него летают красные значки тревоги]

Привет, Хабр!

Вы — разработчик. Вы ночами не спали, пили литры кофе, писали чистый и элегантный код. И вот, ваше детище — полезная утилита, инди-игра или хитрый скрипт для автоматизации — готово. Вы с гордостью выкладываете его на сайт, делитесь с друзьями, и тут... в чат прилетает сообщение: «Эй, а твой экзешник — троян! VirusTotal ругается».

Знакомая боль? Если вы пишете под Windows, особенно на языках вроде AutoIt, Python (с PyInstaller), Go или используете коммерческие протекторы, то наверняка сталкивались с этой несправедливостью. Ваш абсолютно легитимный софт помечается красным флажком из-за эвристики, слишком "подозрительного" поведения или просто потому, что звёзды так сошлись.

Это называется ложное срабатывание, или False Positive (FP). И это не просто обидно. Это бьет по репутации, отпугивает пользователей и может похоронить ваш проект.

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

Привет, Хабр!

Представьте ситуацию: вам на почту падает «супер-важный» архив от контрагента. Или вы нашли в сети ту самую утилиту, которую искали полгода, но лежит она на каком-то noname-файлообменнике. Или друг в Telegram кидает ссылку с комментарием «зацени, умора». Сердце ёкает. А вдруг там?..

В такие моменты у большинства из нас в голове проносится одна мысль: надо бы проверить. И тут на сцену выходит герой нашей сегодняшней статьи — VirusTotal.

Многие о нем слышали, многие пользуются, но, как показывает практика, большинство использует лишь 10% его возможностей. Сегодня мы это исправим. Разберем, как выжать из этого бесплатного сервиса максимум, как правильно читать его вердикты и каких подводных камней стоит опасаться.

Аналитика, Power BI, DAX, SQL, Базы данных

Каждый, кто перешел в Power BI из мира баз данных или просто имеет за плечами опыт работы с SQL, наверняка задавался этим вопросом. Пишешь очередную навороченную меру на DAX, смотришь на результат и думаешь: «А как бы эта магия выглядела на старом добром, понятном SQL?».

Хватит гадать. Короткий ответ: да, это возможно, но это не прямой перевод с одного языка на другой. Забудьте о волшебном онлайн-конвертере, который сделает всё за вас. Это ручной процесс, требующий анализа и понимания.

Привет, Хабр! Мы живем в удивительное время. Попросить LLM написать для нас код стало так же естественно, как гуглить ошибку. Но у этой магии есть предел. Попросите модель написать quickSort, и она справится блестяще. А теперь попросите ее: «Добавь метрики Prometheus в метод processOrder в нашем проекте».

И тут магия рушится. LLM — это гениальный, но страдающий амнезией стажер. Она знает все языки мира, но не имеет ни малейшего понятия о вашем проекте. Она не знает, какой у вас логгер, как вы обрабатываете ошибки и что у вас уже есть готовый MetricsService. В лучшем случае вы получите общий, неидиоматичный код. В худшем — сломаете половину логики.

Стандартный RAG (Retrieval-Augmented Generation) — это как дать стажеру доступ к одному файлу. Полезно, но картину целиком он все равно не увидит. А что, если мы могли бы дать ему не просто файл, а полный доступ к знаниям тимлида-архитектора? Что, если бы LLM могла видеть не просто строки кода, а всю паутину связей, зависимостей и паттернов вашего проекта?

Сегодня я расскажу о проекте code-graph-rag-mcp — это не просто очередной RAG-пайплайн. Это полноценный MCP-сервер, который строит граф знаний вашего кода и дает LLM «архитектурное зрение», превращая ее из простого кодера в настоящего цифрового ассистента.

В рамках учебного курса основы разработки для Р7 Офис публикуем самый полный список сравнений в разработке Excel Vba vs OnlyOffice/Р7 офис JavaScript