Нормативная инженерия умных приложений и агентов

Посты студентов Системная инженерия
, , , ,
1

Задача: написать что-то про нормативную инженерию ПО на спектре от “умных приложений” (читай: с использованием ML и LLMs) до “агентов”.

Prior art: учебник “Системная инженерия”, Gaia Network: An Illustrated Primer - by Roman Leventov, другие существующие учебники типа AI Agents in Action, The Landscape of Emerging AI Agent Architectures for Reasoning, Planning, and Tool Calling: A Survey, книги и статьи об опыте создания умных приложений с ML (хотя я не уверен, какие).

Опыт существующих систем:

  • Реальные агенты в эксплуатации
  • Проприетарные фреймворки: Agent.ai, MultiOn.ai, etc.
  • Опен-сорсные фреймворки: LangGraph, LangStream, AutoGen, Promptflow, etc.
    • Warning: эти фреймворки часто пишутся академиками ещё до реальных применений и количество звёзд плохо коррелирует с качеством

Пример идеи/рекомендации, которая мне кажется важной, но которая пока не достигла масс

Приложения до текущего момента в основном создавались для людей. Доминирует следующая архитектура: база данных с состоянием “на сейчас”, бизнес-логика, фронтенд. Идея Мартина Клеппманна “Turning the database inside out” не особо взлетела.

Приложения “для агентов” или “сросшиеся с агентами” требуют симуляций для RL, аудита и дебага прошлых действий, поэтому желательно иметь полный “paper trail” всех состояний в любой момент времени чтобы можно было при необходимости восстановить прошлое “состояние мозгов” модели/агента и форкнуть его. Поэтому, я думаю что идея stream/“immutable database” processing/turning the database inside-out получит второе дыхание и должна применяться в агентских архитектурах.

Если кто-то хочет поучаствовать в этом, давайте сделаем рабочую группу.

1 лайк
2

Вот довольно фундаментальный, хоть и короткий текст на тему: The Shift from Models to Compound AI Systems – The Berkeley Artificial Intelligence Research Blog. В нем указываются следующие свойства умных приложений и агентов:

  • Стандартные свойства “производительности” для ML и поиска (accuracy, etc.), а также множество производных высокоуровневых свойств, специфичных для функций/роли приложения, от relevance до disturbance robustness.
  • Скалируемость в смысле “scaling laws” первого рода (training time) и второго рода (inference time)
  • “Динамичность”: как быстро приложение подстраивается к новой реальности/данным. На спектре от лет (a la “LLM knowledge cutoff: 2023”) до микросекунд.
  • Управляемость и “гарантии результатов” (controllability and trust): модельные обоснования ([2408.05284] Can a Bayesian Oracle Prevent Harm from an Agent?), логические доказательства
  • Latency and cost - потребление ресурсов

Кроме того, ниже они дают еще несколько операционных и архитектурных свойств:

  • Auditability (loggability)/traceability/debuggability
  • DataOps характеристики для данных, которые нужны приложению или агенту во время тренировки или инференса. В терминах “-остей” это можно сформулировать как доступность, обновляемость (= доступность новых), проверяемость/валидируемость, релевантность данных
  • Security

Это все хорошо соотносится с этим списком:

Инфоэффективность = динамичность.

Хотя сама статья называет системы compound AI systems (a system composed of LLM calls and other tools), о модулярности/композиционности/интероперабельности/интегрируемости этих систем друг с другом а-ля society of minds и не только не упоминяется. Возможно, потому что рынок еще не созрел (или не созрел на февраль 2024 - время выхода статьи) для этого: еще (было) нечему “общаться”/композироваться. Так или иначе, композиционность это как раз наша “любимая” тема в Gaia agenda.