04 — Архитектура управляемого ИИ-контура — читательская версия

PDF — страница 44

4. Архитектура управляемого ИИ-контура

04

После определения природы задачи можно переходить к архитектуре решения.

PDF — страница 45

Архитектура управляемого ИИ-контура

• Цель

• Обучение Контекст

• Память Метод
• Человек

• QA Правила

• Исполнение

• Схема по тексту: Глава 4. Геометрия показывает связи и последовательность, а не количественные значения.

[!note] Редакторское пояснение схемы; визуальная сверка A1 Это пояснение редактора, не дополнительный текст авторов PDF. Текстовые подписи выше сохранены в порядке технического извлечения; связи описаны ниже.

В центре красный прямоугольник «Человек». Восемь внешних блоков соединены с центром радиальными линиями. Если читать по часовой стрелке от верхнего блока: цель, контекст, метод, правила, исполнение, QA, память, обучение. Цель также красная; остальные внешние блоки светлые на тёмном фоне.

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

PDF — страница 46

На этом этапе возникает новый риск: принять набор подключённых инструментов за работающую систему. Компания выбирает языковую модель, добавляет поиск по документам, создаёт нескольких агентов, подключает корпоративные сервисы и объявляет ИИ-контур построенным.

Но технологическая связанность ещё не означает управляемость.

Чтобы искусственный интеллект стал частью операционной системы компании, необходимо согласовать несколько разных слоёв:

• цель и ограничения;

• корпоративный контекст;

• методы и правила;

• механизмы исполнения;

• полномочия человека;

• контроль качества;

• фиксацию результата;

• обучение на ошибках.

Если хотя бы один слой отсутствует, система либо не может выполнить задачу, либо начинает самостоятельно заполнять пробелы. Второй вариант обычно опаснее первого: результат выглядит убедительно, хотя построен на неподтверждённых допущениях.

Поэтому архитектура управляемого ИИ-контура должна отвечать не только на вопрос «что умеет система?», но и на вопросы:

• почему она выбрала именно это действие;

• какие знания и правила использовала;

• где заканчиваются её полномочия;

• кто проверяет результат;

• что произойдёт при ошибке;

• как исправление изменит дальнейшую работу.

PDF — страница 47

4.1. Почему чат с моделью ещё не является рабочей системой

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

Но такой результат трудно воспроизвести.

Он зависит от:

• формулировки запроса;

• того, какие сведения пользователь вспомнил;

• порядка сообщений;

• способности человека распознать ошибку;

• накопленного в конкретном диалоге контекста;

• текущего поведения выбранной модели.

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

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

Такой контур должен обеспечивать:

1. воспроизводимый доступ к актуальному контексту;

2. применение утверждённого метода;

3. соблюдение правил и ограничений;

4. передачу задачи подходящему механизму;

5. контроль промежуточных и итоговых результатов;

6. фиксацию действий и оснований;

7. обновление системы после обнаружения дефекта.

Именно этот переход — от диалога к управляемому рабочему процессу — отличает индивидуальное использование ИИ от организационного внедрения.

PDF — страница 48

4.2. Harness: управляющая оболочка

Центральным элементом архитектуры является Harness — управляющая оболочка, внутри которой модель получает контекст, правила, инструменты и доступ к рабочей среде.

Harness не следует отождествлять с конкретным продуктом. Им может быть среда, способная:

• обращаться к корпоративным файлам и системам;

• применять локальные инструкции;

• вызывать внешние инструменты;

• запускать навыки и агентов;

• читать и создавать рабочие артефакты;

• поддерживать длительный контекст проекта;

• сохранять историю действий;

• выполнять проверки;

• запрашивать подтверждение человека.

Ценность Harness состоит не в интерфейсе. Он связывает корпоративную методологию с возможностями моделей.

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

При этом Harness не должен превращаться в ещё один технологический монолит. Желательно сохранять переносимость:

• знания не должны существовать только внутри одного продукта;

• правила должны храниться в доступном для версионирования формате;

• навыки должны быть отделены от конкретной модели;

• данные должны оставаться в контролируемых корпоративных источниках;

• критические действия не должны зависеть от единственного внешнего сервиса.

Модели и интерфейсы будут меняться. Корпоративная методология должна переживать эти изменения.

4.3. Контекст: что система должна знать перед действием

Контекст — это не вся информация, которой располагает компания. Это минимально достаточный набор сведений, необходимый для правильного выполнения конкретной задачи.

Попытка загружать в каждую сессию весь корпоративный массив создаёт три проблемы:

