Опубликовано 21.10.2023. Изменено 06.11.2023.

Оригинал: https://unixdigest.com/articles/we-have-used-too-many-levels-of-abstractions-and-now-the-future-looks-bleak.html

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

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

Слишком мало и слишком много всё портит.

Какая польза от абстракции, когда она ломается и никто больше не понимает, как работает технология “под капотом”?

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

Сегодня программистов и системных администраторов больше не существует, вместо них у нас есть DevOps и даже DevSecOps, в которых индустрия очень старательно пытается втиснуть каждую отдельную задачу в должностную инструкцию одного человека. Специалисты по технологиям должны выполнять разработку (Dev), безопасность (Sec) и операции (Ops), то есть системное администрирование, но поскольку ни один человек не может по-настоящему освоить все это, нам нужно автоматизировать как можно больше, чтобы сэкономить деньги и избежать сложностей человеческого социального взаимодействия между различными техническими отделами. В результате современному специалисту по технологиям enseñan только тому, как использовать конкретные инструменты, и он или она очень мало знает о технологии “под капотом”.

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

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

Да, давайте все вернемся к кодированию на ассемблере!

— Саркастический комментарий высокомерного разработчика

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

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

— Кен Томпсон

Уже сейчас большинство “специалистов по безопасности” очень мало знают о безопасности и только о том, как использовать какой-то готовый инструмент для тестирования на проникновение. Инструмент для тестирования на проникновение показывает кучу зеленых лампочек на своей веб-панели, и все считается в порядке. Тем не менее, настоящий эксперт по безопасности со злыми намерениями давно взломал систему и продолжает продавать ценные данные в даркнете. Ничего не утекло и ничего не обнаружено. Это может продолжаться годами, никто ничего не узнает, потому что, ну, на панели GUI написано, что все в порядке.

Некоторые студенты сегодня, по-видимому, даже не знают, что такое файлы и папки.

Советы изучающим технологии:

1. Никогда не следуйте за хайпом или трендами.
2. Будьте любопытны. Не просто изучайте инструменты, старайтесь понять, как работает базовая технология.
3. Если возможно, попробуйте хотя бы один раз вручную сделать то, что, например, делает для вас инструмент конфигурации.
4. Если возможно, попробуйте посмотреть код инструмента. Даже базовое понимание кода может быть очень ценным.
5. Сохраняйте любопытство. Продолжайте учиться. Экспериментируйте. Погружайтесь глубже в интересующие вас технологии. Если возможно, создайте домашнюю лабораторию и используйте ее как игровую площадку для обучения и слома вещей.
6. Ставьте под сомнение все. Особенно то, что вам кажется бессмысленным. Не думайте, что кто-то знает лучше — так вы быстро превратитесь в слепого последователя. Иногда кто-то действительно знает лучше, но не делайте такого вывода по умолчанию. И будьте смелыми! Стойте на стороне правды и своих убеждений, даже если это заставляет вас чувствовать себя одиноким.

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

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

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

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

Примерно полгода назад я наткнулся на несколько фронтенд-веб-разработчиков, которые не знали, что веб-сайт можно создать без инструмента развертывания и что JavaScript вообще не нужен, даже если веб-сайт принимает платежи. Я спросил об этом своего друга, который в то время преподавал программирование на Python, и он сказал:

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

Я знаю, что всегда найдутся люди, которые будут интересоваться более глубокими уровнями, дело не в этом. Дело в том, что именно в разработке программного обеспечения мы давно достигли точки, когда добавили слишком много слоев абстракции, и слишком мало людей понимают, что они делают. Индустрия стреляет себе в ногу.

Если, например, я веб-разработчик, будь то фронтенд или бэкенд, или занимаюсь так называемой “интеграционной работой” и создаю веб-сайты без особого кодирования или каких-либо знаний о TCP/IP, DNS, HTTP, TLS, безопасности и т. д., используя только готовые инструменты или фреймворки, то это сделает меня примерно таким же полезным, как обезьяна с динамометрическим ключом, когда что-то пойдет не так.

Сравнение самых популярных BI-as-code инструментов: Evidence, Streamlit, Dash, Observable, Shiny и Quarto
Кейси Хуанси Ли – Приглашенный Автор 30 октября 2024 г. · 4 мин чтения
Кейси – специалист по данным, инженер-программист и писатель. Ранее она работала в McKinsey & QuantumBlack, а в настоящее время работает в Shopify.

Оригинал тут: https://evidence.dev/blog/business-intelligence-tools

а можно не читать, а идти сразу сюда: https://gavrilov.info/all/tetradki-nashe-vsyo-marimo-io-i-utochkadb/

Не существует единственного «лучшего» инструмента бизнес-аналитики (BI); лучший инструмент для вас зависит от ваших конкретных потребностей, рабочего процесса и набора навыков.

Это руководство сравнивает некоторые из самых популярных инструментов BI-as-code, чтобы помочь вам найти то, что наилучшим образом подходит для вашего стека анализа данных и технических компетенций:

* Evidence: Конструктор приложений на Markdown и SQL для аналитиков данных.
* Streamlit: Оболочка для веб-приложений для Python-специалистов по данным.
* Dash: Фреймворк для веб-приложений для Python-разработчиков.
* Observable: Набор инструментов для визуализации данных для JavaScript-разработчиков.
* Shiny: Простая R/Python-оболочка для статистиков и исследователей.
* Quarto: Минималистичная система публикации Jupyter/Markdown для ученых и технических писателей.

Каждый из этих инструментов является открытым исходным кодом, и вы можете найти исходный код на GitHub.

Evidence

Инструмент для создания приложений на SQL и Markdown

Evidence выделяется своим управлением входными данными через SQL-запросы и созданием содержимого страниц с помощью Markdown и предварительно созданных компонентов.

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

Evidence разработан для аналитиков, знакомых с SQL и Markdown, предлагая расширяемость через веб-стандарты. Приложения Evidence отлаженные, производительные и легко воспринимаются бизнес-стейкхолдерами.

Evidence также предлагает неограниченные возможности для определения ваших собственных пользовательских компонентов с использованием HTML и JavaScript, а также стилизации страниц через CSS. Он также поддерживает постоянно растущий список вариантов развертывания, включая Evidence Cloud — безопасный, управляемый хостинг-сервис.

Пример кода:

# Sales Report

<Slider min=2019 max=2024 name=year_pick title=Year size=full/>

```sql sales_by_month
SELECT
    order_month,
    category,
    sum(sales) AS sales
FROM orders
WHERE year = '${inputs.year_pick}'
GROUP BY ALL
```

