WEBVTT

00:00:00.260 --> 00:00:03.720
Единственная проверка, которая предотвращает глупые действия у умных агентов.

00:00:03.900 --> 00:00:07.980
Существует один барьер, превращающий ум в компетентность – проверка контракта перед выполнением.

00:00:08.140 --> 00:00:11.520
Прежде чем любой инструмент запустится, валидатор проверяет три вещи в определенном порядке,

00:00:11.700 --> 00:00:15.140
намерение соответствует реальной возможности, у вызывающего пользователя есть разрешение в данный

00:00:15.140 --> 00:00:18.120
момент и запрашиваемый результат осуществим в пределах заявленных границ данных.

00:00:18.240 --> 00:00:21.820
Если какая-либо часть не пройдена, ничего не будет выполнено. Не нужно быть осторожным,

00:00:22.000 --> 00:00:26.220
не нужно пытаться. Отказ с указанием причин и альтернатив. Начнем с соответствия возможностям.

00:00:26.220 --> 00:00:30.480
План гласит обновить элемент списка SharePoint. Валидатор спрашивает, какой инструмент,

00:00:30.760 --> 00:00:35.500
какой метод, какая версия схемы. Аргументы проверяются по реестру. Обязательные поля присутствуют,

00:00:35.640 --> 00:00:39.760
типы правильны, диапазоны значений адекватны, и да, нет лишних полей, добавленных в надежде,

00:00:39.940 --> 00:00:43.720
что кто-то их проигнорирует. Псевдонимы инструментов запрещены. Используйте каноническое имя,

00:00:43.860 --> 00:00:47.020
иначе запрос будет отклонен. Это предотвращает работу инструментов, созданных на основе предположений,

00:00:47.080 --> 00:00:49.680
и использование параметров, полученных методом проб и ошибок, прежде чем они смогут работать

00:00:49.680 --> 00:00:53.900
некорректно. Далее, соответствие политики. Механизм политик оценивает предлагаемый вызов на

00:00:53.900 --> 00:00:58.760
соответствие активной политике. Разрешить списки для инструментов и доменов. Проверки RBC или ABC,

00:00:59.040 --> 00:01:02.820
привязанные к входным идентификационным данным и областям действия. Правила уровня среды.

00:01:02.980 --> 00:01:07.260
Границы классификации данных. Если агент ограничен файлами, чтением для конкретного сайта,

00:01:07.480 --> 00:01:11.380
вызовом обновления или другим сайтом является категорически запрещено. Если полезная нагрузка

00:01:11.380 --> 00:01:15.100
попадает в категорию ограниченной классификации без проверки человеком, это также запрещено.

00:01:15.100 --> 00:01:20.360
Токены проверяются заново. Области действия проверяются на точность, и повышение привилегий

00:01:20.360 --> 00:01:25.420
только один раз рассматривается как попытка взлома. Затем, проверка осуществимости постусловий.

00:01:25.600 --> 00:01:29.280
Недостаточно просто желать результата. Он должен быть достижимым и проверяемым.

00:01:29.420 --> 00:01:33.520
Валидатор спрашивает, поддерживает ли целевая система ключи потенции элементов. Будет ли система

00:01:33.520 --> 00:01:36.500
генерировать надежный идентификатор или электронный тег, который мы сможем проверить позже.

00:01:36.680 --> 00:01:40.560
Есть ли компенсирующие действия в случае сбоя на нежестоящем уровне. Если план не может обеспечить

00:01:40.560 --> 00:01:44.400
проверяемые постусловия, он отклоняется или переписывается. Мы не принимаем, доверьтесь мне,

00:01:44.400 --> 00:01:48.360
я зарегистрирую это позже. Именно позже и происходят инциденты. Соедините все это вместе,

00:01:48.480 --> 00:01:51.240
и вы получите три этапа. Контрольный пункт. Соответствие возможностям. Соблюдение политики.

00:01:51.380 --> 00:01:54.600
Возможность выполнения постусловий. Пройдите все три этапа, и исполнитель продолжит работу.

00:01:54.760 --> 00:01:58.640
Если какой-либо этап не пройден, активируется путь с указанием причины. Этот путь вежливый,

00:01:58.840 --> 00:02:03.060
тщательный и однозначный. Вот что вы пытались сделать. Вот точная политика или схема,

00:02:03.140 --> 00:02:07.200
которую вы нарушили. Вот безопасные альтернативы. Если намерение пользователя можно исправить,

00:02:07.200 --> 00:02:11.140
сусти область действия, переключитесь на сводку только для чтения, направьте на разрешенный сайт.

00:02:11.320 --> 00:02:15.600
Валидатор предлагает соответствующий план и запрашивает одобрение. Если исправить невозможно,

00:02:15.800 --> 00:02:18.780
перейдите к проверке человеком с полным контекстом или остановитесь сразу.

00:02:19.000 --> 00:02:23.360
Никаких загадочных задержек. Никакого тихого успеха. Короткая микроистория, которую вы,

00:02:23.540 --> 00:02:27.360
возможно, уже пережили, даже если не знали об этом. Агенту поручено обобщить все документы отдела

00:02:27.360 --> 00:02:30.520
кадров за последний квартал и отправить их в юридический отдел. Система поиска предлагает

00:02:30.520 --> 00:02:34.580
запросы графа по сайтам отдела кадров и юридического отдела. Валидатор видит пересечение границ.

00:02:34.580 --> 00:02:38.900
Доступ к отделу кадров ограничен. Доступ к юридическому отделу внутренний. Шлюз Трио блокирует

00:02:38.900 --> 00:02:43.060
перекрестное чтение и исходящую электронную почту. Путь запрета возвращается. Обнаружен

00:02:43.060 --> 00:02:46.800
ограниченный контент. Предлагаемая альтернатива — обобщить внутренний индекс политик,

00:02:46.980 --> 00:02:50.260
предоставить ссылку для запроса сводки по персоналу авторизованным рецензентам.

00:02:50.380 --> 00:02:54.300
Пользователь утверждает соответствующий план. Исполнитель запускает его, указывает на внутренний

00:02:54.300 --> 00:02:57.800
контент и прикрепляет запрос на разрешение доступа к материалам по персоналу. Никаких утечек,

00:02:57.800 --> 00:03:02.440
никаких проблем, по-прежнему полезно. Реализация по своей сути скучна. DSL-политик определяет,

00:03:02.560 --> 00:03:06.820
кто что может делать, где и с какими побочными эффектами. Реестр схем хранит контракты инструментов,

00:03:06.980 --> 00:03:11.680
имена, версии, формы аргументов и условия публикации. Резольвер списка разрешенных сопоставляет

00:03:11.680 --> 00:03:16.340
домены, сайты и области действия с уровнями среды. Валидатор составляет их, проставляет отметку о

00:03:16.340 --> 00:03:20.380
каждом решении в журнале аудита, входных данных, оценках политик, результатах и передает