• растёт информационный шум;

• повышается риск использования нерелевантного или устаревшего материала;

• увеличивается вероятность раскрытия данных, к которым исполнитель не должен иметь доступа.

Поэтому контекст необходимо собирать слоями.

PDF — страница 49

Стратегический контекст Он отвечает на вопросы:

• какого результата добивается компания;

• какие приоритеты действуют сейчас;

• какие ограничения нельзя нарушать;

• на какие метрики должна повлиять задача;

• какие долгосрочные риски необходимо учитывать.

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

Контекст функции и процесса В него входят:

• цель процесса;

• его место в цепочке создания результата;

• входы и выходы;

• участники;

• обязательные этапы;

• критерии завершения;

• правила эскалации;

• известные исключения.

Этот слой объясняет машине, что происходит до и после выполняемой операции.

Проектный контекст Он содержит:

• паспорт проекта;

• поставленную задачу;

• принятые решения;

• действующие гипотезы;

• созданные артефакты;

• ограничения;

• открытые вопросы;

• историю изменений.

Проектный контекст позволяет не восстанавливать ситуацию заново в каждой сессии.

PDF — страница 50

Ролевой контекст Система должна понимать:

• кто инициировал действие;

• какую роль человек занимает;

• какие у него полномочия;

• какие данные ему доступны;

• какие решения он может принимать;

• когда требуется согласование.

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

Контекст метода Он включает:

• используемые модели;

• определения;

• последовательность рассуждения;

• критерии выбора;

• требования к доказательствам;

• типичные ошибки;

• стандарты результата.

Именно этот слой превращает универсальную модель в исполнителя корпоративного способа работы.

Ситуативный контекст Это информация, относящаяся к текущему случаю:

• конкретные данные;

• запрос клиента;

• транскрипт встречи;

• документ;

• набор показателей;

• описание инцидента;

• новое внешнее событие.

Ситуативный контекст постоянно меняется. Остальные слои задают способ его интерпретации.

PDF — страница 51

Контекст имеет несколько уровней

• 01 Стратегический контекст

• 02 Контекст функции и процесса

• 03 Проектный контекст

• 04 Ролевой контекст

• 05 Контекст метода

• 06 Ситуативный контекст

• Схема по тексту: Глава 4. Геометрия показывает связи и последовательность, а не количественные значения.

[!note] Редакторское пояснение схемы; визуальная сверка A1 Это пояснение редактора, не дополнительный текст авторов PDF. Текстовые подписи выше сохранены в порядке технического извлечения; связи описаны ниже.

Шесть полос: 01 стратегический контекст; 02 контекст функции и процесса; 03 проектный контекст; 04 ролевой контекст; 05 контекст метода; 06 ситуативный контекст. Последняя красная; полосы сдвигаются вправо. Основание: §4.3, с. 48–50.

Слово «уровни» здесь обозначает слои релевантной информации. Это не лестница зрелости. Не всем операциям требуется весь стратегический контекст; сам текст источника ограничивает состав минимально достаточным.

PDF — страница 52

4.4. Правила: границы допустимого поведения

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

Например:

• не использовать непроверенные числовые данные как факты;

• указывать источник каждого внешнего утверждения;

• не передавать клиентские данные во внешние сервисы;

• не изменять утверждённый документ без разрешения владельца;

• не переходить к следующему этапу до прохождения проверки;

• не принимать необратимое решение без подтверждения человека;

• использовать действующую версию методологии;

• сохранять результат в установленном месте.

Правила могут относиться к разным уровням:

• всей организации;

• функции;

• подразделению;

• проекту;

• роли;

• конкретному навыку;

• отдельной задаче.

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

Без иерархии контекста ИИ либо выбирает правило самостоятельно, либо пытается совместить несовместимые требования.

Управляемая система должна:

• хранить правила в явном виде;

• определять область их действия;

• указывать владельца;

• фиксировать версию;

• обнаруживать противоречия;

• объяснять применённое ограничение;

• останавливаться при неразрешимом конфликте.

PDF — страница 53

4.5. Навыки: воспроизводимые способы выполнения функций

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

Он должен отвечать на вопросы:

• когда его следует применять;

• какая задача входит в его область;

• какие данные необходимы;

• какой метод используется;

• какие шаги нужно выполнить;

• где требуется проверка;

• в каком формате вернуть результат;

• при каких условиях остановиться;

• какие действия запрещены.

Примеры навыков:

• обработка входящего письма;

• извлечение решений из транскрипта встречи;

• проверка финансовой модели;

