Minimax M1 - бесплатная генерация видосов на халяву (пока).

В общем я взял промпты из MovieBench и стал их пихать в свежий агент Minimax M1, о котором сегодня с восторгом писал.

Генерит как миленький. Бесплатно.

Пруф: https://agent.minimax.io/chat?id=281006706552925

Пробуем: https://agent.minimax.io/

@cgevent

#llm #agents

MCP (Model Context Protocol) — это открытый стандарт, упрощающий взаимодействие ИИ-моделей, особенно LLM, с внешними источниками данных, инструментами и сервисами. MCP-сервер выступает мостом между ИИ-моделями и внешними инструментами.

Вот список лучших MCP-серверов:

- File System MCP Server
Позволяет LLM напрямую работать с локальной файловой системой: читать, записывать и создавать директории.

- GitHub MCP Server
Подключает Claude к репозиториям GitHub, позволяя обновлять файлы и искать код.

- Slack MCP Server
MCP-сервер для API Slack, позволяющий Claude взаимодействовать с рабочими пространствами Slack.

- Google Maps MCP Server
MCP-сервер для API Google Maps.

- Docker MCP Server
Интеграция с Docker для управления контейнерами, образами, томами и сетями.

- Brave MCP Server
Веб- и локальный поиск через API поиска Brave.

- PostgreSQL MCP Server
MCP-сервер, позволяющий LLM изучать схемы баз данных и выполнять запросы только для чтения.

- Google Drive MCP Server
MCP-сервер для интеграции с Google Drive, позволяющий читать и искать файлы.

- Redis MCP Server
MCP-сервер, предоставляющий доступ к базам данных Redis.

- Notion MCP Server
Проект, реализующий MCP-сервер для API Notion.

- Stripe MCP Server
MCP-сервер для взаимодействия с API Stripe.

- Perplexity MCP Server
MCP-сервер, подключающийся к API Sonar от Perplexity для поиска в реальном времени.

#database #books

Data Engineering Design Patterns

O’REILLY выпустили свежую книгу с очень многообещающим названием:
"Data Engineering Design Patterns" (Шаблоны проектирования в инженерии данных).

Автор: Bartosz Konieczny - опытный фриланс Data Engineer, энтузиаст Apache Spark, работает со Scala & Python.
Делится знаниями в блоге waitingforcode.com.

В чем суть и почему это важно?

Проекты в области данных - основа технической экосистемы любой компании.
Но сколько раз вы сталкивались с тем, что решаете проблемы, которые уже давно решили другие?

Эта книга - практическое руководство, которое учит поставлять реально ценные данные, фокусируясь на ключевых аспектах:

• Сбор данных
• Качество данных
• Идемпотентность

Главная ценность:
Перестаньте изобретать велосипед!
Узнайте проверенные шаблоны проектирования, которые экономят время, снижают ошибки и повышают эффективность ваших data-проектов.

upd: Книгу еще не читал, но в предисловии отметились известные люди из мира data engineering.

Maxime Beauchemin, original creator of Apache Airflow and Superset

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

Matt Housely, coauthor, Fundamentals of Data Engineering

Инженерия данных страдает от переизбытка сложности из-за постоянного распространения языков, фреймворков и инструментов. Эта книга предоставляет четкие дорожные карты для решения проблем инженерии данных независимо от применяемой базовой технологии.

#database #systemdesign

Snapchat Data Tech Stack

Snapchat - это технологическая компания, которая решает сложные, масштабные задачи в области данных. Сегодня рассмотрим инструменты и технологии, которые Snapchat использует для извлечения данных, преобразования, управления и многого другого.

Масштабы поражают:

• 4+ ТБ данных каждый день в BigQuery
• 1.8 ТРИЛЛИОНА событий в пик
• 200+ ПБ данных в хранилище (30k GCS бакетов!)
• 5 миллиардов Snaps ежедневно
• 3,000 DAGs в Airflow с 330,000 задач ежедневно

На чем все держится?

Платформа:

• Google Cloud Platform (GCP): Вся инфраструктура данных Snapchat построена на GCP.

Как данные попадают в систему?

• Pub/Sub (GCP): Главный "
вход для потоковых событий в реальном времени. Масштабируется мгновенно.

Как данные обрабатываются?

• Apache Beam (через GCP Dataflow): Обработка и потоковых, и пакетных данных.

• Apache Spark (через GCP Dataproc): Основа для генерации фичей в рекомендательных системах.

Как всем этим управляют?

• Apache Airflow: состоянию на 2024 год Snap использует более 3000 DAG,
которые ежедневно выполняют более 330 000 экземпляров задач, охватывающих ETL, отчетность/аналитику, машинное обучение и многое другое.

Где хранятся и анализируются данные?

• BigQuery: Центральное хранилище данных. Куда стекаются все события. Используется для аналитики и ad-hoc запросов.

• Lakehouse (GCS + Apache Iceberg): Наряду с централизованным хранилищем данных Snapchat использует архитектуру lakehouse, объединяя Google Cloud Storage (GCS) с Apache Iceberg. Это позволяет им эффективно получать доступ к большим наборам данных без дублирования в BigQuery.

Благодаря интеграции BigLake данные GCS становятся напрямую доступны в BigQuery, предоставляя пользователям нативный опыт.
Команды машинного обучения являются одними из основных пользователей Lakehouse на своей платформе Bento.

Как визуализируют и принимают решения?

• Looker: Ключевой инструмент для дашбордов и data-driven решений по всей компании. Глубокая интеграция с BigQuery.