00:03:20.380 --> 00:03:24.840
исполнителю либо зеленый свет, либо план исправления. Исполнитель никогда не обходит красный свет.

00:03:24.840 --> 00:03:28.560
Он обеспечивает выполнение решения или останавливается. Ментальная модель достаточно чиста,

00:03:28.660 --> 00:03:30.940
чтобы ее можно было нанести татуировкой на лоб вашей архитектурной диаграммы.

00:03:31.080 --> 00:03:35.140
Исполнители обеспечивают выполнение. Графы ограничивают. Решения принимают валидаторы.

00:03:35.320 --> 00:03:38.940
Именно в таком порядке. Модель предлагает свои варианты только в пределах огороженного двора,

00:03:39.080 --> 00:03:41.860
и как только она пытается перелезть через него, валидатор останавливает ее,

00:03:42.020 --> 00:03:46.040
объясняет причину и указывает на ворота. Порядок соблюден. Безопасность обеспечена.

00:03:46.180 --> 00:03:50.920
Прогресс не заблокирован. В рамках политики вам нужна была одна вещь, которая предотвратит

00:03:50.920 --> 00:03:54.580
глупые действия у умных агентов. Вот она, предварительная проверка контракта,

00:03:54.740 --> 00:03:58.500
которая доказывает возможности, разрешение и проверяемый результат до любых реальных

00:03:58.500 --> 00:04:03.040
изменений. Она превращает «я думаю, что могу, мне разрешено, я знаю, как, и я могу доказать,

00:04:03.180 --> 00:04:07.940
что я это сделал». Нет-нет-нет, темнота случается не с нами. Теперь у вас есть архитектура,

00:04:08.160 --> 00:04:12.500
используйте ее. Ключевой вывод. Плюс КТ. Ключевой вывод. Подсказки – это мнение,

00:04:12.700 --> 00:04:16.640
исполнители и проверенные графы. Это операции, а предварительная проверка контракта – это

00:04:16.640 --> 00:04:20.860
ограничитель, который заставляет и тех, и других действовать честно. Если это сэкономило вам

00:04:20.860 --> 00:04:25.560
время, верните долготу. Подпишитесь. Далее посмотрите сравнение LandGraph и Microsoft

00:04:25.560 --> 00:04:29.440
агент Framework по производительности и наблюдаемости, фактическим трассировкам,

00:04:29.620 --> 00:04:34.180
затратам и P95. Зафиксируйте свой путь обновления, следуйте инструкциям, включите оповещение и

00:04:34.180 --> 00:04:37.300
получайте следующий эпизод по расписанию. Продолжайте. Большинство людей считают,

00:04:37.460 --> 00:04:41.500
что улучшенные подсказки исправляют нестабильных агентов. Милая теория. Подсказки направляют мысли,

00:04:41.700 --> 00:04:45.820
а не выполняют операции. На самом деле, надежность обеспечивается исполнителями и проверкой

00:04:45.820 --> 00:04:49.720
графов, той опорой, которая не дает агентам упасть лицом вниз, когда реальность дает о себе знать.

00:04:49.840 --> 00:04:53.800
Мы собираемся подключить это к сценариям Microsoft, извлечению графов Microsoft 365,

00:04:54.320 --> 00:04:57.980
рассуждением Azure OpenAI и агентам Copilot Studio, которые не выходят из-под контроля.

00:04:58.160 --> 00:05:03.020
Ставки просты. Точность, задержка, стоимость и возможность аудита. Измеримые,

00:05:03.260 --> 00:05:07.300
а не субъективные ощущения. Я дам вам ментальную модель, которую вы сможете запустить в голове,

00:05:07.440 --> 00:05:11.000
диаграммы в словах, которые вы не забудете, и один этап проверки, который не позволяет умным

00:05:11.000 --> 00:05:15.120
агентам делать глупости. Представляем архитектуру, которую следовало использовать с самого начала.

00:05:15.120 --> 00:05:18.300
Почему подсказки не справляются с операциями, а исполнители нет?

00:05:18.440 --> 00:05:23.500
Итак, вот в чем дело. LLM отвечают за когнитивные процессы. Исполнители отвечают за операции.

00:05:23.740 --> 00:05:28.100
Смешивание этих факторов приводит к хаосу. Модель может предложить план. Она не может

00:05:28.100 --> 00:05:32.160
гарантировать, что электронное письмо было отправлено, файл сохранен или что существовало

00:05:32.160 --> 00:05:37.100
разрешение. Она говорит вероятностями, а операции требуют гарантий. Вступает в игру исполнитель.

00:05:37.240 --> 00:05:41.060
Представьте его как взрослого человека в комнате, управляющего функциями, привязанными к политике,

00:05:41.060 --> 00:05:44.980
с ограничениями состояния и возможностями элементов. Он не верит, что действие прошло

00:05:44.980 --> 00:05:49.180
успешно, он проверяет. Он не предполагает, что инструмент существует. Он проверяет

00:05:49.180 --> 00:05:53.400
возможности, параметры и разрешения, прежде чем даже пытаться выполнить действие. И когда он

00:05:53.400 --> 00:05:57.220
терпит неудачу, он громко заявляет об этом, классифицирует ошибку и выбирает предписанный

00:05:57.220 --> 00:06:01.320
путь восстановления. Большинство агентов, работающих только по запросу, попадают в три режима

00:06:01.320 --> 00:06:06.240
сбоя. Во-первых, галлюцинаторные инструменты. Модель запрашивает функцию, которая не зарегистрирована,

00:06:06.440 --> 00:06:10.780
или вызывает ее с полями, которых не существует. Во-вторых, отсутствие предварительных условий.

00:06:10.780 --> 00:06:14.520
Он пытается редактировать файл SharePoint, не проверяя, может ли он получить доступ к сайту,

00:06:14.700 --> 00:06:18.820
списку или версии элемента. В-третьих, молчаливые частичные ошибки. Второй шаг терпит неудачу,

00:06:18.880 --> 00:06:21.400
но агент продолжает работу и объявляет о победе, потому что текст выглядит уверенно.

00:06:21.540 --> 00:06:24.880
Вы это видели, вы только что назвали это ненадежным. Исполнители запускают цикл,

00:06:24.980 --> 00:06:28.560
который выглядит скучным, и именно поэтому он работает. Предварительные условия, проверка входных

00:06:28.560 --> 00:06:32.180
данных, разрешений и инвариантов. Действия, вызов инструмента с ключом, определяющим потенциал

00:06:32.180 --> 00:06:35.360
элемента, чтобы повторные попытки не приводили к двойному выставлению счетов или двойной отправке

00:06:35.360 --> 00:06:39.740
данных. Постусловие, подтверждение эффектов относительно источника истины. Классификация

00:06:39.740 --> 00:06:44.500
ошибок, это ошибка проверки, временная ошибка, ограничение скорости, ошибка молодости или ошибка

00:06:44.500 --> 00:06:48.180
политики. Восстановление, откат и повторная попытка для временных ошибок, повторная аутентификация

