HelixDB - это высокопроизводительная графо-векторная база данных с открытым исходным кодом, написанная на Rust, разработанная для приложений RAG и ИИ. Она объединяет хранение графовых и векторных данных, используя LMDB для обеспечения персистентности данных и соответствия ACID.

Код на GitHub

#llm #code

Вышла свежая лекция Andrej Karpathy про Software in the Era of AI

Там много всего интересного - за 40 минут он понятно и образно описывает текущее состояние AI, систем для кодинга и того, куда все это катится. Очень рекомендую к просмотру.

(Это его выступление для той самой школы AI стартапов в Сан-Франциско)

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

"когда я вайб-кожу, то все пучком. Но вот если мне нужно что-то сделать на самом деле..."

("If I'm vibe-coding, it is all nice and great, but if I'm actually trying to get the work done, it's no so great to have an overractive agent doing all this kind of stuff").

В общем, как мы уже обсуждали раньше, вайб-кодинг - вещь прикольная для прототипчиков. Но если нам не играться надо, а работу делать и серьезные проекты пилить, то AI+Coding агентов уже нужно держать на коротком поводке. А для этого - работаем с планами, выдаем им системы для верификации, даем инструкции для использования всего этого.

Cоветую посмотреть: https://www.youtube.com/watch?v=LCEmiRjPEtQ

Ваш, @llm_under_hood 🤗

#llm #ml #systemdesign

Продолжаем серию публикаций по LLM System Design. Сегодня говорим про важность внешних инструментов.

Паттерн 3. Дайте LLM правильные инструменты

Самый частый паттерн применения LLM — модель переводит запросы с человеческого языка в вызов нужных инструментов. Вы просите узнать баланс на карте, LLM отправляет запрос в нужный сервис, указывая идентификатор карты в параметрах. Вы говорите, что хотите найти в данных, LLM пишет SQL-запрос к правильной таблице.

Очень важно: любую детермированную логику выполнять кодом, а не LLM. Если нужно понять, можно ли дать этому клиенту скидку, пускай это решит детерминированный алгоритм, а LLM его правильно вызовет. Если нужно отсортировать документы по релевантности, пускай LLM выдаст релевантность, а отсортируете вы результат кодом. Более подробно про это читайте тут.

В дизайне системы очень удобно считать tool-ом любой другой элемент: внешний код, база данных (RAG), другие LLM и т.д. Вызов инструментов требует правильного заполнения всех аргументов, поэтому крайне удачно, что мы прошли Structured Output в Втором паттерне. Не забывайте его использовать.

Код — ваш лучший инструмент

Код это самый мощный tool, который вы только можете дать LLM (но риски кратно возрастают). LLM может персонально под задачу генерировать программу.

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

Код может быть не только tool-ом, но и управлять работой агента с другими tool-ами.
Вместо того, чтобы писать логику вызова tool-ов текстом, можно ее всю завернуть в программный код. Почему это удобно отлично написано тут.

На этой идеи построена библиотека smalagents от HuggingFace. Технические подробности в статье CodeAct.

Как научить LLM использовать инструменты

От самого простого к самому сложному:

1) Подключиться к MCP-серверу, если такой есть, и взять оттуда этот tool.

2) Самим сделать tool на базе каких-то API (не забываем про разницу MCP и API), напихать все в промпт

3) Самим сделать tool, зафайнтюнить LLM правильно этот tool использовать. Про это есть классическая статья.


Обязательная литература

- Объяснение, почему важно разделять LLM и tools

- Аналогичное правило, но для ИИ агентов

- Пост, чем дизайн tool для LLM отличается от просто API

- Статья, как важно Structured Output для tools

Любые вопросы обязательно пишите в комментарии.

Если нужно обсудить конкретно ваш случай - пишите вопрос в личные сообщения.

#llm_system_design

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