<BarChart
  data={sales_by_month}
  title="Sales by Month"
  x=order_month
  y=sales
/>

Хороший выбор, если:

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

Не рекомендуется, если:

• Вы не хотите использовать SQL-запросы для управления входными данными.

---

Streamlit

Веб-приложение-обертка для pandas, numpy и других основных инструментов Python для анализа данных

Если вы уже знакомы с такими вещами, как numpy или pandas, документация Streamlit заставит вас почувствовать себя как дома. Оборачивая, например, `np.histogram` во что-то вроде `st.bar_chart`, Streamlit берет на себя перевод вашего Python-кода в веб-приложение.

Streamlit запускает ваш Python-скрипт сверху вниз, передавая выходные данные, такие как текст, таблицы или диаграммы, на страницу. Этот инструмент также можно использовать для создания чат-бота в стиле ChatGPT с использованием выходных данных на основе Python.

Пример кода:

import streamlit as st
import pandas as pd
import numpy as np

st.title('Uber pickups in NYC')

DATE_COLUMN = 'date/time'
DATA_URL = ('https://s3-us-west-2.amazonaws.com/'
         'streamlit-demo-data/uber-raw-data-sep14.csv.gz')

@st.cache_data
def load_data(nrows):
    data = pd.read_csv(DATA_URL, nrows=nrows)
    lowercase = lambda x: str(x).lower()
    data.rename(lowercase, axis='columns', inplace=True)
    data[DATE_COLUMN] = pd.to_datetime(data[DATE_COLUMN])
    return data

# Create a text element and let the reader know the data is loading.
data_load_state = st.text('Loading data...')
# Load 10,000 rows of data into the dataframe.
data = load_data(10000)
# Notify the reader that the data was successfully loaded.
data_load_state.text("Done! (using st.cache_data)")

st.subheader('Raw data')
st.write(data)

st.subheader('Number of pickups by hour')

hist_values = np.histogram(
    data[DATE_COLUMN].dt.hour, bins=24, range=(0,24))[0]

st.bar_chart(hist_values)

hour_to_filter = st.slider('hour', 0, 23, 17)  # min: 0h, max: 23h, default: 17h
filtered_data = data[data[DATE_COLUMN].dt.hour == hour_to_filter]
st.subheader(f'Map of all pickups at {hour_to_filter}:00')
st.map(filtered_data)

Хороший выбор, если:

• Вы являетесь Python-специалистом по данным, который хочет быстро создать веб-приложение, которым можно поделиться.

Не рекомендуется, если:

• Вам нужно настроить UI/UX, выходя за рамки базовых цветовых тем.
• Вам нужен точный контроль над повторной отрисовкой страницы (весь скрипт перезапускается при изменении входных данных, если вы не управляете фрагментами вручную).
• Вам не нравится писать Python-скрипты.

---

Dash

Фреймворк для веб-приложений на Python, предоставляющий прямой контроль над макетами, элементами DOM и обратными вызовами.

Dash позволяет Python-разработчикам создавать интерактивные веб-приложения без необходимости изучать JavaScript. Он предлагает существенный контроль и настройку для тех, кто готов углубиться в документацию. Ядро Dash — это класс Python, который объединяет несколько концепций:

• Python-обертки для отображения общих элементов DOM и визуализаций plotly (например, `html.H1`, `dcc.Graph`);
• Макет приложения, определенный как список вышеуказанных элементов в `app.layout`;
• Загрузка и обработка данных с помощью обычных средств анализа данных, таких как numpy или pandas;
• Интерактивность посредством обратных вызовов, которые принимают именованные входные данные из приложения (например, значение из выпадающего списка) и возвращают именованные выходные данные (например, отфильтрованный DataFrame);
• Возможность добавлять собственный CSS и JavaScript при необходимости.

Dash построен на базе Flask, поэтому любой Python-разработчик, имеющий опыт работы с веб-фреймворками, должен чувствовать себя в нем комфортно. Хотя R, Julia и F# также указаны как совместимые языки, подавляющее большинство документации Dash написано для Python.

Dash — мощный выбор для опытных программистов на Python, которым нужен точный контроль. Однако, если вам неудобны ментальные модели, такие как классы, обратные вызовы или DOM, кривая обучения в Dash может показаться несколько крутой.

Пример кода:

from dash import Dash, html, dcc, callback, Output, Input
import plotly.express as px
import pandas as pd

df = pd.read_csv('https://raw.githubusercontent.com/plotly/datasets/master/gapminder_unfiltered.csv')

app = Dash()

app.layout = [
    html.H1(children='Title of Dash App', style={'textAlign':'center'}),
    dcc.Dropdown(df.country.unique(), 'Canada', id='dropdown-selection'),
    dcc.Graph(id='graph-content')
]

@callback(
    Output('graph-content', 'figure'),
    Input('dropdown-selection', 'value')
)
def update_graph(value):
    dff = df[df.country==value]
    return px.line(dff, x='year', y='pop')

if __name__ == '__main__':
    app.run(debug=True)

Хороший выбор, если:

• У вас сильные навыки Python, и вы хотите более прямого контроля над макетом, стилизацией и интерактивностью, чем в Streamlit.
• Вы уже хорошо работаете с веб-фреймворками на базе Python, такими как Flask или Django.
• Вы знакомы с библиотеками для анализа данных на базе Python, такими как pandas, numpy и plotly.

Не рекомендуется, если:

• Вам неудобно работать с классами, обратными вызовами, методами или декораторами Python.
• Вам неудобно напрямую взаимодействовать с DOM.

---

Observable Framework

Инструментарий для визуализации данных для веб-разработчиков на JavaScript.

Если `npm run dev` — это ваша скорость, Observable Framework — отличный выбор для использования всей мощи веб-разработки при визуализации данных. Предоставляя вам импортируемые вспомогательные элементы, такие как Plot и FileAttachment, Observable упрощает интеграцию входных данных и предварительно созданных компонентов визуализации в ваше веб-приложение. У вас по-прежнему есть все обычные инструменты веб-разработки: HTML, JSX, компоненты React, стили CSS, функции JavaScript и импорты и т.д.

Хотя загрузчики данных для Observable могут быть написаны на любом языке программирования, базовый уровень комфорта с концепциями веб-разработки (например, HTML, CSS и JavaScript) позволит вам наилучшим образом использовать многие функции Observable.

Пример кода:

import * as Plot from 'npm:@observablehq/plot';