00:06:48.180 --> 00:06:51.400
или повторное согласие для аутентификации, резервные варианты для известных альтернатив и жесткие

00:06:51.400 --> 00:06:54.880
остановки с указанием причин нарушений политики. И демпатентность не подлежит обсуждению.

00:06:54.880 --> 00:06:58.960
Если действие можно повторить, необходим ключ, который делает вторую попытку бездействующей или

00:06:58.960 --> 00:07:02.920
согласованным переопределением. Тайм-ауты предотвращают зомби-вызовы. Откат учитывает

00:07:02.920 --> 00:07:07.780
ограничение скорости. Это детерминированное поведение, управляющее по своей сути стахастической

00:07:07.780 --> 00:07:13.300
генерацией текста. Исполнитель — это коробка передач. LLM — это двигатель. Вы не давите на газ до упора

00:07:13.300 --> 00:07:17.500
и не надеетесь, что колеса поймут. Вывод данных, основанный на контракте, — это противоядие от

00:07:17.500 --> 00:07:22.360
шаблонных абзацев. Модель рассуждения не может вдаваться в подробности. Она выдает JSON, соответствующей

00:07:22.360 --> 00:07:26.520
схеме, имя инструмента, аргументы и ожидаемые постусловия. Валидаторы проверяют соответствие

00:07:26.520 --> 00:07:30.040
схеме перед запуском. Если структура не верна, исполнитель отклоняет запрос с указанием причины,

00:07:30.160 --> 00:07:33.440
запрашивает исправленный план или передает запрос на эскалацию. Так предотвращается превращение

00:07:33.440 --> 00:07:36.960
сложных запросов в производственные инциденты. Теперь вы можете подумать, разве я не могу просто

00:07:36.960 --> 00:07:41.340
попросить модель проверить свою работу? Вы можете спросить. Она ответит, да. Она всегда так делает.

00:07:41.560 --> 00:07:45.700
Средний пользователь это принимает. Профессионалам нужны доказательства. Доказательства хранятся в

00:07:45.700 --> 00:07:50.240
постусловиях, проверенных в таких системах, как Microsoft Graph, SharePoint или Exchange. Это реальные источники

00:07:50.240 --> 00:07:55.360
истины, а не память модели. Но вот где начинается самое интересное. Отдельные шаги — это хорошо. В реальных рабочих

00:07:56.520 --> 00:08:00.140
компенсации и контрольные точки, контролируемые человеком. Вам нужно больше, чем просто исполнитель.

00:08:00.280 --> 00:08:04.260
Вам нужна карта, которую исполнитель сможет прочитать. Это граф рабочих процессов. В графе узлы — это

00:08:04.260 --> 00:08:07.900
задачи или суп-агенты с явно заданными контрактами. Ребра определяют поток управления и поток данных.

00:08:08.060 --> 00:08:12.260
Состояние — первостепенное. Что является постоянным. Что сохраняется в контрольных точках. Что является

00:08:12.260 --> 00:08:16.280
временным. Исполнитель детерминированно обходит граф, соблюдая списки разрешенных действий и схемы на

00:08:16.280 --> 00:08:21.920
каждом ребре. Если узел выходит из строя, граф определяет компенсации, отмену, восстановление или эскалацию.

00:08:21.920 --> 00:08:27.040
Никаких загадочных каналов. И тут происходит волшебство. Это момент, когда надежность меняется.

00:08:27.180 --> 00:08:32.200
ЛЛМ предлагает. Исполнитель обеспечивает соблюдение. Проверка ограничений графа принимает решение.

00:08:32.360 --> 00:08:36.240
Порядок восстановлен. Как только вы отделяете когнитивные процессы от операций, ваши агенты

00:08:36.240 --> 00:08:39.740
перестают импровизировать и начинают действовать. И да, они по-прежнему чувствуют себя умными,

00:08:39.880 --> 00:08:43.820
потому что они таковыми и являются, но теперь они управляются. Готовый шаблон. Давайте подключим

00:08:43.820 --> 00:08:49.280
его к Microsoft 365, не превращая ваш клиент в баффи. Основы графовых рабочих процессов. Узлы,

00:08:49.280 --> 00:08:53.280
ребра и состояние, которое не утекает. Представьте себе это. У вас есть надежный

00:08:53.280 --> 00:08:57.680
исполнитель, но нет карты. Он будет следовать приказам. Но куда? На помощь приходит граф рабочих

00:08:57.680 --> 00:09:01.900
процессов, ваше руководство по эксплуатации. Узлы – это задачи или субагенты с четко определенными

00:09:01.900 --> 00:09:06.280
контрактами. Ребра определяют поток управления и поток данных. Граф кодирует, что выполняется,

00:09:06.440 --> 00:09:10.820
когда выполняется и какие данные могут пересекать границы. Никакой импровизации или джаза.

00:09:10.940 --> 00:09:15.140
Это нотная запись. Начните с формы. Большинство графов производственных процессов представляют

00:09:15.140 --> 00:09:18.740
собой направленные ациклические графы – DG, поскольку циклы приводят к бесконечным

00:09:18.740 --> 00:09:22.840
циклам и искажению состояния. Циклы все еще могут быть, но вы намеренно отмечаете их счетчиками

00:09:22.840 --> 00:09:26.800
и условиями, максимальным количеством итераций, предикатами выхода и таймаутами. Так вы

00:09:26.800 --> 00:09:32.060
предотвращаете превращение «думать усерднее», «думать бесконечно». Условная маршрутизация является

00:09:32.060 --> 00:09:36.380
явной. Если уверенность в получении информации выше порогового значения, переходите к синтезу.

00:09:36.500 --> 00:09:41.140
В противном случае – к повторному запросу. Параллелизм – это первоклассная функция. Запускайте

00:09:41.140 --> 00:09:45.340
суммирование и извлечение цитат параллельно, затем соединяйтесь в узле-барьере, который проверяет,

00:09:45.340 --> 00:09:49.740
что оба процесса выполнили свои постусловия. Состояние – это не атмосфера, это реестр. Вы

00:09:49.740 --> 00:09:53.060
поддерживаете три типа состояния – постоянное состояние, надежные контрольные точки, из которых

00:09:53.060 --> 00:09:56.760
можно восстановиться после сбоя, входные данные, решения, подписанные действия. Эфемерное состояние –

00:09:56.760 --> 00:09:59.760
кратковременные буферы, такие как промежуточные выходные данные модели, которые вы не хотите

00:09:59.760 --> 00:10:03.100
засорять долговременную память. Производное состояние – пересчитываемые артефакты, такие как

00:10:03.100 --> 00:10:07.360
имбединги или отфильтрованные результаты, которые можно построить детерминированно. Правило простое – сохраняйте

00:10:07.360 --> 00:10:11.600
только то, что можно защитить при проверке. Все остальное намеренно выбрасывается. Стратегия

