Если вы хоть раз обучали модель компьютерного зрения, вы знаете, как качество данных решает всё. На первый взгляд кажется, что задачи у всех инструментов одинаковые: поставить рамку, провести полигон, экспортировать данные, но в реальности всё упирается в детали...
Привет, Хабр!
В последние годы потоки данных в различных системах и между ними только увеличиваются, а в дальнейшем этот тренд наврятли изменится. Для работы с данными всегда требуются различные инструменты.
Apache NiFi — программный продукт с открытым исходным кодом, написанный на языке Java, предназначенный для автоматизации потоков данных между системами. Главная его задача: организовывать ETL-процессы. На GitHub у Apache NiFi имеется 5.9 тысяч звезд.
Эта статья посвящена написанию процессора для Apache NiFi на Java и требует базовых знаний в области Apache NiFi, опыт программирования на Java и IDE на борту компьютера.
В этой статье мы поговорим о том, как реализовать поведение атомарной вставки в ClickHouse. Рассмотрим несколько вариантов, подсветим их сильные и слабые стороны, а также, когда каждый из них применять.
Когда пришло время выбирать тему диплома, я, как и многие студенты, понятия не имел, о чём писать. После мозгового штурма с одногруппниками родилась идея, которая из простого «варианта для защиты» превратилась в полноценный инженерный проект: «исследование и разработка системы автоматического распознавания дефектов печатных плат».
Со временем я понял, что выбрал тему не случайно - это реально актуальная задача для производства, где качество пайки напрямую влияет на работоспособность устройств, а ещё отличный шанс пройти весь цикл Computer Vision проекта от сбора данных до обучения моделей.
Эта статья краткая выжимка моего опыта: как собрал собственный датасет дефектов печатных плат для обучения моделей, какие инструменты использовал и на что стоит обратить внимание.
Статья будет полезна:
Представим ситуацию: мы спланировали маршрут до точки назначения, предположили, по какой дороге будет быстрее добраться, даже вспомнили, где обычно бывают пробки, чтобы их объехать. Но, неожиданно, на самом свободном участке образовался затор из‑за аварии в правом ряду. В этот момент понимаем, что лучше бы мы ехали по навигатору, и какая‑нибудь «Анфиса» предупреждала о дорожной ситуации, чтобы в определенный момент можно было изменить траекторию движения. Именно так годами чувствовали себя пользователи Spark, когда их красиво оптимизированные запросы наталкивались на суровую реальность распределенных данных.
В статье рассказываем о подходе к построению DWH на базе единой инфраструктуры данных (Unified Data Infrastructure), разработанной Andreessen Horowitz.
Разбираемся, почему модель a16z полезна в быстрорастущих компаниях или тех, кто переходит к data-driven управлению.
Статья — практическое руководство по управлению привилегиями в StarRocks: объектная модель (SYSTEM, CATALOG, DATABASE, TABLE, VIEW, MATERIALIZED VIEW, FUNCTION и др.), перечень привилегий для каждого типа сущности и соответствующие операции. Разбираем роль‑based доступ (RBAC): встроенные роли (root, cluster_admin, db_admin, user_admin, public), создание собственных ролей и выдачу прав через GRANT/REVOKE с наглядными SQL‑примерами. Отдельный блок — особенности StarRocks: ограничение ресурсов на пользователя (max_user_connections), роли по умолчанию и их активация при входе, массовая выдача прав через public, выполнение от имени другого пользователя (IMPERSONATE/EXECUTE AS). Материал полезен инженерам данных, DBA и разработчикам, работающим с OLAP/MPP‑СУБД и хранилищами данных, а также тем, кто внедряет контроль доступа в аналитических кластерах. Дополнительно освещены создание пользователей с разными методами аутентификации (включая LDAP), управление RESOURCE/RESOURCE GROUP, GLOBAL FUNCTION и STORAGE VOLUME, а также практики безопасной раздачи прав по ролям.
Статья представляет техническое сравнение StarRocks и ClickHouse для real‑time аналитики. На идентичных AWS‑кластерах с набором ~1 ТБ (Parquet, >3 млрд строк) смоделированы параллельные нагрузки (k6) и непрерывный поток UPSERT из PostgreSQL через CDC. Оцениваются субсекундная Latency, согласованность обновлений, полнофункциональные JOIN и операционная простота (TCO). ClickHouse с Replacing/CollapsingMergeTree обеспечивает eventual consistency и нередко требует FINAL/внешних потоковых компонентов. StarRocks с Primary Key Model дает нативный UPSERT с мгновенной видимостью изменений и асинхронным Compaction. В бенчмарках StarRocks показал до ~40% преимущество в длинных запросах, лучший p99/QPS и стабильность (без HTTP 5xx). В контексте Lakehouse StarRocks сильнее за счет внешних таблиц и записи в Apache Iceberg. Рекомендации: ClickHouse — для append‑only сценариев; StarRocks — для real‑time аналитики с частыми обновлениями.
На данный момент я прохожу 5-дневный интенсив по AI-агентам от Google и параллельно веду собственный конспект. Эта статья представляет собой перевод оригинального материала, выполненный с помощью Gemini и мной. В некоторых местах я немного упростила формулировки или обобщила идеи.
Оригинал статьи тут Agent Quality
Другие статьи:
Интенсивный курс «AI-агенты» от Google День 1
Интенсивный курс «AI-агенты» от Google День 2
Интенсивный курс «AI-агенты» от Google День 3
StarRocks при каждом импорте данных создаёт новую версию, что со временем приводит к росту числа мелких файлов и падению эффективности запросов. Фоновый процесс Compaction объединяет версии, устраняет дубликаты и сокращает количество I/O. В материале разобраны: архитектура Compaction в режиме разделения хранения и вычислений (FE — Scheduler, BE/CN — Executor), диспетчеризация по Partition и Tablet, критерии безопасной очистки данных, а также практики тюнинга. Показано, как смотреть Compaction Score на уровне Partition, отслеживать и отменять задачи, и какие параметры FE/BE/CN действительно влияют на производительность (compact_threads, lake_compaction_max_tasks и др.). Отдельно затронут мониторинг и алерты в Grafana/Prometheus. Текст ориентирован на инженеров DWH/OLAP и эксплуатацию высоконагруженных систем хранения данных.
Многие задаются вопросом: «Зачем мне семантический слой? Что это вообще такое?» В этом практическом руководстве мы соберём самый простой семантический слой — всего лишь из файла YAML и Python-скрипта. Цель не в том, чтобы построить слой ради самого слоя, а в том, чтобы понять его ценность. Затем мы выполним запросы к данным о 20 миллионах поездок нью-йоркских такси, используя согласованные бизнес-метрики, при этом запросы выполняются через DuckDB и Ibis. К концу вы точно будете понимать, когда семантический слой действительно решает проблемы, а когда это избыточно.
Привет, меня зовут Вова Ловцов. Я дата-сайентист, работаю в команде Core DS в Cloud.ru, где мы занимаемся разработкой агентов, RAG-систем и других сопутствующих технологий.
Недавно мы запустили AI-помощника, который не только отвечает на вопросы по документации, разворачивает виртуальные машины и настраивает мониторинг за пользователей, но и помогает с SRE и FinOps. Под капотом это мультиагентная система, и один из ее ключевых компонентов — это RAG (Retrieval-Augmented Generation). Именно он отвечает за поиск информации и формирование понятных ответов.
Как понять, что RAG работает хорошо? Как его измерить, улучшить и выбрать лучшую конфигурацию? Обычные метрики вроде BLEU или ROUGE не всегда отражают качество ответа с точки зрения пользователя. Поэтому мы озадачились поиском автоматизированного и воспроизводимого решения и в итоге выбрали RAGAS — open source библиотеку для оценки RAG-систем. Но оказалось, что «из коробки» она работает далеко не идеально.
В этой части кратко расскажу про оценку и наш выбор исходя из внутренних особенностей. А в следующей — как подошли к адаптации RAGAS, какие проблемы встретили на пути и что придумали, чтобы их решить.
У знакомого есть консалтинговая компания по внедрению продуктов 1С в бизнес и он поделился болью - у его заказчика - среднего размера строительной компании необходимо внести в систему порядка нескольких сотен смет в xlsx формате в 1С конфигурацию, которую они внедряют.
Сложность в том, что другие инженерные отрасли сильно отстают от IT в плане культуры разработки. Во времена моей юности по ФИДО ходила присказка "Если бы строители строили дома, как программисты пишут программы, то первый же залетевший дятел разрушил бы цивилизацию". Скорее всего автор этого афоризма никогда не был знаком с реальными строителями. Сейчас скорее наоборот - если бы строители писали программы, мы бы не вышли из эпохи арифмометров. Мы в IT приучены к тому, что ревью кода не пропустил коммит с лишним пробелом.
У сметчиков же документация выглядит как в буквальном смысле черновики - все файлы разной структуры, с разным числом и содержанием колонок, разделы разного формата, где-то древовидные, где-то плоские, причём оформлены в разном стиле - где помечено цветом, где шрифтом, с комментариями на полях и прочее.
Дело осложняется тем, что одно и то же наименование может быть записано разными сметчиками по-разному. Где просто бетон, где бетон с указанием марки, слова в разном порядке, часто одно и то же наименование, но записано и вовсе разными терминами, где синтаксический анализатор бессилен, при том что термины для неспециалиста неочевидные и незнакомые.
Традиционный автоматический импорт в сметной документации невозможен. В итоге 6 сметчиков вводили одну строительную очередь больше 2-х месяцев - бюджет для компании-внедренца около 2-х миллионов.
Устали тратить часы на рутину? Пора автоматизировать ее с помощью n8n. В этой статье я расскажу про локальную установку и основу платформы
Substrait — это промежуточный формат (IR) для обмена планами запросов между системами. Он снимает боль диалектов SQL, позволяет делать pushdown в разные бэкенды и избавляет от повторного парсинга/оптимизации федеративных системах и позволяет относительно безболезненно заменять один бэкенд другим. Ниже - зачем он нужен, как устроен и кто поддерживает.
Большие языковые модели (LLM) стали основой современных ИИ-продуктов, обеспечивая работу всего - от чат-ботов и виртуальных ассистентов до исследовательских инструментов и корпоративных решений. Но LLM различаются по сильным сторонам, ограничениям и стоимости: одни лучше в рассуждениях, другие - в креативе, коде или работе со структурированными запросами. Здесь и нужен маршрутизатор LLM.
Маршрутизатор LLM работает как «умный диспетчер трафика»: он автоматически направляет промпты в наиболее подходящую модель под конкретную задачу. Вместо одной универсальной модели бизнес и разработчики повышают точность, скорость и снижают затраты, маршрутизируя запросы в реальном времени. По мере роста применения ИИ маршрутизация LLM становится обязательным слоем для масштабируемых, надёжных и эффективных систем.
Этот материал — про наш путь на ЛЦТ Фест 2025 в задаче «Интеллектуальный цифровой инженер данных». Мы пришли не с ещё одним «ML-демо», а с управляемым процессом импорта: Графовые структуры как мозг (сигнатуры, профили датасетов, шаблоны пайплайнов), MCP как оркестратор шагов, MinIO для presigned-загрузки без лишнего трафика, Airflow с одним универсальным DAG и Postgres на выходе. Вместо «магии нейросети» в критическом пути — алгоритмы и правила, а LLM — ассистент и объяснитель. Результат — предсказуемость, воспроизводимость и ощутимая экономия: один процесс вместо зоопарка MVP, storage-first вместо переделок, повторное использование классов и шаблонов вместо ручных костылей.
AI-драгдизайн: первая молекула прошла Фазу II. Разбираем, как GNN, AlphaFold 3 и $2.23 млрд на провал меняют фармакологию
Привет, Хабр! Меня зовут Екатерина, я практикующий инхаус-юрист с фокусом на IT, IP и рекламе. Недавно я начала экспериментировать с технологией Retrieval-Augmented Generation и векторным поиском в юридических задачах, а также исследовать архитектурные подходы к построению баз знаний в юриспруденции. Этот материал — обзор трёх публикаций о способах построения таких баз, а также моя попытка начать формулировать методологию структурирования юридического знания для RAG. Буду признательна за любой инпут со стороны ML-специалистов.
Недавно на Хабре вышла статья с громким заголовком «Бенчмарк lakehouse‑движков, часть 1: StarRocks и Doris падают под нагрузкой, Presto аутсайдер, CedrusData быстрее всех». В своей статье авторы из Кверифай Лабс выбрали методику TPC‑DS, но вместо 99 запросов остановилась на одном, который к тому же запускается на одной машине. Обосновывается это тем, что на одном конкретном запросе нужно разобрать работу оптимизаторов. По результатам исследования делается вывод, что решение, разработанное авторами, является лучшим, в том числе для запуска одного конкретного запроса на одном узле. Давайте попробуем разобраться, действительно ли это так.