export function temperaturePlot(data, { width } = {}) {
	return Plot.plot({
		title: 'Hourly temperature forecast',
		width,
		x: { type: 'utc', ticks: 'day', label: null },
		y: { grid: true, inset: 10, label: 'Degrees (F)' },
		marks: [
			Plot.lineY(data.properties.periods, {
				x: 'startTime',
				y: 'temperature',
				z: null, // varying color, not series
				stroke: 'temperature',
				curve: 'step-after'
			})
		]
	});
}
# Weather report

import { temperaturePlot } from './components/temperaturePlot.js';

const forecast = FileAttachment('./data/forecast.json').json();

display(temperaturePlot(forecast));

Хороший выбор, если:

• Вы веб-разработчик, который разбирается в HTML, CSS и JavaScript и хочет в полной мере использовать свои обычные инструменты (например, Node, React).

Не рекомендуется, если:

• Вы не уверены, что такое node и npm, или что означает async/await.

---

Shiny

Авторитетная оболочка для R и Python, с акцентом на эффективную реактивность.

Если R или Python — ваш основной язык для анализа данных, и вы не заинтересованы в полноценной веб-разработке или ручном управлении обратными вызовами, то, возможно, стоит потрудиться, чтобы изучить ментальные модели Shiny. Из всех инструментов, рассмотренных в этой статье, он, вероятно, наиболее авторитетен в плане создания новых, специфичных для Shiny концепций, которые должен освоить пользователь. Например, все пользовательские входы (т.е. выпадающие списки) определяются с помощью функций `ui.input_*()`, а все выходы создаются декораторами, такими как `@render.plot`. Даже для опытного Python-разработчика понимание всех этих концепций может занять время. Код для сложной панели инструментов Shiny может стать довольно громоздким.

Преимущество всего этого заключается в том, что Shiny автоматически эффективно управляет реактивностью за вас. Их документация даже приводит пример воспроизведения панели инструментов Streamlit для более быстрой работы.

HTML, CSS и JavaScript могут управляться вручную, но необходимость их размещения внутри Python-оберток может привести к тому, что код будет выглядеть немного громоздко.

Если вы довольны использованием чистых, минималистичных, предварительно стилизованных компонентов Shiny и цените эффективную реактивность, Shiny может быть хорошим выбором.

Пример кода:

from shiny.express import input, render, ui
from shinywidgets import render_plotly

ui.page_opts(title="Penguins dashboard", fillable=True)

with ui.sidebar():
    ui.input_selectize(
        "var", "Select variable",
        ["bill_length_mm", "bill_depth_mm", "flipper_length_mm", "body_mass_g", "year"]
    )
    ui.input_numeric("bins", "Number of bins", 30)

with ui.card(full_screen=True):
    @render_plotly
    def hist():
        import plotly.express as px
        from palmerpenguins import load_penguins
        return px.histogram(load_penguins(), x=input.var(), nbins=input.bins())

Хороший выбор, если:

• У вас сильные навыки R или Python, и вы хотите использовать только эти языки.
• Вы цените быструю, эффективную реактивность и не хотите вручную управлять обратными вызовами.
• Вам нравится использовать чистые, минималистичные, предварительно стилизованные компоненты.

Не рекомендуется, если:

• Вы не хотите изучать специфические для Shiny ментальные модели для управления UI и реактивностью.
• Вы предпочитаете напрямую контролировать UI с помощью более традиционного стека веб-разработки (например, HTML / CSS / JS).
• Вам требуется очень тонкий контроль над внешним видом и ощущениями.

---

Quarto

Минималистичный рендерер страниц на Jupyter / Markdown, предназначенный для научной и технической публикации.

Если ваша цель — как можно быстрее и без излишеств преобразовать результаты анализа данных в HTML-файлы, .doc или PDF, Quarto может быть хорошим выбором. Quarto берет заметки Jupyter или Markdown в стиле Quarto и преобразует их в широкий спектр форматов. Доступны темы, а также некоторые параметры интерактивности. Фактически, если вы готовы потрудиться и изучить ее, Quarto предоставляет документацию для большинства задач, которые вы можете захотеть выполнить. В целом, однако, Quarto — хороший выбор для тех, кто уже знаком с заметками Jupyter и хочет быстро представить свою работу в общем формате без чрезмерной настройки или суеты.

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

Пример кода:

---
title: 'Quarto Basics'
format:
  html:
    code-fold: true
jupyter: python3
---

For a demonstration of a line plot on a polar axis, see @fig-polar.

#| label: fig-polar
#| fig-cap: "A line plot on a polar axis"

import numpy as np
import matplotlib.pyplot as plt

r = np.arange(0, 2, 0.01)
theta = 2 * np.pi * r
fig, ax = plt.subplots(
  subplot_kw = {'projection': 'polar'}
)
ax.plot(theta, r)
ax.set_rticks([0.5, 1, 1.5, 2])
ax.grid(True)
plt.show()

Хороший выбор, если:

• Вы уже знакомы с заметками Jupyter или Markdown и хотите быстро представить свою работу в общем формате с минимальной стилизацией.
• Вы не против изучать документацию для выполнения более сложных задач (например, пользовательские темы или развертывание в определенном сервисе, таком как Netlify).

Не рекомендуется, если:

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

---

Заключение

При выборе инструмента BI-as-code учитывайте технические навыки вашей команды и конкретные потребности:

* Evidence идеально подходит для аналитиков, которые в основном работают с SQL и хотят быстро создавать приложения для данных с использованием Markdown.
* Streamlit хорошо подходит для Python-специалистов по данным, стремящихся к быстрому прототипированию.
* Dash предлагает больше контроля для Python-разработчиков, знакомых с веб-фреймворками.
* Observable предоставляет полные возможности веб-разработки для JavaScript-разработчиков.
* Shiny подходит для пользователей R/Python, которым нужно эффективное управление реактивностью.
* Quarto идеально подходит для ученых и технических писателей, сосредоточенных на публикации документов.

Если вы хотите попробовать Evidence сами, вы можете начать бесплатно.

Evidence можно хостить на huggingface.co, но вот чем лучше в своей закрытой корпоративной среде пока не ясно. думаемс. 🤔

Кстати, вот такая штука еще интересная, но это тема другой статьи https://tabler.io/admin-template

The DuckLake Manifesto:
SQL как формат Lakehouse
Авторы: Марк Раасвельдт и Ханнес Мюляйзен
Оригинал: https://ducklake.select/manifesto/

DuckLake упрощает Lakehouse, используя стандартную базу данных SQL для всех метаданных вместо сложных файловых систем, при этом храня данные в открытых форматах, таких как Parquet. Это делает его более надежным, быстрым и простым в управлении.