00:10:11.600 --> 00:10:16.220
отката имеет значение. Когда узел изменяет внешний мир, создает события календаря, обновляет

00:10:16.220 --> 00:10:20.660
элемент списка, вы записываете обратное действие, если оно существует, или план компенсации,

00:10:20.820 --> 00:10:25.420
если его нет. Если нежестоящий узел выходит из строя, граф может пройти эти компенсации в обратном

00:10:25.420 --> 00:10:29.160
порядке. Нет, это не излишне, это способ избежать ситуации, когда «ой, дважды забронировал

00:10:29.160 --> 00:10:33.080
генерального директора», превращается в «ой, мы не можем это исправить». Ребра несут в себе контракты.

00:10:33.220 --> 00:10:38.160
Ребро – это не загадочная труба, это апи между узлами. Определите схемы ввода-вывода, типы,

00:10:38.300 --> 00:10:41.500
обязательные поля, допустимые значения. Определите списки разрешенных

00:10:41.600 --> 00:10:45.300
инструментов, к которым может обращаться следующий узел. Определите теги возможностей,

00:10:45.480 --> 00:10:49.700
что принимающий узел обещает сделать, а что откажет. Исполнитель обеспечивает их соблюдение

00:10:49.700 --> 00:10:54.040
во время выполнения. Узел не может переправить токен SharePoint через ребро суммирования. Это не

00:10:54.040 --> 00:10:58.060
показуха безопасности, это способ предотвратить горизонтальное перемещение вашего собственного

00:10:58.060 --> 00:11:03.200
агента. Обработка ошибок происходит в графе, а не в настройках. Каждый узел объявляет свою

00:11:03.200 --> 00:11:08.040
таксономию ошибок, ошибка проверки, временная инфраструктура, ограничение скорости,

00:11:08.040 --> 00:11:13.560
аутентификация, авторизация, нарушение политики и неизвестное. Для каждого класса граф

00:11:13.560 --> 00:11:17.040
предоставляет путь. Повторная попытка с экспоненциальной задержкой для временных ошибок,

00:11:17.140 --> 00:11:20.360
обновление токена для аутентификации, альтернативный инструмент для ограничения скорости,

00:11:20.520 --> 00:11:23.740
отказ с указанием причины для политики. Для неизвестных ошибок существуют очереди

00:11:23.740 --> 00:11:27.240
недоставленных сообщений. Неудачные полезные нагрузки отправляются в карантин с полным

00:11:27.240 --> 00:11:30.540
контекстом, чтобы люди могли их проверить, не воспроизводя хаос в производственной среде.

00:11:30.660 --> 00:11:34.920
Контрольные точки с участием человека — это не случайные сообщения вслег. Они приостанавливают

00:11:34.920 --> 00:11:38.000
выполнение, представляют предлагаемые действия и доказательства, и требуют одобрения или

00:11:38.000 --> 00:11:41.800
редактирования, которое регистрируется и подписывается. После одобрения выполнение возобновляется.

00:11:42.000 --> 00:11:44.700
В случае отказа граф возвращается к безопасному резервному варианту.

00:11:44.800 --> 00:11:47.640
Поздравляем, вы только что внедрили систему контроля изменений, которой разработчики

00:11:47.640 --> 00:11:50.140
действительно будут следовать, потому что это быстрее, чем электронная почта.

00:11:50.260 --> 00:11:54.080
Изоляция памяти не подлежит обсуждению. Каждая сессия получает контекст с ограниченной

00:11:54.080 --> 00:11:57.480
областью действия, только необходимые документы, токены и промежуточные результаты.

00:11:57.700 --> 00:12:01.740
Межсессионное отравление, когда внедрение подсказки из одной беседы проникает в другую,

00:12:01.740 --> 00:12:05.460
это способ случайной утечки данных. Граф обеспечивает соблюдение границ.

00:12:05.600 --> 00:12:09.440
Никакой общеизменяемой памяти, только разрешенное чтение из проверенного хранилища с фильтрами

00:12:09.440 --> 00:12:13.620
контента и валидаторами схем. Да, вы можете кэшировать встраивания и сводки, но вы помечаете их

00:12:13.620 --> 00:12:17.480
происхождением и разрешениями и удаляете при изменении политики. Наблюдаемость встроена,

00:12:17.680 --> 00:12:20.740
а не добавлена. Трассировка на уровне узлов показывает входные и выходные данные,

00:12:20.960 --> 00:12:24.800
длительность, повторные попытки и последующие эффекты. Вы объединяете трассировки в идентификатор запуска

00:12:24.800 --> 00:12:27.520
графа, чтобы иметь возможность воспроизводить, диагностировать и доказывать

00:12:27.520 --> 00:12:31.680
соответствие требованиям. Кто что сделал, когда и почему. Обнаружение аномалий выявляет странные

00:12:31.680 --> 00:12:35.560
закономерности, внезапные всплески вызовов инструментов, необычные домены, разрывы токенов.

00:12:35.620 --> 00:12:38.900
Это ваша система раннего предупреждения, прежде чем интерес перерастет в инцидент.

00:12:39.020 --> 00:12:43.900
По сути, граф — это конституция. Исполнитель — это правоохранительные органы. Магистр права — это

00:12:43.900 --> 00:12:47.940
адвокат, а не судья. Когда вы кодируете узлы, ребра и состояние таким образом, вы получаете не просто

00:12:47.940 --> 00:12:51.640
рабочие процессы, которые успешно завершаются. Вы получаете рабочие процессы, которые безопасно

00:12:51.640 --> 00:12:53.980
завершаются с ошибкой, объясняют себя и предсказуемо восстанавливаются.

00:12:53.980 --> 00:12:58.980
Теперь, имея на руках план, мы можем подключиться к Microsoft 365, не превращая ваш клиент в шведский

00:12:58.980 --> 00:13:03.840
стол. Безопасность по умолчанию. Проверка графа превосходит хаос-инженерию. Вы не доказываете

00:13:03.840 --> 00:13:07.720
надежность, бросая хаос в производственную среду и надеясь, что выжившие окажутся устойчивыми.

00:13:07.840 --> 00:13:10.860
Вы доказываете ее, отклоняя небезопасные рабочие процессы еще до того, как они начнут

00:13:10.860 --> 00:13:14.160
выполняться. Это и есть проверка графа. Статические проверки, чтобы исключить бессмыслицу,

00:13:14.280 --> 00:13:17.000
и механизмы контроля во время выполнения, чтобы держать опасность в рамках. Статическая

00:13:17.000 --> 00:13:20.640
валидация — это предполетная проверка. Вы проверяете структуру перед запуском. Циклы,

00:13:20.740 --> 00:13:24.240
создающие неограниченные циклы, отклоняются или требуют объявления защитных механизмов

00:13:24.240 --> 00:13:29.160
итерации. Недоступные узлы, мертвый код — это удаление или оправдание. Отсутствующие контракты,

