Fundamentals of Data Engineering. Глава №3. Designing Good Data Architecture. Принципы

🔵 Entrerpise и Data архитектуры

Enterprise architecture включает в себя проектирование гибких систем для поддержки изменений предприятия посредством тщательной оценки трейдоффов. Она включает в себя подмножество архитектур: бизнес-архитектура архитектура техническая, архитектура приложения и архитектура данных.

Data architecture - проектирование систем для поддержки меняющихся потребностей предприятия в данных. Включает:
- Operational architecture (относится к людям, процессам и технологиям, помогает найти ответ на вопрос "Что?")
- Technical architecture (подробно описывает прием, хранение, преобразование и обслуживание данных на протяжении всего жизненного цикла проектирования данных, помогает найти ответ на вопрос "Как?").

🔵 Принципы из которых складывается хорошая архитектура данных:

1️⃣ Выбирайте общие компоненты с умом.
Что можно отнести к общим компонентам в DE:
- хранилище объектов
- система контроля версий
- система наблюдения и мониторинга
- оркестрация
- механизмы обработки.

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

2️⃣ Планируйте неудачу
Чтобы построить надежные системы данных, учитывайте вероятность нештатных ситуаций. Ключевые термины для оценки сценариев сбоев включают:

- Availability: процент времени, в течение которого ИТ-услуга или компонент работоспособны.
- Reliability: вероятность соответствия определенным стандартам при выполнении предполагаемой функции в течение определенного интервала времени.
- Recovery time objective: максимально допустимое время простоя службы или системы.
- Recovery point objective: приемлемое состояние после восстановления, определяющее максимально допустимую потерю данных в системах данных.

3️⃣ Проектируя закладывай масштабируемость
Идеальная эластичная система должна автоматически масштабироваться в ответ на нагрузку. Однако неправильные стратегии масштабирования могут привести к усложнению систем и увеличению расходов.

4️⃣ Архитектурная функция это лидерство
Менторство и коучинг разработчиков, участие в решении сложных проблем является важнейшим аспектом работы архитектора. Повышая навыки команды, архитекторы могут получить больше рычагов, чем принимая все решения самостоятельно и становясь узким местом.

5️⃣Всегда рефлексируй по поводу архитектуры
Все настолько быстро меняется (технологии, инструменты и бизнес модели) и для того чтобы своевременно реагировать на эти изменения важно целиться не в что-то идеальное а скорее проектировать так чтобы была возможность изменять. Гибкость в нашем agile мире важнее всего.

6️⃣ Создавайте слабосвязанные системы
Слабосвязанная система обладает следующими свойствами:
- Небольшие компоненты.
- Взаимодействие посредством абстракций а не реализаций.
- Изменения в одном компоненте не влияют на другие.
- Каждый компонент обновляется отдельно.

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

8️⃣ Безопасность
- Используйте модели безопасности с нулевым доверием.
- Выстройте модель совместной ответственности при вычислениях в облаке.
- Поощряйте инженеров по обработке данных выступать в роли инженеров по безопасности.

9️⃣FinOps
FinOps - дисциплина финансового управления и культурная практика в облаке, способствующая сотрудничеству между инженерными, финансовыми и бизнес специалистами для принятия решений о расходах на основе данных, с целью достичь максимального соотношения доходов к расходам.

———

На этом всё, в следующем посте рассмотрим архитектурные показатели.😊

🔍 Топ-5 библиотек для объяснения ML моделей

🟢 SHAP (Shapley Additive Explanations)
Один из самых популярных методов объяснения модели на основе вкладов признаков.

🟢 LIME (Local Interpretable Model-agnostic Explanations)
Модель-агностичный подход, который обучает локальную интерпретируемую модель вокруг конкретного предсказания.

🟢 Eli5 (Explain Like I’m Five)
Упрощённое объяснение сложных ML-моделей, поддержка scikit-learn, Keras и других фреймворков.

🟢 AI Explainability 360 (AIX360)
Библиотека от IBM для объяснения моделей на различных типах данных: табличных, текстовых, изображениях и временных рядах.

🟢 InterpretML
Инструмент от Microsoft, который включает как интерпретируемые «прозрачные» модели, так и объяснители для «чёрных ящиков».

#dl #llm

Привет, друзья!

Как-то был запрос на методы объяснения для мультимодальных моделей (MM). Мой внутренний перфекционист не дал мне это сделать быстро, но жизнь подсунула обзорную статью с приятными картинками, которая сделала это просто прекрасно.

Смотреть: главы 4, 5.