• подготовка коммерческого предложения;

• аудит проекта;

• поиск незавершённых циклов;

• анализ причин отклонения показателя;

• подготовка исследовательского задания;

• проверка презентации по стандарту качества.

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

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

PDF — страница 54

4.6. Агенты: ограниченные исполнители

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

Но полезная агентность начинается с ограничения.

Агенту необходимо определить:

• конкретную цель;

• доступные действия;

• разрешённые источники;

• лимиты времени и ресурсов;

• критерии завершения;

• условия остановки;

• запрещённые действия;

• порядок эскалации;

• способ проверки.

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

Гораздо надёжнее распределить работу:

• один агент собирает факты;

• второй проверяет источники;

• третий контролирует полноту;

• четвёртый ищет внутренние противоречия;

• человек интерпретирует результат и принимает решение.

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

Основной принцип:

Агенту следует передавать не неопределённую ответственность, а ограниченную функцию внутри процесса, ответственность за который остаётся у человека.

PDF — страница 55

4.7. Модели: формализованные способы интерпретации

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

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

• формулу;

• набор факторов;

• правила расчёта;

• систему весов;

• ограничения;

• диапазон применимости;

• способ интерпретации.

Модель делает рассуждение проверяемым.

Руководитель может не согласиться с итоговым решением, но должен понимать:

• какие данные использовались;

• как они преобразовались;

• какие допущения были сделаны;

• какой фактор оказал решающее влияние;

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

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

PDF — страница 56

4.8. Scaffolds: когнитивные опоры

Не всякую экспертную работу можно превратить в последовательность правил. В задачах с несколькими допустимыми ответами полезнее поддержать мышление человека.

Scaffold — это временная или постоянная конструкция, которая помогает сотруднику рассуждать в заданной профессиональной рамке.

Им может быть:

• дерево вопросов;

• карта факторов;

• набор альтернативных объяснений;

• последовательность проверки гипотез;

• перечень обязательных перспектив;

• границы допустимого решения;

• сценарная модель;

• шаблон профессионального разбора;

• предупреждение о типичных когнитивных ошибках.

Scaffold не говорит человеку, какое решение принять. Он повышает вероятность того, что решение будет принято с учётом необходимой информации и в соответствии с корпоративным способом мышления.

В этом состоит его отличие от инструкции.

Инструкция уменьшает вариативность исполнения. Scaffold сохраняет вариативность решения, но повышает качество рассуждения.

PDF — страница 57

4.9. Микросервисы: интерфейсы для повторяемого применения

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

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

Например:

• форма подбора аналога товара;

• калькулятор экономического эффекта;

• сервис проверки документа;

• интерфейс расчёта производственной загрузки;

• конструктор технического решения;

• подготовка карточки клиента;

• классификатор рекламаций;

• проверка проекта перед запуском.

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

Такой подход позволяет не переписывать основные корпоративные системы. Узкие решения создаются рядом с CRM, ERP, системой управления задачами или базой знаний и взаимодействуют с ними через доступные интерфейсы.

Микросервис особенно оправдан, если:

• функция повторяется;

• стандарт результата устойчив;

• круг пользователей широк;

• работа через общий чат создаёт ошибки;

• необходимо ограничить доступ;

• требуется журналирование;

• важна единая версия метода.

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

PDF — страница 58

4.10. QA: независимая проверка результата

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

Система сформировала расчёт и сама заявила, что он корректен. Агент нашёл данные и сам подтвердил надёжность источников. Модель написала документ и самостоятельно оценила его полноту.

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

Поэтому контроль качества должен включать разные типы проверки:

• формальную — соблюдены ли обязательные требования;

• логическую — нет ли противоречий;

• источниковую — подтверждены ли факты;

• методологическую — правильно ли применён метод;

• содержательную — достаточен ли результат для решения;

• человеческую — допустимо ли использовать результат в конкретной ситуации.

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

PDF — страница 59

4.11. Rail: проверка движения по принятой методологии

Rail — это механизм, который сопоставляет фактическое состояние работы с установленным процессом.

Он отвечает не на вопрос «хорош ли результат вообще», а на более конкретные вопросы:

• правильно ли инициирован проект;

• собраны ли обязательные артефакты;

• определён ли владелец;

• установлены ли критерии результата;

• закрыт ли необходимый контекст;

• проведены ли обязательные проверки;

• не пропущен ли этап;

• не началась ли содержательная работа раньше управленческой;

• соответствует ли текущее действие полномочиям участника.

Результатом Rail является статус:

• на рельсе;

• отклонение;