00:13:29.380 --> 00:13:33.680
каждый узел должен объявить схемы ввода и вывода, необходимые возможности и побочные эффекты.

00:13:33.820 --> 00:13:38.100
Границы привилегий. Узлы, изменяющие внешние системы, должны работать в сегментах с учетными

00:13:38.100 --> 00:13:42.460
данными с минимальными привилегиями и явными списками разрешенных запросов. И да, если ваш узел

00:13:42.460 --> 00:13:46.760
суммирование, внезапно запросит доступ на запись в SharePoint, валидатор безоговорочно откажет.

00:13:46.840 --> 00:13:50.960
Теперь о времени выполнения. Вот здесь люди допускают небрежность. Механизм политик

00:13:50.960 --> 00:13:55.260
находится рядом с исполнителем, а не позади него. Списки разрешенных инструментов и доменов — это

00:13:55.260 --> 00:13:59.020
не документация, это принятые решения. Во время вызова механизм проверяет нас или нас на

00:13:59.020 --> 00:14:02.560
соответствие активному субъекту, внутрисистемному токену-идентификатору, областям действия,

00:14:02.660 --> 00:14:06.700
утверждением и корректно распространяет данные по всей цепочке. Никаких скрытых сверхспособностей.

00:14:06.800 --> 00:14:09.920
Токены имеют ограниченную область действия, обновляются при наличии разрешения и никогда не

00:14:09.920 --> 00:14:13.440
передаются через дружественные узлы. Агент получает доступ при каждом вызове, иначе он не будет

00:14:13.440 --> 00:14:18.400
вызывать. Санитаризация входных и выходных данных — это гигиена, а не опция. Внедрение подсказок — это

00:14:18.400 --> 00:14:22.820
не хитрость, а предсказуемость. Каждый входящий источник контента проходит через фильтры контента,

00:14:23.000 --> 00:14:27.580
HTML-код, средства очистки Markdown и BrandMauer инструкций, которые удаляют ненужные данные.

00:14:27.780 --> 00:14:34.140
Выходные данные проходят через валидаторы схем. Если узел обещал JSON, исполнитель отклоняет текст и запрашивает

00:14:34.140 --> 00:14:38.900
исправление. Модель может возражать — валидатор не ведет переговоры. Он обеспечивает соблюдение

00:14:38.900 --> 00:14:43.460
типов, диапазонов и инвариантов. Песочница и сегментация ограничивают радиус поражения.

00:14:43.640 --> 00:14:48.140
Узлы, которые вызывают внешний код или ненадежные коннекторы, работают в ограниченных средах.

00:14:48.260 --> 00:14:52.200
Апишлюзы с ограничениями скорости и сетевыми политиками, которые предотвращают горизонтальное

00:14:52.200 --> 00:14:56.320
перемещение и средствами контроля исходящего трафика, которые разрешают трафик только к проверенным

00:14:56.320 --> 00:15:00.800
доменам. Вы не позволяете узлу получения обнаруживать новый источник данных в производственной среде.

00:15:00.960 --> 00:15:04.800
Обнаружение происходит в среде разработки за тестами с подписанными обновлениями списка разрешенных

00:15:04.800 --> 00:15:08.820
источников. Наблюдаемость не регистрируется где-либо, она точечная. Трассировка на уровне узлов

00:15:08.820 --> 00:15:11.840
записывает входные и выходные данные, продолжительность, повторные попытки и решения,

00:15:12.000 --> 00:15:15.260
принимаемые механизмом политик. Все данные сопоставляются по идентификатору запуска.

00:15:15.460 --> 00:15:19.520
Журналы аудита неизменяемы и содержат информацию о том, какой субъект санкционировал какое действие,

00:15:19.640 --> 00:15:23.300
в каких областях, в какое время и почему политика это разрешила. Когда регулятор спрашивает,

00:15:23.300 --> 00:15:26.900
кто что сделал, вы не пожимаете плечами, а ищете. Готовность к соответствию означает,

00:15:27.080 --> 00:15:30.100
что ваши доказательства скучны и полны. Риски, связанные с патчами и третьими сторонами,

00:15:30.200 --> 00:15:33.420
это проблемы цепочки поставок. Относитесь к ним соответственно. Сканирование зависимости

00:15:33.420 --> 00:15:37.180
выполняется при каждой сборке. Коннекторы и плагины проверяются, фиксируются версии и проверяются

00:15:37.180 --> 00:15:41.080
на предмет расширения прав доступа. Если вы импортируете спецификацию MCP или открытого API,

00:15:41.240 --> 00:15:44.500
вы проверяете, соответствуют ли объявленные методы политики минимальных привилегий,

00:15:44.600 --> 00:15:47.560
которую вы ожидаете. Никаких конечных точек с подстановочными знаками,

00:15:47.560 --> 00:15:51.900
никаких скрытых путей записи, притворяющихся путями чтения. Гигиена — это не гламурно,

00:15:52.040 --> 00:15:56.140
однако именно ради нее вы спите. Проверка истинности графа превосходит хаос-инженерию,

00:15:56.320 --> 00:16:00.040
потому что она предотвращает целые классы инцидентов, а не документирует их последствия.

00:16:00.180 --> 00:16:02.920
Вы по-прежнему тестируете режимы отказов, но делаете это для подтверждения защитных

00:16:02.920 --> 00:16:05.260
механизмов, а не для того, чтобы обнаружить, что забыли их установить.

00:16:05.360 --> 00:16:08.560
Давайте вернемся к ментальной модели. Статические проверки поддерживают

00:16:08.560 --> 00:16:12.320
работоспособность чертежей. Никаких невозможных путей, никакой осиротевшей работы,

00:16:12.320 --> 00:16:15.560
никаких утечек привилегий. Защитные механизмы во время выполнения поддерживают

00:16:15.560 --> 00:16:19.880
работоспособность поведения. Каждый вызов аутентифицирован, авторизован, очищен и отслеживается.

00:16:20.100 --> 00:16:23.480
Исполнитель обеспечивает соблюдение ограничений графа, установленных валидатором.

00:16:23.640 --> 00:16:27.440
Модель. Она предлагает в рамках заданных границ и обрезается, когда отклоняется от них.

00:16:27.620 --> 00:16:31.160
Разве это не тяжело? Только если вам нравятся нарушения. Накладные расходы

00:16:31.160 --> 00:16:34.940
механические и автоматизированные. Статическая проверка выполняется во время сборки и

00:16:34.940 --> 00:16:38.480
развертывания. Политика во время выполнения – это вспомогательный механизм, быстрый и локальный.

00:16:38.480 --> 00:16:42.540
Проверки схемы занимают миллисекунды. Стоимость, которую вы устраняете, инциденты,

00:16:42.700 --> 00:16:46.140
ручные проверки, доработки, затмевает микрозадержку, которую вы добавляете.

00:16:46.140 --> 00:16:51.140
И отдача измерима. Меньше несанкционированных вызовов, меньше сбоев токенов и гораздо