✔️ Глава 4 касается методов, которые работают для LLM и могут быть обобщены для MM моделей. Краткий пересказ:

1. Описано Linear Probing (Линейное зондирование) — о котором я писала здесь.

Что делаем — извлекаем скрытые представления из модели и обучаем линейный классификатор.

2. Описан метод Logit Lens — метод, анализирующий, как выходные вероятности модели (логиты) изменяются на разных слоях.

Что делаем — на каждом слое скрытые представления проецируем в выходное пространство с помощью финального слоя модели.

3. Дальше Causal Tracing. Метод, подразумевающий внесение изменений в состояния сети, и анализа, как это повлияет на выход модели.

4. Потом Representation Decomposition — метод разбиения скрытых представлений модели на более понятные части. Очень схож с третьим и может задействовать зондирование, как инструмент анализа.

5. Предпоследнее — применение Sparse AutoEncoder — здесь мы при помощи автокодировщика, обучаемого на скрытых представлениях, вытаскиваем наиболее значимые фичи в «узкий слой» автоэнкодера.

6. Ну и классический Neuron-level Analysis — метод, изучающий индивидуальные нейроны в сети и их вклад в предсказания модели., при помощи анализа активаций отдельных нейронов при разных входных данных.

✔️ Теперь глава 5. Про методы, специфичные для мультимодальных моделей. Тут описано 5 штук:

1. Text-Explanations of Internal Embeddings — дословно, метод, назначающий текстовые описания внутренним представлениям модели.

2. Network Dissection — метод, выявляющий нейроны, отвечающие за конкретные концепции. Офигенный метод (paper), красивый метод (визуализация), но очень плохо адаптирован для трансформеров.

3. Cross-attention Based Interpretability — анализ того, какие части текста и изображения наиболее связаны через кросс-аттеншены.

4. Training Data Attribution — методы, определяющие, какие обучающие примеры сильнее всего влияют на конкретные предсказания модели. Что делаем — сознательно и не очень меняем и подаем обучающие примеры.

5. В завершение классика — Feature Visualizations — методы, позволяющие визуализировать, какие части входных данных наиболее важны для модели. Как правило — градиетные методы.

✔️Вместо вывода:
За счет размера моделей, методы интерпретации мультимодальных моделей заимствуют подходы из LLM. Однако, они требуют доработок из-за сложности взаимодействий между модальностями. С одной стороны можно действовать грубо и просить на каждое внутреннее представление делать объяснение. Но это вычислительно не приятно и скорее относится к конструированию объяснимой модели, а не объяснению имеющейся.

Лично мне очень весь этот мультимодальный челлендж нравится. Думаю, как практически его потыкать (обязательно поделюсь результатом).

Чудесного воскресенья, друзья!

Сейчас в догонку кину картинки.
Ваш Дата-автор!

#llm #prompt

#database #books #systemdesign

Fundamentals of Data Engineering. Глава №3. Designing Good Data Architecture. Архитектурные показатели и паттерны.

Начнем с показателей:

1️⃣ Эластичность (Elasticity)
- способность системы динамически масштабироваться в зависимости от рабочей нагрузки. Она включает в себя масштабирование вверх и вниз, с возможностью масштабирования вниз до нуля.

2️⃣ Доступность (Availability)
- процент времени, в течение которого ИТ-услуга или компонент находится в рабочем состоянии.

4️⃣ Надежность (Reliability):
- вероятность того, что система будет соответствовать определенным стандартам при выполнении своей предполагаемой функции в течение определенного интервала времени.

5️⃣ Масштабируемость (Scalability)
- способность улучшать производительность системы и справляться с требованиями за счет увеличения емкости. Это может включать масштабирование системы для обработки большого количества запросов или обработки большого набора данных.

🔵 Основные средства достижения показателей

Vertical scaling - масштабирование за счет увеличивает количества ресурсов без изменения количества узлов в системе. Имеет ограничения (физические).

Horizontal scaling - масштабирование за счет добавления большего количества узлов в систему для удовлетворения требований к нагрузке и ресурсам.

Для того чтобы минимизировать ущерб от сбоев и поддерживать высокие показатели надежности системе трeбуется избыточность (Redundancy). Главный пример избыточности - реплики данных в кластере], благодаря им система может вернуться в стабильное состояние очень быстро, благодаря тому что сосед возьмёт на себя обязанности умершего узла.

🔵 Архитектурные приемы и паттерны
Tightly coupled - подразумевает процессы, где сервисы зависят друг от друга.

