После первой настройки Telegram Business Bot в OpenClaw обычно все радуются базовому сценарию: вечерний саммари по личным диалогам.
Работает, удобно, но быстро появляется следующий вопрос:
А что, если нужен не только отчёт за вчера, а анализ переписок за месяц или год?
Ниже покажу, как я это у себя собрал: Telegram Business Bot + OpenClaw + memU + локальная векторная база.
Эта статья - не попытка критиковать конкретный банк и не утверждение, что алгоритм ошибся. Я не знаю внутренних правил скоринга, не видел модели и не утверждаю, что решение было неверным.
Это разбор частного случая глазами человека, который внезапно оказался в очень неприятной жизненной ситуации в связи с тем, что в ответственный момент классификатор «принял решение» об отказе в ипотеке. В данный момент ситуация продолжает оставаться неясной и я нахожусь в стрессе. В какой-то степени, попытка хоть как-то разобраться в том, какие факторы повлияли на отказ в выдаче ипотеки, хоть как-то снижает уровень стресса.
Привет, Хабр! Меня зовут Александр, я DevRel команды Selena Lakehouse. Пишу про СУБД StarRocks, архитектуры Lakehouse и Streamhouse в Telegram-канале @starrocks_selena (https://t.me/starrocks_selena).
Полгода назад термин Streamhouse начал всплывать на конференциях и в блогах. При этом многие русскоязычные источники, которые я читал, сводят его к «замене Iceberg на Paimon и обновлению Flink» или путают с обычным Lakehouse. На самом деле за Streamhouse стоит интересная архитектурная логика. Конкретный набор компонентов, где каждый решает свою задачу: Apache Flink для вычислений, Apache Fluss как горячий потоковый слой, Apache Paimon как холодное хранилище. Вместе они дают потоковый Lakehouse с задержкой в секунды вместо минут.
Мне стало интересно: можно ли на этом стеке построить полноценный аналитический конвейер? Не на слайдах, а руками в Docker Compose, с SQL и реальным сценарием.
В этой статье:
Об опыте прохождения курса от Яндекс "Инженер данных с нуля", что подвинуло, как учился, какие претензии, стоит ли он своих денег. В общем - мысли в слух!
Сколько раз вы пытались открыть в Excel файл на пару миллионов строк и смотрели на зависший белый экран под звук взлетающего кулера? А сколько раз писали трехэтажные циклы for в чистом Python, чтобы просто сгруппировать данные и посчитать среднее?
Pandas — это Excel на максималках и швейцарский нож любого разработчика и аналитика. В этой статье я собрал абсолютную выжимку: 10 главных шагов для работы с таблицами. Разберем вечную путаницу между loc и iloc, правильную очистку от пропусков, группировки и джойны (merge).
Data Mesh, Data Fabric, Lakehouse: разбираем модные термины
Data Mesh, Fabric, Lakehouse – все говорят, но никто толком не объясняет, чем они отличаются и можно ли их использовать вместе. Разобралась и делюсь структурированно и без воды.
➕ Сравнительная таблица и чек-лист: что выбрать под свою боль.
✔️Сохраняйте, чтобы больше никогда не путаться.
Привет! Меня зовут Саша Михеев, и я работаю в Авито над развитием персонализации пользователей. Делаю так, чтобы покупатели видели объявления, которые могут их заинтересовать. В статье рассказываю, как мы внедряли «трансформеры», чтобы улучшить рекомендации для пользователей.
Статья будет полезна data scientist-ам, ML-инженерам, ML-Ops-специалистам и продакт-менеджерам.
Реальные кейсы показывают, что внедрение агентного ИИ — это не только технический, но и организационный вызов. Ниже мы рассмотрим лучшие практики и типичные ошибки, которые совершали компании на ранних этапах, а также то, как их избежать.
Складывается впечатление, что агентный ИИ уже вышел за рамки фантастических обещаний и вступил в фазу прагматичной апробации. Так ли это? В статье эксперт онлайн-магистратур Центра «Пуск» МФТИ Денис Прилепский отвечает на этот вопрос и рассказывает, как эволюционировал агентный ИИ и как сегодня технологию внедряют в работу компаний.
LLM научилась запоминать беседу, не подгядывая в контекст. Архитектуры типа Titans и обещают превращение цикла вывода в цикл онлайн-оптимизации
Приветствуем вас, Хабр.
В течение минувшего года мы серьёзно прорабатывали тему инженерии данных (Data Engineering), поскольку остались очень довольны читательским интересом к вышедшей у нас книге «Основы инженерии данных: как создавать надёжные системы обработки данных» Джо Риса и Мэтта Хоусли (оригинал — издательство "O'Reilly"). В январе вышла её допечатка.
Кроме того, у нас уже переведена и ушла в редактуру более продвинутая книга, также от O'Reilly, написал которую Бартош Конечны (Bartosz Konieczny); она называется «Data Engineering Design Patterns: Recipes for Solving the Most Common Data Engineering Problems».
Лет десять назад объектное хранилище было экзотикой. Крупные компании обходились NFS‑шарами и надеждой, что RAID не развалится в самый неподходящий момент. Средний бизнес в целом не понимал, зачем это нужно. Но сегодня все изменилось. S3 API стал таким же стандартом, как REST или JSON. Мы в Диасофте построили «Фабрику данных» (Digital Q.DataFactory) в архитектуре Data Lakehouse на основе S3 Архипелаг, которая объединяет гибкость Data Lake с надежностью хранилища данных. В этой статье расскажем, как построили слой хранения.
Здравствуйте, уважаемые читатели Хабра!
В этой публикации рассмотрим применение тематического моделирования для анализа имеющихся данных и визуализации семантических связей между таблицами.
Data governance, data mesh, modern data stack, data lineage – столько разных data, столько разных популярных подходов и инструментов. Лидером по популярности (на мой скромный взгляд) среди всех них является data catalog. Многие говорят о нем, многие хотят его, многие уже внедрили. Но внедрить это одно дело, а вот получить от него пользу – дело совсем другое.
Мы сформировали список самых частых проблем, основанные не только на нашем опыте, но и на опыте наших коллег, проанализировав множество статей и материалов на эту тему.
Наверняка каждый, кто начинает погружаться в анализ данных, сталкивался с этой классической проблемой. Вы скачиваете гигантский CSV-файл, по привычке пишете pd.read_csv(), запускаете ячейку и... кулеры начинают выть, система жутко тормозит, а в итоге скрипт падает с ошибкой нехватки памяти.
Первая мысль в такой ситуации — нужен компьютер помощнее или облачный сервер. На самом деле, чтобы переваривать огромные файлы, вовсе не обязательно наращивать оперативку. Проблема кроется в том, что по умолчанию мы пытаемся запихнуть весь объем данных в память целиком.
Существует довольно много простых техник, которые позволяют обойти это ограничение. Ниже мы разберем несколько таких приемов, которые спасают, когда ваши данные переросли возможности вашего железа. Пойдем от самых базовых к чуть более продвинутым.
Если мы говорим про AI, говорим и про галлюцинации. Эти два понятия, к сожалению, стали неразрывны. И главная задача в 2026 не просто внедрить AI, чтобы потом всем рассказывать о своих успехах и как затраты сократились на 900%. Главная задача – сделать так, чтобы AI не врал. А врать он любит. Он буквально патологический врун! Но его можно понять, ведь наш друг боится показаться несведущим. И если он чего-то не знает о чем его спрашивают, он с высокой долей вероятности начинает привирать.
Давайте разберемся, как сделать так, чтобы AI не врал. И кратко рассмотрим аж 9 способов, а точнее 9 видов архитектур RAG.
Привет, Хабр! Меня зовут Александр Воробьев. За моими плечами разработка более 100 электронных устройств, пуско-наладка АСУ ТП и множество проектов, где нужно было "прикрутить" датчик к микроконтроллеру, написать веб-интерфейс и заставить это всё работать вместе. Каждый раз — это горы кода, даташитов и времени. В какой-то момент я задался вопросом: а можно ли автоматизировать этот процесс? Чтобы инженер думал над архитектурой, а не над синтаксисом? В этом посте я поделюсь своим путем создания инструмента, который позволяет собирать сложные IoT-системы за минуты с помощью AI-агента, и покажу это на реальных кейсах.
Сразу успокоим читателя: AI не вытеснил data-инженера из рабочего процесса. Наоборот, он сделал эту роль еще более значимой. И в этой статье объясняется, что именно это означает для вас и вашей профессии. Не с точки зрения технологий и инструментов, а с точки зрения изменения зоны ответственности.
AI, как и везде, конечно классно справляется с некоторыми задачами, но всю ответственность по-прежнему несет человек. Весь контекст не передашь через промпт, и AI не делает компромиссных решений. Большинство систем не выходят из строя, потому что было сложно написать код. Выходят потому что решения по разработке были приняты поспешно, и без четкого понимания, кто и как этими системами будет пользоваться. И AI еще быстрее за нас принимает решения, но все те же риски «непонимания контекста» остаются.
В статье рассказываем, зачем при сбоях в DWH нужен полноценный план аварийного восстановления, чем он отличается от резервного копирования данных и как выглядит на практике - на примере проекта для крупного ритейлера.
Загружал пару лет переписки из Telegram в Apache Doris на ноутбуке. Первый запуск 2 часа. После оптимизации 206 400 сообщений за 5 секунд.
Полез в исходники разобраться, почему Stream Load (HTTP-загрузка данных) в Doris работает так быстро. В статье разбор C++ кода: от HTTP PUT до Segment-файла на диске.
Что внутри:
— 14 шагов одного HTTP-запроса (с диаграммой и кодом)
— StreamLoadPipe: буфер 4 MB с backpressure
— Иерархия записи: LoadChannel → DeltaWriter → MemTable → async flush
— 6 практических выводов: что крутить, что мерить, где смотреть compaction score