00:16:51.140 --> 00:16:53.820
меньше посмертных разборов причин произошедшего.

00:16:54.060 --> 00:16:58.940
Еще один момент, который упускает из виду обычный пользователь. Валидация является компонуемой.

00:16:59.080 --> 00:17:02.560
Вы можете обернуть сторонние инструменты прокси-узлами, которые обеспечивают соблюдение

00:17:02.560 --> 00:17:06.400
контрактов и политик, не доверяя самому инструменту. Вы можете сегментировать графы по уровню

00:17:06.400 --> 00:17:10.220
конфиденциальности, общедоступности, внутреннему доступу, ограниченному доступу и продвигать рабочие

00:17:10.220 --> 00:17:14.080
процессы между уровнями только после прохождения валидации для новой границы. Вот как вы безопасно

00:17:14.080 --> 00:17:17.900
масштабируетесь. Безопасность по умолчанию — это не лозунг, это свойство рабочего процесса.

00:17:18.000 --> 00:17:21.660
Вы не надеетесь, что агенты будут вести себя правильно. Вы делаете некорректное поведение

00:17:21.660 --> 00:17:25.060
структурно-трудновыводимым и оперативно-видимым. При наличии необходимых ресурсов,

00:17:25.120 --> 00:17:30.160
подключение Microsoft 365 Graph и Azure OpenAI — это не рулетка. Это контролируемая власть на ваших

00:17:30.160 --> 00:17:33.540
условиях. Теперь мы можем говорить о подключении, а не о тушении пожаров.

00:17:33.700 --> 00:17:38.700
Сценарий Microsoft M365 Graph плюс Azure OpenAI плюс Copilot Studio.

00:17:38.700 --> 00:17:42.740
Давайте соберем состав участников. Агент поиска — дисциплинированный библиотекарь,

00:17:42.840 --> 00:17:46.080
который извлекает данные из Microsoft Graph только с минимальными привилегиями.

00:17:46.220 --> 00:17:50.940
Агент рассуждений — модель Azure OpenAI, которая планирует, размещает сайты и никогда не выходит

00:17:50.940 --> 00:17:54.400
за рамки своих задач. Исполнитель — оператор, привязанный к политикам,

00:17:54.580 --> 00:17:58.040
который запускает инструменты с одимпатентностью и проверками постусловий.

00:17:58.220 --> 00:18:02.000
Валидатор — контролер, схема, политика и обеспечение границ.

00:18:02.140 --> 00:18:05.200
Охранник политики — вспомогательный компонент среды выполнения, который связывает

00:18:05.200 --> 00:18:09.400
все с областями действия IntraID и RBC. Вместе они ведут себя как компетентная команда,

00:18:09.640 --> 00:18:12.600
а не как комитет. Доступ к данным начинается с граф, а не с догадок.

00:18:12.720 --> 00:18:15.720
Агент поиска хранит регистрацию приложения с детализированными областями действия.

00:18:15.840 --> 00:18:19.900
Файлы — чтение для конкретного сайта. Почта — чтение для ограниченного почтового ящика.

00:18:20.060 --> 00:18:23.740
Календари — чтение для календаря ресурсов. Никаких героических операций чтения,

00:18:23.980 --> 00:18:27.640
записи граф. Запросы используют дельта и выборочные поля для минимизации полезной нагрузки.

00:18:27.800 --> 00:18:31.000
Постраничная навигация — первоклассная. Исполнитель детерминированно следует

00:18:31.000 --> 00:18:34.420
по ссылкам с таймаутами, соблюдая ограничение скорости обслуживания. Когда возникают ошибки

00:18:34.420 --> 00:18:38.880
429, отступление происходит математически. Никаких истерик, только экспоненциальное терпение.

00:18:39.100 --> 00:18:42.780
Заземление — это не просто ощущение, это конвейер. Получение документов кандидатов с помощью

00:18:42.780 --> 00:18:46.860
поиска по графу или запросов к спискам. Дедупликация по идентификатору элемента и ETG-версии,

00:18:47.060 --> 00:18:50.320
чтобы не смешивать устаревшие и актуальные данные. Разбивка на фрагменты по семантическим

00:18:50.320 --> 00:18:54.480
границам, заголовкам разделов, разрывам слайдов. Затем прикрепление происхождения диска, сайта,

00:18:54.480 --> 00:18:58.860
пути, идентификатора элемента, последнего изменения и назначенного хиша. Агент логического вывода

00:18:58.860 --> 00:19:02.640
видит только фрагменты плюс метаденные и обязан выводить цитаты, сопоставленные с этими

00:19:02.640 --> 00:19:07.460
идентификаторами. Нет цитаты, нет утверждения. Исполнитель обеспечивает это как постусловие перед

00:19:07.460 --> 00:19:11.540
любым внешним действием. Для оркестрации используется Капайлот Студия. Вы определяете

00:19:11.540 --> 00:19:15.400
декларативные инструменты, пакеты запросов граф, действия записи SharePoint, публикации Teams,

00:19:15.580 --> 00:19:19.400
отправки Outlook, каждый из которых находится за прокси-сервером с явными схемами и списками разрешений.

00:19:19.400 --> 00:19:23.600
Координация между агентами структурирована. Агент извлечения предоставляет инструмент

00:19:23.600 --> 00:19:28.480
заземления. Агент рассуждений запрашивает его с параметрами. Исполнитель выступает посредником,

00:19:28.700 --> 00:19:32.720
проверяет и возвращает обоснованный контекст. Контрольные точки, заполняемые человеком,

00:19:32.900 --> 00:19:36.240
являются встроенными. Предлагаемый узел действия приостанавливает выполнение,

00:19:36.500 --> 00:19:40.740
отображает план с цитатами и требует одобрения. Одобрение подписывается и регистрируется.

00:19:40.940 --> 00:19:45.180
Отказ направляет к безопасной альтернативе или эскалации. Токены и задержка управляются,

00:19:45.180 --> 00:19:49.140
а не игнорируются. Выборочный контекст означает, что вы передаете только релевантные

00:19:49.140 --> 00:19:52.780
фрагменты, а не весь ваш клиент. Сводки предварительно вычисляются и кэшируются с помощью

00:19:52.780 --> 00:19:56.300
имбидингов, ключами которых являются хэш-контента и разрешения. Измените документ,

00:19:56.480 --> 00:20:00.380
измените ключ, пропустите кэш, пересетайте. Потоковые ответы поддерживают работоспособность

00:20:00.380 --> 00:20:03.260
пользовательского интерфейса, пока исполнитель обрабатывает побочные эффекты только после

00:20:03.260 --> 00:20:06.480
получения полного плана с действительной схемой. Условия раннего выхода останавливают цикл

00:20:06.480 --> 00:20:09.400
рассуждений, когда уровень уверенности и покрытия достигает порогового значения.

00:20:09.600 --> 00:20:13.480
Никакого дополнительного мышления, потому что модель показалась поэтичной. Возможность аудита

