Почти интеллектуальные системы» (Smart (enough) systems) (Рубрика Processes)

Нашел у себя на полке книгу про интеллектуальные системы, что вышла почти 20 лет назад. Когда-то давно я ее читал и в ней было много умных слов. А сейчас я ее открыл и понял, что если половину терминов оттуда заменять на модные сейчас слова типа "GenAI", "мультиагентные систем", "RAG" или "context engineering", то текст будет выглядеть как свежий архитектурный гайд по построению интеллектуальных систем. Дальше я решил понять, а что за авторы написали этот труд и оказалось, что там два автора

• Джеймс Тейлор - один из главных евангелистов decision management: работал в Fair Isaac (FICO), где развивал подход Enterprise Decision Management, а позже стал CEO Decision Management Solutions. Он много лет продвигает идею «делайте решения явными и управляемыми».
• Нил Рэйден - легенда BI/analytics: основатель Hired Brains, практик и аналитик, который умел объяснять, почему «данные есть, инсайты есть, а бизнес всё равно принимает решения “на глазок”».

Книга была хороша в свое время, так как в середине 2000‑х компании уже купили ERP/BPM/BI, построили витрины и дашборды… и внезапно обнаружили, что:

• Процессы автоматизировали, а решения внутри процессов - нет
• Аналитика живёт в презентациях и Excel, а не в runtime
• Правила размазаны по коду/табличкам/головам людей и меняются больно Тейлор и Рэйден попали в нерв: они предложили смотреть на «решение» как на отдельный объект инженерии - как на сервис/компонент, который можно проектировать, тестировать, версионировать, мониторить и улучшать. Не «магический AI», а честная промышленная автоматизация скрытых решений.

Почему и сейчас книга актуальна - потому что многие используют buzzwords для описания желаемого результата вместо того, чтобы описать что именно они хотят. Условно "а тут у нас GenAI сделает все по красоте" или "наша multi-agent система выполнит эту работу сама" или просто "а тут справится AI". Для тех, кто немного понимает в технике такой подход кажется карго-культом. И тут полезно вспомнить про то, о чем рассказывала эта старая книга, а именно про то, что обычно болит в любой интеллектуальной системе:

• Где в продукте спрятаны решения и кто за них отвечает;
• Как отделять decision logic от process orchestration;
• Как сочетать “правила” и “модели” без религиозных войн;
• Как измерять качество решений (а не количество токенов);
• Как обеспечивать согласованность между каналами и командами;
• Как менять логику быстро, но безопасно (управление изменениями, контроль, обратная связь).

Когда читал эту книгу, то составил для себя минисловарик терминов из 2007 года и как они маппятся на термины из 2026 года

• Business rules engine → guardrails / policy engine / “промпт‑конституция”
• Predictive analytics model → ML‑модель / LLM‑модель / routing‑модель
• Decision service → AI‑оркестратор / агент с тулзами / микросервис решения
• Data & analytics → feature store + telemetry + (да‑да) RAG/векторная база
• Adaptive control → online‑эксперименты, bandits, self‑improving пайплайн
• “Make decisions explicit” → «вынесите это из кода/голов в явный артефакт + evals»

Забавно, что в 2007 году авторы специально добавили “(enough)” в название, чтобы отстроиться от тогдашнего "настоящего AI" - мол, нам не нужна эзотерика, нам нужна практическая автоматизация решений. В 2026 мы делаем наоборот: берём те же идеи, добавляем GPU, векторную БД и называем это GenAI.

Итого: технологии крутятся по кругу, а хорошая инженерия - нет. Если вы строите AI‑системы, то вам всё равно придётся:

• Делать решения явными
• Измерять их эффект
• Управлять изменениями
• Обеспечивать контроль и обратную связь

Просто вместо правил/скорингов иногда будет промпт/LLM. 🙂

#AI #Engineering #Software #Management #Leadership #Processes #LLM #ML #Architecture