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 — компания, занимающаяся разработкой ИИ. Наша миссия — обеспечить, чтобы искусственный интеллект приносил пользу человечеству.

🔥 Classifier Factory от Mistral

Classifier Factory — это интуитивно понятное руководство для создания и обучения собственных моделей классификации на базе компактных LLM от Mistral AI.

С его помощью — как через веб‑интерфейс La Plateforme, так и через API — можно быстро разворачивать решения для модерации контента, детекции намерений, анализа тональности, кластеризации данных, обнаружения мошенничества, фильтрации спама, рекомендательных систем и других задач

Таким образом, Classifier Factory упрощает весь цикл работы с custom‑классификаторами: от подготовки данных до развёртывания готовой модели в продакшене.

Еще они обнвоили доку.

🔜 Docs
🔜Cookbook: Moderation Classifier
🔜Cookbook: Intent Classification
🔜Cookbook: Classification of Food

@ai_machinelearning_big_data

#Mistral #api

https://habr.com/ru/companies/recognitor/articles/898152/