00:20:13.480 --> 00:20:17.300
заложена изначально. Каждое действие подписывается субъектом службы или делегированным

00:20:17.300 --> 00:20:20.920
пользователем и помечается идентификатором запуска, инструментом, параметрами. При

00:20:20.920 --> 00:20:24.900
необходимости скрывает информацию областью действия и результатом. Неизменяемые журналы

00:20:24.900 --> 00:20:28.660
хранятся в вашей системе мониторинга. Выберите свой любимый. Таким образом, вы можете

00:20:28.660 --> 00:20:32.440
воспроизвести запуск без повторного выполнения побочных эффектов. Кто что сделал, когда и почему,

00:20:32.600 --> 00:20:36.560
это вопрос, а не охота на ведьм. И да, ссылки сохраняются в неизменном виде, поэтому вы можете

00:20:36.560 --> 00:20:39.940
убедиться, что ответ связан с фактическим содержимым арендатора, а не с типовым законом.

00:20:39.940 --> 00:20:44.420
Сбои нормализованы и скучны. При ошибках 429 исполнитель повторяет попытку с задержкой,

00:20:44.520 --> 00:20:47.460
затем переключается на запрос с меньшей стоимостью или уменьшенным размером страницы.

00:20:47.580 --> 00:20:51.520
При устаревшем кэше валидатор обнаруживает несоответствующий и тагас и принудительно обновляет

00:20:51.520 --> 00:20:54.520
кэш. При отказе в доступе система защиты политики отказывает с указанием причины,

00:20:54.620 --> 00:20:57.880
предлагает путь запроса согласия или направляет запрос к скрытому резюме, который не приводит к

00:20:57.880 --> 00:21:02.000
утечке информации. При сбое инструмента граф объявляет альтернативные варианты или помещает запуск в

00:21:02.000 --> 00:21:05.960
очередь недоставленных сообщений с полным контекстом для исправления человеком. Детерминированные

00:21:05.960 --> 00:21:10.060
резервные варианты превращают инцидент в заявку. Теперь краткий обзор. Пользователь

00:21:10.060 --> 00:21:14.160
спрашивает. Составьте краткое изложение решений по дорожной карте за последний квартал со ссылками.

00:21:14.360 --> 00:21:17.760
Агент, выполняющий логическое мышление, предлагает используйте поиск по графу на определенном

00:21:17.760 --> 00:21:21.180
сайте SharePoint и в канале Teams, отфильтруйте по последнему кварталу, а затем синтезируйте.

00:21:21.300 --> 00:21:24.800
Валидатор проверяет, соответствуют ли запрошенные области действия роли агента.

00:21:25.100 --> 00:21:28.160
Соответствует. Исполнитель отправляет вызовы графа с постраничной навигацией и выбором полей,

00:21:28.160 --> 00:21:31.340
удаляет дубликаты по идентификатору элемента, фрагментирует данные и возвращает контекст с указанием

00:21:31.340 --> 00:21:34.480
происхождения. Логическое мышление создает краткое изложение с встроенными ссылками,

00:21:34.640 --> 00:21:38.260
сопоставленными с идентификаторами элементов. Валидатор проверяет схему и ссылки. Проверка

00:21:38.260 --> 00:21:41.760
пройдена успешно. Появляется контрольная точка с кратким изложением и подтверждением.

00:21:42.040 --> 00:21:45.500
Утверждающий нажимает ОК. Исполнитель публикует результат в Teams и отправляет электронные письма

00:21:45.500 --> 00:21:47.800
заинтересованным сторонам. Каждое действие использует ключи значимости элементов,

00:21:47.940 --> 00:21:50.860
чтобы повторные попытки не приводили к двойной отправке. Обратите внимание на дисциплину.

00:21:50.860 --> 00:21:54.360
Ни один агент не изобретает инструмент. Ни один узел не пересекает домен за пределами своего

00:21:54.360 --> 00:21:58.900
разрешенного списка. Токены корректно определяются и передаются через интро-ID. Они копируются

00:21:58.900 --> 00:22:03.320
и вставляются между узлами. Модель никогда не делает вывод об успехе. Исполнитель доказывает

00:22:03.320 --> 00:22:07.220
это условиями POST запроса к графу. Создано ID-сообщение, обновлен ITG элемента,

00:22:07.420 --> 00:22:11.120
ID-события календаря. Затем ставится отметка о завершении выполнения. И да, вы можете безопасно

00:22:11.120 --> 00:22:15.340
расширить это, подключив планер, Vivo или сторонние сервисы через MCP или открытый API, но только за

00:22:15.340 --> 00:22:19.320
прокси-инструментами со строгими схемами и контролем исходящего сетевого трафика. Оберните каждый

00:22:19.320 --> 00:22:23.240
коннектор одной и той же логикой валидатора и защитой политик. Переход между средами требует

00:22:23.240 --> 00:22:27.300
проходов валидации, соответствующих новым границам. От разработки к тестированию и продакшену с

00:22:27.300 --> 00:22:31.280
учетом расширения области действия, а не предположения. Это архитектура Microsoft, реализованная

00:22:31.280 --> 00:22:37.260
правильно. Граф для истины, Azure OpenAI для размышлений, Copilot Studio для оркестрации, исполнители для

00:22:37.260 --> 00:22:42.840
операций, валидаторы и политики для безопасности, а также наблюдаемость для доказательств. Далее цифры,

00:22:42.840 --> 00:22:48.460
а не впечатления. Метрики, да и, после, точность, задержка, стоимость, административные издержки.

00:22:48.640 --> 00:22:53.780
Хорошая архитектура, докажите это. Цифры, а не впечатления. Агенты, работающие только с подсказками,

00:22:53.980 --> 00:22:58.260
настоящие драматизаторы. Точность не постоянно, потому что они выдумывают источники и забывают

00:22:58.260 --> 00:23:03.340
ссылки. Без обоснования получается уверенная проза, которая никуда не ведет. Задержка в конце цепочки

00:23:03.340 --> 00:23:07.860
звонков ужасна. Одна длинная цепочка звонков, требующих более глубокого анализа, каждый из которых

00:23:07.860 --> 00:23:11.920
раздут избыточным контекстом. Затраты растут по спирали, потому что каждый раз в модель отправляются

00:23:11.920 --> 00:23:15.460
полные стенограммы и необработанные документы, как переплаченная курьерская служба.

00:23:15.860 --> 00:23:20.540
Административные издержки. Высокие. Инциденты. Экстренные исправления. Загадочные сбои и аудиты,

00:23:20.680 --> 00:23:24.540
которые напоминают археологию с завязанными глазами. Теперь о состоянии после с исполнителями

00:23:24.540 --> 00:23:28.440
и проверенными графами. Точность повышается, потому что для обработки заявок требуются квитанции.

00:23:28.600 --> 00:23:32.360
Обоснованные ссылки, привязанные к идентификаторам элементов графа, электронным тягам и подписанным