Хотите послушать содержание этого манифеста? Мы также выпустили эпизод подкаста на ютубе, объясняющий, как мы пришли к формату DuckLake.

Или тут можно посмотреть:

Предыстория

Инновационные системы данных, такие как BigQuery и Snowflake, показали, что разделение хранилища и вычислений — отличная идея в то время, когда хранилище является виртуализированным товаром. Таким образом, и хранилище, и вычисления могут масштабироваться независимо, и нам не нужно покупать дорогие машины баз данных только для хранения таблиц, которые мы никогда не будем читать.

В то же время рыночные силы вынудили людей настаивать на том, чтобы системы данных использовали открытые форматы, такие как Parquet, чтобы избежать слишком распространенного “захвата” данных одним поставщиком. В этом новом мире множество систем данных с удовольствием резвились вокруг нетронутого «озера данных», построенного на Parquet и S3, и все было хорошо. Кому нужны эти старомодные базы данных!

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

Настоящее озеро данных/Lakehouse

Настоящее озеро данных. Может быть, больше похоже на домик у озера.

Iceberg и Delta

Для решения основной задачи изменения данных в озере появились различные новые открытые стандарты, наиболее заметные из которых — Apache Iceberg и Linux Foundation Delta Lake. Оба формата были разработаны для того, чтобы, по сути, вернуть некоторую разумность в изменении таблиц, не отказываясь от основной предпосылки: использовать открытые форматы в блочном хранилище. Например, Iceberg использует лабиринт файлов JSON и Avro для определения схем, снимков и того, какие файлы Parquet являются частью таблицы в определенный момент времени. Результат был назван «Lakehouse», по сути, дополнением функций базы данных к озерам данных, что позволило реализовать множество новых увлекательных вариантов использования для управления данными, например, обмен данными между движками.

Архитектура таблицы Iceberg

Но оба формата столкнулись с проблемой: поиск последней версии таблицы затруднен в блочных хранилищах с их изменчивыми гарантиями согласованности. Трудно атомарно (буква «А» в ACID) поменять указатель, чтобы убедиться, что все видят последнюю версию. Iceberg и Delta Lake также знают только об одной таблице, но люди – опять же, шокирующе – хотели управлять несколькими таблицами.

Каталоги

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

Архитектура каталога Iceberg

Вы говорите, база данных?

Но вот в чем проблема: Iceberg и Delta Lake были специально разработаны так, чтобы не требовать базу данных. Их дизайнеры приложили большие усилия, чтобы закодировать всю информацию, необходимую для эффективного чтения и обновления таблиц, в файлы в блочном хранилище. Они идут на многие компромиссы, чтобы достичь этого. Например, каждый корневой файл в Iceberg содержит все существующие снимки со схемой и т. д. Для каждого изменения записывается новый файл, который содержит полную историю. Многие другие метаданные должны были быть объединены, например, в двухуровневых файлах манифеста, чтобы избежать записи или чтения слишком большого количества мелких файлов, что не было бы эффективным в блочных хранилищах. Внесение небольших изменений в данные также является в значительной степени нерешенной проблемой, которая требует сложных процедур очистки, которые до сих пор не очень хорошо изучены и не поддерживаются реализациями с открытым исходным кодом. Существуют целые компании, и до сих пор создаются новые, чтобы решить эту проблему управления быстро меняющимися данными. Почти так, как если бы специализированная система управления данными была бы хорошей идеей.

Но, как указано выше, дизайны Iceberg и Delta Lake уже были вынуждены пойти на компромисс и добавить базу данных в качестве части каталога для обеспечения согласованности. Однако они никогда не пересматривали остальные свои проектные ограничения и стек технологий, чтобы приспособиться к этому фундаментальному изменению дизайна.

DuckLake

Здесь, в DuckDB, мы на самом деле любим базы данных. Это удивительные инструменты для безопасного и эффективного управления довольно большими наборами данных. Раз уж база данных все равно вошла в стек Lakehouse, имеет безумный смысл использовать ее и для управления остальными метаданными таблицы! Мы все еще можем использовать «бесконечную» емкость и «безграничную» масштабируемость блочных хранилищ для хранения фактических данных таблицы в открытых форматах, таких как Parquet, но мы можем гораздо более эффективно и действенно управлять метаданными, необходимыми для поддержки изменений в базе данных! По совпадению, это также то, что выбрали Google BigQuery (со Spanner) и Snowflake (с FoundationDB), только без открытых форматов в нижней части.

Архитектура DuckLake: просто база данных и несколько файлов Parquet.

Для решения фундаментальных проблем существующей архитектуры Lakehouse мы создали новый открытый табличный формат под названием DuckLake. DuckLake переосмысливает то, как должен выглядеть формат «Lakehouse», признавая две простые истины:

Хранение файлов данных в открытых форматах в блочном хранилище — отличная идея для масштабируемости и предотвращения привязки к поставщику.
Управление метаданными — это сложная и взаимосвязанная задача управления данными, которую лучше оставить системе управления базами данных.
Основная идея DuckLake заключается в перемещении всех структур метаданных в базу данных SQL, как для каталога, так и для табличных данных. Формат определяется как набор реляционных таблиц и «чистые» транзакции SQL над ними, описывающие операции с данными, такие как создание, изменение схемы, а также добавление, удаление и обновление данных. Формат DuckLake может управлять произвольным количеством таблиц с межтабличными транзакциями. Он также поддерживает «расширенные» концепции баз данных, такие как представления, вложенные типы, транзакционные изменения схемы и т. д.; см. ниже список. Одним из основных преимуществ такого дизайна является использование ссылочной целостности (буква «C» в ACID), схема гарантирует, например, отсутствие дублирующихся идентификаторов снимков.

Схема DuckLake

Какую именно базу данных SQL использовать, решает пользователь, единственные требования — система должна поддерживать операции ACID и первичные ключи, а также стандартный SQL. Внутренняя схема таблицы DuckLake намеренно сделана простой, чтобы максимизировать совместимость с различными базами данных SQL. Вот основная схема на примере.

Давайте рассмотрим последовательность запросов, которые происходят в DuckLake при выполнении следующего запроса на новой, пустой таблице:

INSERT INTO demo VALUES (42), (43);