Loosely coupled - децентрализованные сервисы, не имеющие строгой зависимости друг от друга. Чтобы реализовать этот шаблон, назначьте общие стандарты, правила владения ресурсами и ответственные за сервисы команды.

Cohesion и Coupling: отличия

———

Monolith - подразумевает что все возможные компоненты расположены вместе. Самый распространенный пример - единый репозиторий в котором есть логика UI / Backend, База данных итп.

Microservices - отдельные слабо связанные сервисы, каждый выполняет определенную функцию. В этой архитектуре, если сервис временно выходит из строя, это не влияет на способность остальных продолжать работать.

Кстати, ранее уже обозревал и делился личным мнением по поводу этих стилей:
🔹Монолитная архитектура
🔹Прагматичный взгляд на Микросервисную архитектуру.

Аргумент

Напомню сценарий событий:

Ситуация: пришёл босс и просит меня взять в работу его идею, обходя существующие процессы.

Моя цель (то, что я держу в голове на протяжении всего разговора): не брать задачи в бэклог, если они обходят установленные процессы. Даже если задача идёт от босса.

Проблема (то, что я озвучиваю на встрече): «Мы не можем взять эту задачу прямо сейчас».

Тезис: «Мы оценим эту задачу так же, как остальные новые задачи, и после 2 апреля вернусь к тебе с более точным ответом».

Далее идёт аргумент

___

Аргумент — высказывание, которое доказывает или опровергает тезис.

У нас есть процесс, по которому задачи попадают к нам в бэклог: объясняю, из чего состоит процесс, когда я планирую оценить задачу босса и вернуться с деталями.

Три признака рабочего аргумента:
1. Подходит под тему дискуссии
2. На языке выгод для второй стороны
3. Достаточный

___

№1. Аргумент подходит под тему дискуссии

Это когда аргумент связан с тезисом (основной идеей, которую хочу донести).

Убеждающая сила аргумента падает, если аргумент относится к тезису частично.

Если аргумент не связан с тезисом, то не имеет значения, насколько он понятен, правдоподобен и достаточен.

Например

Тезис: «Мы оценим эту задачу так же, как остальные новые задачи, и после 2 апреля вернусь к тебе с более точным ответом».

✔︎ Аргумент, который соответствует тезису:
«Чтобы стабильно добиваться поставленных KPI, мы строго придерживаемся процесса оценки всех новых задач. Это также позволяет нам расставлять приоритеты осознанно, учитывать загрузку, риски и взаимосвязи между задачами. В итоге мы релизим фичи быстрее и качественнее».

✘ Аргумент, который не соответствует тезису:
«Я понимаю, что эта задача важна, но если мы начнём брать задачи в обход процесса, то можем пропустить критически важные детали. В прошлый раз, когда мы взяли задачу без оценки, нам пришлось потом в спешке всё переделывать. А ведь нам важно делать качественный продукт, верно?»

___

Продолжение про аргументацию

⚠ Теперь в постах будут появляться «Советы с тёмной стороны» — мои размышления о том, как описанный инструмент можно использовать во вред собеседнику.


Советы с тёмной стороны аргументации

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

Этот приём называется «подмена тезиса» или «логическая ошибка красной селёдки».

Красная селёдка

“Ты же знаешь, что я всегда беру в работу самые важные задачи! Помнишь, как мы с тобой в прошлом году оперативно решили проблему с [какой-то другой задачей]? Я всегда держу в приоритете критически важные вещи”.

Что тут не так? Здесь мы переключаем внимание на свою лояльность и прошлые успехи, уводя обсуждение в сторону. Я чаще всего сталкиваюсь именно с этим тёмным приёмом. Горит с этого ужасно.

.

Для общения с эмоциональными коллегами или если вам плохо и вы хотите поделиться своей болью, то эмоциональный довод поможет.

Эмоциональный довод

“Послушай, я понимаю, насколько это важно для тебя. Я вижу, сколько ты вкладываешь в этот проект, сколько сил и энергии ты отдаёшь. Ты всегда ставишь интересы компании на первое место, и мне действительно не хочется тебя подводить. Но если мы нарушим процесс сейчас, мы можем создать хаос, и в итоге твоя идея не получит того внимания и качества, которого заслуживает. Разве ты этого хочешь?”

Что тут не так? Вместо логического ответа идёт упор на эмоции босса: признание его усилий, скрытая манипуляция чувством ответственности и страхом провала.

.

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

Эффект Барнума (или обобщённое утверждение)