Snapchat демонстрирует глубокую интеграцию с GCP для решения экстремальных задач по объему и скорости данных. Комбинация managed-сервисов (Pub/Sub, Dataflow, Dataproc, BigQuery, Dataplex, Looker) и гибких OSS-решений (Airflow, Spark, Beam, Iceberg) позволяет им справляться с невероятными масштабами.

@data_whisperer

#database #systemdesign

The Modern Data Stack Is a Dumpster Fire

Автор поста разносит в пух и прах культ сложности в data-инфраструктуре. В своем посте он рассказывает суроваю правду, которую не покажут вендоры:

Проблема №1: Инструментальный Ад (или Собираем пазл вслепую)

Знакомо? Начинаете не с задачи бизнеса, а с выбора 15 крутых инструментов (Fivetran, Airbyte, dbt, Airflow, Snowflake ).
Перенести CSV-шку превращается в квест через 10 сервисов. На выходе - машина Руба Голдберга для отчетов.
Итог: Красивые презентации, ноль пользы. А фрагментация? Это не баг, ребята, это фича вендорской бизнес-модели!

Проблема №2: Цена Безумия

• Облачные счета выше выручки? Не шутка. Налог на интеграцию – это не только деньги, но и:
◦ Недели на добавление нового источника.
◦ Часы тупой отладки в 5 разных интерфейсах, чтобы поправить одну цифру в дашборде.
◦ Реальная история: $400K и полгода за 3 дашборда. А конкурент на DuckDB + Python сделал это за неделю и выиграл тендер.

Проблема №3: AI-Powered как маркетинговый шум:

Изначально современный стек данных - это уже сложная, перегруженная и дорогая система "помойка на колесах".

◦ Вендоры массово добавляют ИИ-фичи (часто сырые) в свои инструменты, позиционируя это как панацею.
◦ На деле, это часто лишь косметическое улучшение или опасный эксперимент над пользователями.
◦ ИИ добавляется в уже перегруженные и сложные системы, делая их еще более "черными ящиками".

Миф: Вам Нужны Big Data и Сложный Стек

• 90% компаний работают со средними данными (medium data). Ваш ноутбук-2025 мощнее дата-центра 2012 года
• Маркетинг вендоров раздул Big Data" Но вы – не Netflix. Зачем вам Spark/Snowflake для 80 млн строк?
• Эластичность облака = Мы возьмем с вас больше. И мы это сделаем.

Какое решение предлагает автор?

Ключ не в масштабе, а в снижении сложности. Будущее за:
• DuckDB, Polars, SQLite: Обрабатывают гигабайты/сотни млн строк на одном ноутбуке быстрее и в 10-100 раз дешевле облака (реальные кейсы Watershed, FinQore, Mode).

Принципы:
1. Стройте ТОЛЬКО то, чем можете владеть (объясните стек новичку за час).
2. Усложняйте ТОЛЬКО когда реальность требует.
3. Принимайте локальные/встроенные решения.
4. Мигрируйте постепенно.
5. Безжалостно упрощайте

Вывод:
Современный стек данных для многих - это путь в ад затрат, стресса и бесконечной настройки.
Команды, которые выбрали простые, понятные, локальные инструменты (small data done right), просто побеждают.
Их стек просто работает. Они решают задачи бизнеса, а не обслуживают инфраструктурного Франкенштейна.

"Лучший стек данных – тот, о котором вам не приходится думать."

@data_whisperer

#dl #llm

#dl #nlp #llm #books

#llm #papers

Zero-shot vs Few-shot. Пишем промпты эффективно

➡ Few-shot prompting
Здесь мы представляем модели примеры с инструкцией, как ей следует себя вести. После этого надеемся, что модель нас поймет, т.е. выучит in-context learning и выполнит запрос

Пример

Запрос:
Красный - один
Оранжевый - два
Желтый - три
Зеленый - четыре
Голубой - пять
Синий - шесть
Фиолетовый -

Ответ:
семь

➡ Zero-shot prompting
Это противоположность Few-shot. Здесь мы напрямую запрашиваем ответ у модели без дополнительных инструкций и надеемся, что ее достаточно хорошо обучили, чтобы она поняла, что мы от нее хотим.

Пример

Запрос:
Определи характер отзыва (позитивный, негативный или нейтральный).
Отзыв: Фильм в целом неплох.

Ответ:
Нейтральный

➡ Какие ограничения ?
Zero-Shot prompting неплохо себя показывают на каких-то простых задачах, основанных на общих знаниях. Few-shot уже может решать более сложные задачи и может помочь когда полноценный fine-tuning невозможен. Или когда нужно выучить несложные концепции. Еще Few-shot может повысить точность ответа.

Но и Few-shot - это не панацея. Он все еще неспособен решать достаточно сложные задачи на рассуждение. Если задача требует нескольких шагов рассуждения, даже набора примеров может оказаться недостаточно, чтобы LLM смогла найти нужную закономерность. Здесь обращаемся к Chain of Thoughts.

Иногда можно увидеть термины One-shot, Two-shot Prompting и т.д. Это просто частные случаи Few-shot prompting и они указывают на количество подаваемых в модель примеров.

#gan #petproject

Камрад Aleks напомнил вот про этот отличный репозиторий - https://github.com/gseth/ControlAltAI-Nodes
Я тоже его очень рекомендую. Так много достойных и интересных нод.

#Comfy #novice

#llm #petproject