BEGIN TRANSACTION;
 -- некоторые чтения метаданных здесь пропущены
  INSERT INTO ducklake_data_file VALUES (0, 1, 2, NULL, NULL, 'data_files/ducklake-8196...13a.parquet', 'parquet', 2, 279, 164, 0, NULL, NULL);
  INSERT INTO ducklake_table_stats VALUES (1, 2, 2, 279);
  INSERT INTO ducklake_table_column_stats VALUES (1, 1, false, NULL, '42', '43');
  INSERT INTO ducklake_file_column_statistics VALUES (0, 1, 1, NULL, 2, 0, 56, '42', '43', NULL);
  INSERT INTO ducklake_snapshot VALUES (2, now(), 1, 2, 1);
  INSERT INTO ducklake_snapshot_changes VALUES (2, 'inserted_into_table:1');
COMMIT;

Мы видим единую целостную транзакцию SQL, которая:

Вставляет новый путь к файлу Parquet
Обновляет глобальную статистику таблицы (теперь имеет больше строк)
Обновляет глобальную статистику столбцов (теперь имеет другое минимальное и максимальное значение)
Обновляет статистику столбцов файла (также записывает помимо прочего минимум/максимум)
Создает новый снимок схемы (#2)
Регистрирует изменения, произошедшие в снимке
Обратите внимание, что фактическая запись в Parquet не является частью этой последовательности, она происходит заранее. Но независимо от того, сколько значений добавлено, эта последовательность имеет ту же (низкую) стоимость.

Давайте обсудим три принципа DuckLake: простоту, масштабируемость и скорость.

Простота

DuckLake следует принципам проектирования DuckDB, заключающимся в сохранении простоты и постепенности. Для запуска DuckLake на ноутбуке достаточно просто установить DuckDB с расширением ducklake. Это отлично подходит для целей тестирования, разработки и прототипирования. В этом случае хранилищем каталога является просто локальный файл DuckDB.

Следующим шагом является использование внешних систем хранения. Файлы данных DuckLake неизменяемы, он никогда не требует модификации файлов на месте или повторного использования имен файлов. Это позволяет использовать его практически с любой системой хранения. DuckLake поддерживает интеграцию с любой системой хранения, такой как локальный диск, локальный NAS, S3, Azure Blob Store, GCS и т. д. Префикс хранения для файлов данных (например, s3://mybucket/mylake/) указывается при создании таблиц метаданных.

Наконец, база данных SQL, размещающая сервер каталога, может быть любой более-менее компетентной базой данных SQL, которая поддерживает ACID и ограничения первичного ключа. Большинство организаций уже имеют большой опыт эксплуатации такой системы. Это значительно упрощает развертывание, поскольку помимо базы данных SQL не требуется никакого дополнительного программного обеспечения. Кроме того, базы данных SQL в последние годы стали широко доступны, существует бесчисленное множество размещенных служб PostgreSQL или даже размещенных DuckDB, которые могут использоваться в качестве хранилища каталога! Опять же, привязка к поставщику здесь очень ограничена, потому что переход не требует перемещения данных таблицы, а схема проста и стандартизирована.

Нет файлов Avro или JSON. Нет дополнительного сервера каталогов или дополнительного API для интеграции. Все это просто SQL. Мы все знаем SQL.

Масштабируемость

DuckLake фактически увеличивает разделение проблем в архитектуре данных на три части: хранение, вычисления и управление метаданными. Хранение остается на специализированном файловом хранилище (например, блочное хранилище), DuckLake может масштабироваться бесконечно в хранении.

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

Наконец, база данных каталога должна быть способна выполнять только те транзакции метаданных, которые запрашиваются вычислительными узлами. Их объем на несколько порядков меньше, чем фактические изменения данных. Но DuckLake не привязан к одной базе данных каталога, что позволяет мигрировать, например, из PostgreSQL на что-то другое по мере роста спроса. В конечном итоге, DuckLake использует простые таблицы и базовый, переносимый SQL. Но не беспокойтесь, DuckLake, поддерживаемый PostgreSQL, уже сможет масштабироваться до сотен терабайт и тысяч вычислительных узлов.

Опять же, это именно тот дизайн, который используют BigQuery и Snowflake, которые уже успешно управляют огромными наборами данных. И, ничего не мешает вам использовать Spanner в качестве базы данных каталога DuckLake, если это необходимо.

Скорость

Как и сам DuckDB, DuckLake очень ориентирован на скорость. Одной из самых больших проблем Iceberg и Delta Lake является сложная последовательность операций ввода-вывода файлов, необходимая для выполнения самого маленького запроса. Следование по пути каталога и метаданных файлов требует многих отдельных последовательных HTTP-запросов. В результате существует нижний предел того, насколько быстро могут выполняться чтения или транзакции. Много времени тратится на критический путь фиксации транзакций, что приводит к частым конфликтам и дорогостоящему разрешению конфликтов. Хотя кэширование может использоваться для решения некоторых из этих проблем, это добавляет дополнительную сложность и эффективно только для «горячих» данных.

Единые метаданные в базе данных SQL также позволяют планировать запросы с низкой задержкой. Чтобы прочитать данные из таблицы DuckLake, один запрос отправляется в базу данных каталога, которая выполняет сокращение на основе схемы, разделов и статистики, чтобы, по сути, получить список файлов для чтения из блочного хранилища. Нет множественных обращений к хранилищу для извлечения и восстановления состояния метаданных. Также меньше вероятность возникновения ошибок, нет регулирования S3, нет неудачных запросов, нет повторных попыток, нет еще не согласованных представлений хранилища, которые приводят к невидимости файлов и т. д.

DuckLake также способен улучшить две самые большие проблемы производительности озер данных: небольшие изменения и множество одновременных изменений.

Для небольших изменений DuckLake значительно сократит количество мелких файлов, записываемых в хранилище. Нет нового файла снимка с крошечным изменением по сравнению с предыдущим, нет нового файла манифеста или списка манифестов. DuckLake даже опционально позволяет прозрачно встраивать небольшие изменения в таблицы непосредственно в метаданные! Оказывается, систему баз данных можно использовать и для управления данными. Это позволяет выполнять запись за доли миллисекунды и улучшать общую производительность запросов за счет уменьшения количества файлов, которые необходимо считывать. Записывая гораздо меньше файлов, DuckLake также значительно упрощает операции очистки и сжатия.

В DuckLake изменения таблицы состоят из двух шагов: подготовки файлов данных (если таковые имеются) к хранению, а затем выполнения одной транзакции SQL в базе данных каталога. Это значительно сокращает время, затрачиваемое на критический путь фиксации транзакций, поскольку нужно выполнить только одну транзакцию. Базы данных SQL довольно хорошо справляются с разрешением конфликтов транзакций. Это означает, что вычислительные узлы тратят гораздо меньше времени на критический путь, где могут возникать конфликты. Это позволяет значительно быстрее разрешать конфликты и выполнять гораздо больше параллельных транзакций. По сути, DuckLake поддерживает столько изменений таблицы, сколько может зафиксировать база данных каталога. Даже почтенный Postgres может выполнять тысячи транзакций в секунду. Можно было бы запустить тысячу вычислительных узлов, выполняющих добавление в таблицу с интервалом в одну секунду, и это работало бы нормально.

Кроме того, снимки DuckLake — это всего лишь несколько строк, добавленных в хранилище метаданных, что позволяет существовать множеству снимков одновременно. Нет необходимости заблаговременно удалять снимки. Снимки также могут ссылаться на части файла Parquet, что позволяет существовать гораздо большему количеству снимков, чем файлов на диске. В совокупности это позволяет DuckLake управлять миллионами снимков!

Возможности

DuckLake обладает всеми вашими любимыми функциями Lakehouse:

Произвольный SQL: DuckLake поддерживает все те же обширные возможности SQL, что и, например, DuckDB.
Изменения данных: DuckLake поддерживает эффективное добавление, обновление и удаление данных.
Множественная схема, множественные таблицы: DuckLake может управлять произвольным количеством схем, каждая из которых содержит произвольное количество таблиц в одной и той же структуре метаданных.
Межтабличные транзакции: DuckLake поддерживает транзакции, полностью соответствующие ACID, для всех управляемых схем, таблиц и их содержимого.
Сложные типы: DuckLake поддерживает все ваши любимые сложные типы, такие как списки, произвольно вложенные.
Полная эволюция схемы: Схемы таблиц могут изменяться произвольно, например, столбцы могут быть добавлены, удалены или их типы данных изменены.
Отмотка времени и откат на уровне схемы: DuckLake поддерживает полную изоляцию снимков и отмотку времени, позволяя запрашивать таблицы на определенный момент времени.
Инкрементальное сканирование: DuckLake поддерживает получение только тех изменений, которые произошли между указанными снимками.
Представления SQL: DuckLake поддерживает определение лениво оцениваемых представлений SQL.
Скрытое разбиение на разделы и отсечение: DuckLake учитывает разбиение данных на разделы, а также статистику на уровне таблиц и файлов, что позволяет заранее отсекать сканирование для максимальной эффективности.
Транзакционные DDL: Создание, эволюция и удаление схем, таблиц и представлений полностью транзакционны.
Избегание уплотнения данных: DuckLake требует гораздо меньше операций уплотнения, чем сопоставимые форматы. DuckLake поддерживает эффективное уплотнение снимков.
Встраивание: При внесении небольших изменений в данные DuckLake может опционально использовать базу данных каталога для прямого хранения этих небольших изменений, чтобы избежать записи множества мелких файлов.
Шифрование: DuckLake может опционально шифровать все файлы данных, записываемые в хранилище, что позволяет размещать данные с нулевым доверием. Ключи управляются базой данных каталога.
Совместимость: Файлы данных и (позиционные) файлы удаления, которые DuckLake записывает в хранилище, полностью совместимы с Apache Iceberg, что позволяет выполнять миграцию только метаданных.
Заключение

Мы выпустили DuckLake v0.1 с расширением DuckDB ducklake в качестве первой реализации. Мы надеемся, что вы найдете DuckLake полезным в своей архитектуре данных – с нетерпением ждем ваших творческих вариантов использования!

Немного про эффективность от себя

Все достаточно легко

Подготовка

python3 -m venv ./whisper

Активация и установка этого https://github.com/SYSTRAN/faster-whisper

source ./whisper/bin/activate
pip install faster-whisper

Сам код

import sys
import os
import time
from faster_whisper import WhisperModel

# --- Конфигурация модели Whisper ---
model_size = "large-v3"
# Выберите свою конфигурацию:
# model = WhisperModel(model_size, device="cuda", compute_type="float16") # Если есть GPU и CUDA
# model = WhisperModel(model_size, device="cuda", compute_type="int8_float16") # Если есть GPU и CUDA с INT8
model = WhisperModel(model_size, device="cpu", compute_type="int8") # Для CPU (как в вашем примере)
# -----------------------------------

def transcribe_mp3_to_text(mp3_filepath):
    """
    Транскрибирует MP3 файл и сохраняет результат в текстовый файл.
    """
    if not os.path.exists(mp3_filepath):
        print(f"Ошибка: Файл MP3 не найден: {mp3_filepath}")
        return False

    if not mp3_filepath.lower().endswith(".mp3"):
        print(f"Ошибка: Файл '{mp3_filepath}' не является MP3 файлом. Пропускаем.")
        return False

    # Извлечение имени файла без расширения
    filename_without_ext = os.path.splitext(os.path.basename(mp3_filepath))[0]
    output_txt_filepath = os.path.join(os.path.dirname(mp3_filepath), f"{filename_without_ext}.txt")

    print(f"[{time.strftime('%Y-%m-%d %H:%M:%S')}] Начинаем транскрипцию '{mp3_filepath}'...")
    print(f"Результат будет сохранен в '{output_txt_filepath}'")

    try:
        segments, info = model.transcribe(mp3_filepath, beam_size=5)

        detected_language_msg = f"Detected language: '{info.language}' with probability {info.language_probability:.2f}"
        print(detected_language_msg)

        # Сохранение транскрипции в текстовый файл
        with open(output_txt_filepath, 'w', encoding='utf-8') as f_out:
            f_out.write(f"--- Транскрипция для: {os.path.basename(mp3_filepath)} ---\n")
            f_out.write(f"{detected_language_msg}\n\n")
            
            full_text = [] # Для сбора всего текста, если нужно вывести в конце

            for segment in segments:
                segment_line = f"[{segment.start:.2f}s -> {segment.end:.2f}s] {segment.text}"
                print(segment_line) # Выводим в консоль для отладки
                f_out.write(f"{segment.text}\n") # Записываем только текст в файл, по сегментам
                full_text.append(segment.text)

            # Если вы хотите сохранить всю транскрипцию одним блоком в конце файла или отдельный файл
            # f_out.write("\n\n--- Полный текст ---\n")
            # f_out.write(" ".join(full_text))

        print(f"[{time.strftime('%Y-%m-%d %H:%M:%S')}] Транскрипция успешно завершена! Результат в '{output_txt_filepath}'")
        return True

    except Exception as e:
        print(f"Ошибка при транскрипции файла '{mp3_filepath}': {e}")
        # Вы можете добавить логирование ошибки в отдельный файл, если нужно
        return False

if __name__ == "__main__":
    if len(sys.argv) < 2:
        print("Использование: python process_mp3.py <путь/к/вашему/файлу.mp3>")
        sys.exit(1)

    mp3_file_path_arg = sys.argv[1] # Это будет полный путь к MP3 файлу, переданный из Automator/Bash
    transcribe_mp3_to_text(mp3_file_path_arg)

Итоги запуска

(whisper) (base) yuriygavrilov@MacBookPro fastwhisper % python whisp.py            
Detected language 'ru' with probability 0.998883
[0.00s -> 4.96s]  Раз, два, три, привет, как дела?
[5.94s -> 8.54s]  Все хорошо, а у тебя как?
[9.54s -> 10.78s]  И у меня все хорошо
[10.78s -> 12.98s]  Спасибо, пока
(whisper) (base) yuriygavrilov@MacBookPro fastwhisper %

тестовый файл тут

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

Буду делать через приложении на маке automator

Как то примерно так :)

осталось прикрутить это а действие к папке

кажись заработало :)