«Ты же человек, который всегда думает наперёд, стратег. Ты понимаешь, что правильные решения требуют системного подхода, а не хаотичных действий. В конце концов, ты же сам не раз говорил, что важно соблюдать баланс между скоростью и качеством. Вот поэтому нам нужно следовать процессу, а не бросаться с места в карьер».

Что тут не так? Использование приятных обобщённых утверждений, которые кажутся персонализированными, но подходят почти всем: “Ты стратег, ты думаешь наперёд.” Далее говорим, что если он хочет сохранить этот статус, то надо соглашаться: «Ты понимаешь, что правильные решения требуют системного подхода, а не хаотичных действий…» — это будет выглядеть как признание его разумности и дальновидности.

.

💡Как бороться с такими манипуляциями?

Если со мной проворачивают подобные приколы, мне помогает:
1. Проговаривание слов собеседника
2. Проговаривание своими словами всей логической последовательности, как если бы я пересказывал наш диалог кому-то, кто совсем не «в теме».

Вслух или про себя. В этот момент в голове что-то щёлкает, и я начинаю замечать нестыковки в аргументации.

Но не всегда.

Если бы от всех манипуляций можно было защититься так просто, то их бы не использовали.

___

Нашли что-то полезное для себя?

Как вам тема «тёмной стороны»? Интересно ли читать про такие приёмы?

#llm #rl

Самые популярные архитектуры в Enterprise RAG Challenge

Вот вам краткая выжимка того, что люди использовали во время Enterprise RAG Challenge round 2. Она сделана на основе анализа 55 описаний архитектур, которые заполнили команды.

🤗 Спасибо всем, кто участвовал и заполнял! 🤗

Key Takeaways

- RAG is near-universal. Almost every approach tries to solve the “long PDF → targeted answer” problem by chunking, storing embeddings, retrieving relevant sections, then letting the model “read” only those sections.
- Structured prompts (with JSON/Pydantic) were popular to ensure consistent outputs—particularly for numeric or Boolean questions that required a definite format.
- Chain-of-thought or multi-step reasoning is common, sometimes with multiple LLM calls for expansions, validations, or final re-checks.
- Performance + Cost trade-offs surfaced: several teams used “fast & cheap” LLMs for search or chunk-labelling, then a heavier model (e.g., GPT-4o) for final answers.

Most submissions combined:
- Document parsing (Docling, PyMuPDF, or similar),
- Vector or keyword-based retrieval (FAISS, Qdrant, BM25, etc.),
- Iterative LLM-based reasoning (chain-of-thought or agent-like flows),
- Structured response schemas (Pydantic or JSON).

Despite the variety of LLM families (OpenAI GPT-4o variants, Llama, Gemini, Qwen, DeepSeek, IBM Granite, Microsoft phi, etc.), the underlying RAG pipeline structure remained strikingly consistent: parse PDFs, embed or index them, fetch relevant chunks, and prompt an LLM to produce carefully formatted answers.

А то, насколько хорошо все эти архитектуры показали себя в рамках соревнования - мы узнаем уже в эту пятницу.

Ваш, @llm_under_hood 🤗

The 37signals Guide to Internal Communication

Мы уже писали про замечательную книгу Getting Real от ребят из 37signals.

Давно хотел написать про ещё один классный гайдлайн от ребят — The 37signals Guide to Internal Communication.

Мы внедряем различные практики разработки — как пишем код, какие линтеры используем, как проводим ревью и т.д. А вот как правильно коммуницировать, чтобы были единые, всем понятные правила? На моей практике с этим аспектом не всё так гладко.

В гайде вас ждёт набор очень ёмко сформулированных правил коммуникации. Приведу без перевода особенно откликнувшиеся мне:
— Real-time sometimes, asynchronous most of the time.
— Meetings are the last resort, not the first option.
— Speaking only helps who’s in the room, writing helps everyone.
— If your words can be perceived in different ways, they’ll be understood in the way which does the most harm.
— Never expect or require someone to get back to you immediately unless it’s a true emergency. The expectation of immediate response is toxic.
— Five people in a room for an hour isn’t a one hour meeting, it’s a five hour meeting. Be mindful of the tradeoffs.
— “Now” is often the wrong time to say what just popped into your head. It’s better to let it filter it through the sieve of time. What’s left is the part worth saying.
— Urgency is overrated, ASAP is poison.
— Ask if things are clear. Ask what you left out. Ask if there was anything someone was expecting that you didn’t cover. Address the gaps before they widen with time.

#teamwork #edu

#dl #code