• критический разрыв;

• недостаточно данных для проверки.

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

Особенно важно версионирование Rail. Проверка должна показывать, по какой версии процесса она была проведена. Иначе невозможно понять, почему два пользователя получили разные результаты или на каком этапе возник дефект.

PDF — страница 60

4.12. Meditate: превращение исправлений в обучение

Работа с ИИ почти всегда начинается с многократных человеческих корректировок.

Пользователь объясняет:

• это рассуждение неверно;

• этот источник недостаточен;

• такой вывод не следует из данных;

• этот формат неприемлем;

• это действие запрещено;

• в такой ситуации нужно остановиться;

• этот фактор имеет более высокий приоритет.

Если исправления остаются внутри одного диалога, организация платит за одну и ту же ошибку многократно.

Meditate — это механизм анализа сессии или инцидента, который выделяет повторяемые корректировки и предлагает превратить их в:

• новое правило;

• уточнение навыка;

• дополнительную проверку;

• исключение;

• изменение приоритета;

• новый вопрос;

• ограничение полномочий.

Не каждое замечание должно автоматически становиться правилом. Человек мог исправить систему ситуативно или ошибиться сам. Поэтому изменение проходит проверку, получает владельца и фиксируется как новая версия.

4.13. Полный рабочий цикл

В собранном виде архитектура выглядит так.

До начала работы

• определена стратегическая цель;

• найдено ограничение;

• выделена функция;

• установлен тип задачи;

• выбран метод;

• назначен владелец;

• определены метрики и риски.

PDF — страница 61

При запуске

• Harness собирает релевантный контекст;

• проверяет роль и полномочия;

• выбирает применимый навык;

• определяет доступные инструменты;

• устанавливает точки человеческого подтверждения.

Во время исполнения

• агент или модель выполняет ограниченную функцию;

• промежуточные результаты проходят проверки;

• неопределённость и исключения передаются человеку;

• значимые действия журналируются.

Перед завершением

• QA проверяет качество результата;

• Rail проверяет соблюдение процесса;

• человек принимает решение там, где это предусмотрено;

• результат сохраняется в корпоративной памяти.

После завершения

• измеряется процессный и экономический эффект;

• фиксируются ошибки и вмешательства;

• Meditate предлагает изменения;

• ответственный утверждает новую версию;

• обновление распространяется на пользователей.

Именно замыкание последнего этапа превращает набор инструментов в самообучающуюся организационную систему.

PDF — страница 62

4.14. Безопасность как часть архитектуры

Безопасность нельзя добавлять после запуска.

Для каждого компонента необходимо определить:

• какие данные он может читать;

• какие данные может изменять;

• какие сведения допускается передавать внешней модели;

• какие действия требуют подтверждения;

• где хранится журнал;

• как отзывается доступ;

• как маскируются клиентские данные;

• как проверяется новый навык;

• как восстанавливается предыдущая версия;

• кто отвечает за инцидент.

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

Поэтому публикация навыка должна проходить как минимум:

• методологическую проверку;

• проверку полномочий;

• проверку утечек;

• проверку внешних вызовов;

• тестирование на ограниченном наборе случаев;

• утверждение владельцем.

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

PDF — страница 63

4.15. Минимальная жизнеспособная архитектура

Для первого проекта не требуется строить всю систему сразу.

Минимальный управляемый контур может состоять из семи элементов:

1. Одна значимая функция.

2. Утверждённый метод её выполнения.

3. Ограниченный набор контекста.

4. Один воспроизводимый навык.

5. Явная точка человеческого решения.

6. Независимая проверка результата.

7. Реестр ошибок и изменений.

Если такой контур стабильно работает, к нему можно добавлять:

• автоматические источники данных;

• агентов;

• дополнительные проверки;

• микросервисный интерфейс;

• мониторинг;

• распространение навыка;

• автоматическое обновление версий.

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

Узкий контур даёт возможность увидеть, где именно возникает эффект и где система ошибается.

Вывод

Управляемый ИИ-контур — это не модель, не корпоративный чат и не набор агентов.

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

Harness соединяет элементы. Контекст сообщает системе, в какой организации и задаче она действует. Правила устанавливают границы. Навыки воспроизводят функции. Агенты выполняют ограниченные последовательности действий. Модели формализуют анализ. Scaffolds поддерживают человеческое мышление. Микросервисы делают способности доступными пользователям. QA проверяет результат. Rail контролирует соблюдение процесса. Meditate превращает исправления в новые версии правил.

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

Такой цикл описывает связка CORD+PDCA.