Создалась транскрипция сама

получилось в итоге вот так: Открываем Automator, настраиваем действие и все.

работает так: кидаем файл в папку тест, скрипт запускается, транскрипция появляется рядом. Все.

Проверим качество модели на этом:

почти идеал 🤘

Второй раз чуть иначе, но почти точно.

Но только для мака и есть локальные модели

https://superwhisper.com

недавно появилось приложение для ИОС

https://apps.apple.com/us/app/superwhisper/id6471464415

В целом нейронка показывает себя достойно, почти как 4.0 но чуть качественнее и может создавать треки по 8 минут. 4 могла только до 4 минут.

Пара экспериментов

Жрецы данных :) 🤣🤘🎸

А вот по заказу в стиле кровостока 🤣 от Александра Баракова, но пожалуй надо текст переписать

Другой текст 🙉

Это то как нейронка понимает dmbok и предлагает исполнение, от себя я не добавлял ничего. Но был интересный опыт в первом промте я попросил нейронку дать рекомендации, не только для меня но и для другой нейронки. ( deepseek был первый, вторая flash 2.5 preview )

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

Анна Ахматова

Ремикс на песню apologies onerepublic

Кстати нейронка теперь лучше защищает авторские права, ее нельзя попросить спой как Киркоров, идет проверка по названиям треков и исполнителям. Но можно другую нейронку попросить переделать песню. Вот как например эта:

Этот трек переписала другая нейронка, но с сохранением смысла. Использовала Flash 2.5 preview.

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

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

В версии 4.5 появился функционал генерации кусочков, то есть если песня вам нравится, а только некоторые слова или окончание надо поправить, то это можно сделать. Заменить можно примерно любые 6 секунд.

Немного профильных треков:

Для сравнение этот трек сделан на версии 4.0:

А тут немного личного :) такое нейронка пишет на после анализа чатов, ну почти 🙈🥹

Все тексты делал тут: http://openrouter.ai в основном Gemini Flash 2.5 либо DeepSeek R1

Для начала поиграем в CDO, проверяем навыки и зарабатываем все деньги мира 😁

Игра тут: https://www.whoisthebestcdo.com

Who’s the best CDO? 🔊 ( не забываем включать звук для мотивации 🤘 )

You’re the newly appointed Chief Data Officer. Your role is to guide your company through data chaos, one paw-step at a time. Expect surprises in your inbox and remember : data is your territory now.

Как думаете стоит сделать перевод на русский? 🧐

Теперь расслабляемся и смотрим просто :) 📺

Data Corp – Первая серия

Интервью с победителем в игре :)

Полная версия тут

Краткое содержание

Книга “Построение эволюционных архитектур” Нила Форда, Ребекки Парсонс и Патрика Куа рассматривает подход к разработке программных систем, которые легко адаптируются к изменениям и новым требованиям. Книга подчеркивает важность постепенных изменений, объективных критериев оценки архитектуры (fitness-функций) и разумной связанности между компонентами. Авторы подробно описывают принципы, практики и антипаттерны эволюционного подхода, чтобы помочь читателям создавать гибкие и устойчивые системы.

Основные тезисы и выводы

• Эволюционная архитектура – это не просто методология, это философия:** Подход к построению систем, которые “учатся” и адаптируются к изменениям, в отличие от жёстких, заранее спланированных архитектур.
• Изменения неизбежны и к ним надо готовиться:** Современный мир разработки требует гибкости. Эволюционные архитектуры призваны облегчить внесение изменений, а не предотвращать их.
• Fitness-функции – это компас для эволюции:** Объективные критерии оценки архитектуры, которые помогают защитить важные её характеристики в процессе изменений (производительность, безопасность, масштабируемость и т.д.).
• Постепенность и малые изменения – основа успеха:** Небольшие инкрементальные изменения легче контролировать, тестировать и развертывать, чем крупные реструктуризации. Большие изменения происходят из маленьких шагов.
• Связанность должна быть разумной и осознанной:** Чрезмерная связанность (coupling) затрудняет изменения. Необходимо стремиться к минимальной связанности, необходимой для решения бизнес-задач и функциональной целостности. Разумная связанность должна обеспечивать масштабируемость и надежность.
• Команда и культура важны не меньше, чем технологии:** Успешное внедрение эволюционной архитектуры требует кросс-функциональной команды с культурой экспериментов и автоматизации (DevOps).
• Инструменты и автоматизация – основа практики:** Автоматизированные процессы и конвейеры развертывания (deployment pipelines) позволяют быстро и надежно вносить изменения и оценивать их влияние на архитектуру. Автоматизация позволяет снизить цену изменений.

Заключение

Книга “Построение эволюционных архитектур” предоставляет ценную методологию для разработки программных систем, способных адаптироваться к постоянным изменениям. Книга будет полезной для архитекторов, разработчиков и руководителей, стремящихся создавать гибкие, устойчивые и конкурентоспособные решения. Эта книга – практическое руководство по эволюции программного обеспечения, а не попытка навязать еще один “серебряный шар”.

Рекомендации

1. Начните с анализа текущей архитектуры: Определите узкие места, критические зависимости и области, требующие большей гибкости.
2. Определите ключевые fitness-функции: Какие характеристики архитектуры наиболее важны для бизнеса? Установите объективные критерии их оценки.
3. Постепенно внедряйте конвейеры развертывания (deployment pipelines): Автоматизируйте процессы сборки, тестирования и развертывания небольших изменений.
4. Поддерживайте культуру экспериментов: Поощряйте небольшие, контролируемые эксперименты с новыми технологиями и подходами.
5. Используйте потребительски ориентированные контакты: Отслеживайте требования потребителей и используйте feedback для постоянного совершенствования архитектуры.
6. Создавайте небольшую, но эффективную команду: Кросс-функциональная команда с необходимыми навыками будет залогом успешной эволюции архитектуры.
7. Учитывайте организационные факторы: Адаптируйте структуру команды, процессы бюджетирования и управления изменениями, чтобы поддерживать эволюционный подход.
8. Применяйте на практике теорию Эрика Эванса в книге “Домен управляемый дизайн”: Эффективные архитектурные решения будут приниматься с учетом предметной области.