00:23:32.360 --> 00:23:35.660
хешем, означают, что ответ без подтверждения происхождения просто не проходит проверку.

00:23:35.660 --> 00:23:39.840
Эффект мгновенный. Меньше неправильных ответов, меньше циклов доработки и измеримое повышение

00:23:39.840 --> 00:23:43.440
показателей успешности выполнения задач в оценочных наборах. Когда утверждение не может быть

00:23:43.440 --> 00:23:46.940
подтверждено, агент отклоняет его с указанием причин или запрашивает одобрение человека.

00:23:47.220 --> 00:23:52.020
Предсказуемо. Доступно для проверки. Безопасно. Задержка сокращается по трем причинам. Во-первых,

00:23:52.200 --> 00:23:55.600
параллелизм, поиск, переранжирование и извлечение цитирований выполняются параллельно,

00:23:55.760 --> 00:23:59.260
а затем синхронизируются на узле-барьере. Во-вторых, кэширование, встраивание и сводки,

00:23:59.260 --> 00:24:02.640
основанные на хаешае контента и области разрешений, позволяют избежать пересчета того,

00:24:02.800 --> 00:24:06.260
что не изменилось. В-третьих, ранний выход. Как только охват и уверенность достигают

00:24:06.260 --> 00:24:09.780
порогового значения, граф останавливает цикл. Сравните это с последовательным запросом,

00:24:09.880 --> 00:24:13.040
где модель обдумывает решение на протяжении абзаца, а ваши пользователи обдумывают свой выход.

00:24:13.180 --> 00:24:15.660
Стоимость снижается, потому что дисциплина использования токенов обеспечивается,

00:24:15.780 --> 00:24:19.260
а не выпрашивается. Выходные данные, ограниченные схемой, предотвращают бессвязность.

00:24:19.460 --> 00:24:23.480
Выборочный контекст передает метаданные только релевантным фрагментам, а не целым сайтам.

00:24:23.480 --> 00:24:28.120
Более короткие запросы, меньшие ответы, меньше повторных попыток. Эффективность элементов и логика

00:24:28.120 --> 00:24:31.880
задержки исполнителя позволяют избежать дублирующих вызовов и лишних циклов. В результате

00:24:31.880 --> 00:24:35.060
получается меньше токенов на успешный результат и значительно меньшая вариативность.

00:24:35.200 --> 00:24:38.760
Финансовый отдел предпочитает сокращение отклонений. Административные издержки уменьшаются,

00:24:38.900 --> 00:24:42.220
потому что наблюдаемость проектируется, а не импровизируется. Трассировка на уровне узлов и

00:24:42.220 --> 00:24:46.280
неизменяемые журналы сокращают время диагностики инцидентов. Вы видите, какой узел вышел из строя,

00:24:46.460 --> 00:24:49.480
почему механизм политик отклонил запрос и что исполнитель попытался сделать дальше.

00:24:49.480 --> 00:24:53.820
Повторяемые развертывания сокращают объем работы на моем компьютере. Соответствие требованиям

00:24:53.820 --> 00:24:57.260
перестает быть сезонным кризисом, потому что каждый запуск уже содержит информацию о том,

00:24:57.360 --> 00:25:00.800
кто, что, когда и почему. Давайте сделаем это конкретным с помощью измерительной системы,

00:25:00.860 --> 00:25:04.260
которую вы действительно можете запустить. Создайте набор репрезентативных задач для оценки,

00:25:04.420 --> 00:25:07.980
вопросы и ответы со ссылками, сводку со ссылками и предложения по действиям с утверждениями.

00:25:08.080 --> 00:25:12.320
Для каждого определите оптимальные ответы или критерии приемлемости. Исправьте факты с помощью

00:25:12.320 --> 00:25:15.780
сопоставленных идентификаторов элементов, покрытия ссылок и допустимого отклонения.

00:25:15.780 --> 00:25:20.440
Установите параметры SLO P50 и P95, сквозная задержка, расход токенов на успешно выполненную

00:25:20.440 --> 00:25:23.620
задачу и процент отклонений политик. Свяжите каждую метрику с трассировками,

00:25:23.840 --> 00:25:26.860
чтобы любая регрессия имела след. Результаты, которые вы должны ожидать,

00:25:27.040 --> 00:25:29.200
если будете следовать архитектуре, а не импровизировать ее.

00:25:29.340 --> 00:25:32.580
Более высокая достоверность ответов, поскольку неподтвержденные утверждения никогда не

00:25:32.580 --> 00:25:37.240
покидают тестовую среду. Более низкая задержка P95, поскольку длинные хвосты обрезаются

00:25:37.240 --> 00:25:41.460
параллельными узлами и ранними выходами. Меньше затрат токенов, поскольку вы перестаете отправлять

00:25:41.460 --> 00:25:45.280
длинные тексты и начинаете отправлять релевантные фрагменты. Меньше страниц для администраторов,

00:25:45.440 --> 00:25:48.700
поскольку большинство сбоев обрабатываются детерминированными резервными механизмами.

00:25:48.820 --> 00:25:53.040
И да, скучный показатель, о котором все забывают. Коэффициент успешного завершения с первого раза

00:25:53.040 --> 00:25:56.560
больше запусков завершается без вмешательства человека. Влияние на бизнес, более быстрое решение

00:25:56.560 --> 00:25:59.720
проблем означает, что пользователи перестают открывать дублирующие заявки. Предсказуемые затраты

00:25:59.720 --> 00:26:03.240
означают планирование бюджета без неожиданных последствий в виде затрат токенов. Уверенность в соответствии

00:26:03.240 --> 00:26:07.560
означает меньше циклов аудита, которые могут сорвать ваш план действий. Неочевидная выгода – это

00:26:07.560 --> 00:26:12.020
репутационный аспект. Когда ответы агента ссылаются на контент арендатора, и ссылки работают,

00:26:12.220 --> 00:26:16.600
люди доверяют этому, используют это и перестают пересылать скриншоты, начинающиеся с вопроса,

00:26:16.680 --> 00:26:20.980
почему там было написано это. Прямые, императивные рекомендации, отслеживание связи с метриками,

00:26:20.980 --> 00:26:24.840
иначе вы будете полагаться на собственное мнение. Если вы не можете открыть запись выполнения и точно

00:26:24.840 --> 00:26:28.440
увидеть, какой именно узел завысил количество токенов или вызвал задержку, у вас нет наблюдаемости,

00:26:28.540 --> 00:26:32.600
у вас есть лишь предположения, основанные на временных метках. Все меняется, когда валидатор находится

00:26:32.600 --> 00:26:37.320
между хорошим планом и реальными действиями. Точность стабилизируется, задержка сокращается,

00:26:37.620 --> 00:26:41.480
стоимость выравнивается, администраторы спят. Это не магия, это исполнители,

00:26:41.720 --> 00:26:45.900
графы и валидация выполняют работу, которую вы ошибочно назначили запросом.