План действий согласно книге

1. Оценка текущей ситуации:
   • Анализ архитектуры: Определение проблемных мест, связей, которые необходимо уменьшить.
   • Оценка зрелости команды: Анализ навыков, процессов и культуры разработки.
2. Определение целей и стратегии:
   • Определение ключевых бизнес-целей: Что должна обеспечивать архитектура? Чего ожидает бизнес? Какова ключевая ценность?
   • Выбор стиля архитектуры: Учитывая ограничения и требования, выбрать подходящий стиль архитектуры (микросервисы, SOA, монолит с модульной структурой и т.д.).
3. Внедрение изменений:
   • Разработка fitness-функций: Для защиты архитектуры с новыми возможностями.
   • Постепенные изменения с использованием deployment pipelines: Автоматизация процессов сборки, тестирование, изменение
   • Создание Cross-функциональной команды: Поместите все необходимые ресурсы в команду, чтобы уменьшить препятствия.
4. Непрерывное совершенствование:
   • Анализ метрик и feedback: Постоянный сбор информации о работе системы и ее воздействии на бизнес.
   • Регулярный пересмотр архитектуры и fitness-функций: Адаптация к изменяющимся требованиям и технологиям.

Инструкция оригинал тут

Потом еще свой код покажу, но он работает в версии 1.65, надо бы обновить.

Документ представляет собой руководство по разработке автономных систем (агентов) на базе языковых моделей (LLM). Основные темы:

Определение агентов: системы, выполняющие задачи от имени пользователя с высокой степенью автономии.
Ключевые компоненты: модели LLM, инструменты (API, функции), инструкции, защитные механизмы (guardrails).
Оркестрация: подходы к управлению агентами (одиночные и мультиагентные системы).
Guardrails: механизмы безопасности для контроля рисков.
Практические рекомендации: выбор моделей, проектирование инструментов, обработка исключений, интеграция с людьми.

Ниже не полный перевод. Раздел Guardrails очень интересный!

Практическое руководство по созданию агентов

Автор: OpenAI

---

Содержание

1. Введение
2. Что такое агент?
3. Когда следует создавать агента?
4. Основы проектирования агентов
5. Выбор моделей
6. Определение инструментов
7. Конфигурация инструкций
8. Оркестрация
   • 8.1. Системы с одним агентом
   • 8.2. Мультиагентные системы
9. Защитные механизмы (Guardrails)
10. Заключение

---

1. Введение

Крупные языковые модели (LLM) становятся всё более способными решать сложные многошаговые задачи. Достижения в области логических рассуждений, мультимодальности и использования инструментов открыли новую категорию систем на базе LLM — агентов.

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

После прочтения вы узнаете:

• Как выбирать подходящие сценарии использования.
• Как проектировать логику агентов и управлять их взаимодействием.
• Как обеспечивать безопасность и предсказуемость работы.

---

2. Что такое агент?

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

Ключевые характеристики:

1. Использование LLM
   • Управление рабочими процессами.
   • Корректировка действий при ошибках.
2. Доступ к инструментам
   • Взаимодействие с API, базами данных, внешними системами.

Примеры задач:

• Обработка запросов в службе поддержки.
• Бронирование ресторана.
• Генерация отчётов.

Не являются агентами:

• Простые чат-боты.
• Системы без управления рабочими процессами.

---

3. Когда следует создавать агента?

Агенты подходят для задач, где традиционные правила и детерминированные системы неэффективны.

Сценарии для внедрения:

Перед созданием агента:

• Убедитесь, что задача требует неоднозначных решений.
• Если задача простая, используйте детерминированные методы.

---

4. Основы проектирования агентов

Агент состоит из трёх компонентов:

Пример кода (Agents SDK):

weather_agent = Agent(  
    name="Weather agent",  
    instructions="Вы помощник, который отвечает на вопросы о погоде.",  
    tools=[get_weather],  
)

---

5. Выбор моделей

Рекомендации:

1. Начните с самой мощной модели для базового уровня производительности.
2. Заменяйте её на более лёгкие модели, где это возможно.

Примеры задач:

• Простые запросы → Маленькие модели (например, `gpt-3.5`).
• Сложные решения → Мощные модели (например, `gpt-4`).

---

6. Определение инструментов

Инструменты расширяют возможности агентов через API.

Типы инструментов:

Пример кода:

search_agent = Agent(  
    name="Search agent",  
    instructions="Помогите пользователю искать в интернете.",  
    tools=[WebSearchTool(), save_results],  
)

---

7. Конфигурация инструкций

Рекомендации:

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

Пример генерации инструкций:

prompt = """  
Вы эксперт по созданию инструкций для агентов.  
Преобразуйте документ в нумерованный список без неоднозначностей.  
Документ: {{help_center_doc}}  
"""

---

8. Оркестрация

8.1. Системы с одним агентом

• Один агент управляет всеми задачами.
• Простота внедрения и обслуживания.

Пример работы:

await Runner.run(agent, [UserMessage("Столица США?")])

8.2. Мультиагентные системы

• Менеджер-агент координирует специализированных агентов.
• Децентрализованные агенты передают задачи друг другу.

Пример менеджер-агента:

manager_agent = Agent(  
    name="Менеджер переводов",  
    tools=[spanish_agent, french_agent],  
)

---

9. Защитные механизмы (Guardrails)

Цель: Предотвращение рисков (утечки данных, вредоносные запросы).

Типы защит:

• Классификатор релевантности → Фильтрация не относящихся к делу запросов.
• Фильтр PII → Защита персональных данных.
• Модерация → Блокировка вредоносного контента.

Пример кода:

@input_guardrail  
async def churn_detection(ctx, input):  
    # Проверка риска оттока клиентов  
    ...

---

10. Заключение

Ключевые принципы:

• Начинайте с простых агентов.
• Используйте защитные механизмы.
• Планируйте вмешательство человека для критических задач.

Агенты открывают новые возможности для автоматизации сложных рабочих процессов.

OpenAI — компания, занимающаяся разработкой ИИ. Наша миссия — обеспечить, чтобы искусственный интеллект приносил пользу человечеству.