Transcription
Хорошо, выключите это. Итак, цель этого, э, цель этого мероприятия сегодня, этой лабораторной сессии, заключается в том, чтобы пройти через некоторые аспекты того, как сделать чат-ботов более детерминированными, и я имею в виду, что запрос к чат-боту должен всегда давать одинаковые ответы. Итак, мы, как архитекторы, одно из того, что мы делаем, это создаем наше управление, создаем стандарты и пытаемся обеспечить соблюдение этих стандартов для нашего управления. Так что один из стандартов, который мы, вероятно, создадим во время нашей сессии, это стандарт для проверки API. Мы хотим проверить контракт API. Стандарт Open API, и мы хотим убедиться, что они следуют нашему стандарту API, реализованному командой архитекторов. Это может касаться некоторых вопросов, которые мы хотим рассмотреть: безопасно ли это? Правильно? Реализуют ли они аутентификацию на правильном уровне? Возвращают ли они правильный контент для правильного HTTP-глагола? Соответствует ли это ожидаемой структуре? И как мы можем сделать это более автоматизированным, чтобы им не приходилось, чтобы они могли самостоятельно проверять это, и когда они придут на рассмотрение архитектурным советом, они придут подготовленными и будут знать, чего ожидать, но, что более важно, это сэкономит им время, когда они смогут фактически продвигаться вперед с тем, что они реализовали, но реальный фокус сегодня будет на том, как использовать что-то вроде чат-бота для этого, но прежде чем мы даже приступим к этому, есть один вопрос, который я хотел бы задать: могут ли LLM уже проектировать API? Итак, LLM могут проектировать API, генерировать архитектурные диаграммы, писать код Terraform. Нет никакого сценария. Какова именно роль архитектора через три года? Я не говорю, что, хорошо, есть другие вещи, люди будут углубляться в технические детали и говорить: «О, академики не просто занимаются дизайном и стандартами API и тому подобным», но если LLM может сделать большую часть этого с точки зрения, вы знаете, дизайна, диаграмм, документации и Terraform, так какова роль архитектора через 3 года? Я хотел бы увидеть, если вы можете написать в комментариях или если вы хотите высказаться сейчас, если вы поднимете руку, я проведу разговор, потому что, как я уже упоминал, это очень интерактивно, очень практично, и было бы хорошо провести некоторую беседу. Хорошо, хорошо, так что сегодня я буду призывать всех использовать ChatGPT или что-то еще, что вы хотите использовать, но разница, которую нам нужно изучить, — это разница между случайным промптингом и архитектурным AI. Итак, когда архитектор использует код или ChatGPT, это не то же самое, что просто вводить любые случайные вещи. Архитектор, как я уже упоминал ранее, работает со стандартами или управлением, хочет внедрить стандарты, хочет обеспечить соблюдение стандартов. Поэтому, работая с такими вещами, как ChatGPT или Claude, мы хотим убедиться, что они могут, мы можем автоматизировать задачи, которые мы выполняем. Так что, если мы просто хотим проверить, соответствует ли API стандарту, это задача, которую мы можем автоматизировать с помощью генеративного AI, и ChatGPT — хороший пример для этого. Я надеюсь, что вы все меня слышите. Итак, чтобы установить некоторые ожидания, это практическое занятие, и вы будете создавать компонент управляемого AI. Не до самого кода, так что не волнуйтесь, кодирования не будет, но мы постараемся избежать всей воды, мы хотим перейти прямо к делу и посмотреть, что мы можем сделать, что мы можем построить. И для этой сессии мы будем использовать что-то, к чему мы все привыкли как архитекторы. Мы знаем, что мы смотрим на обзоры спецификаций, мы хотим убедиться, что любой новый API, который вводится в среду, соответствует стандарту, реализованному стандарту, который был обеспечен через архитектурный обзор. Но как мы можем остановить любые архитектурные нарушения? Единственный способ, которым мы сейчас это делаем, — это просматривать дизайн или просматривать то, что предоставлено командой разработки. И мы начнем с чего-то очень, очень простого. Я создал файл, и этот файл — очень простой пример спецификации Open API, и многие из вас, архитекторов, уже очень хорошо с ним знакомы. Вы обычно получаете что-то вроде этого от вашей команды разработки, и мы говорим: «Хорошо, у нас есть некоторые новые события, у нас есть, и это очень просто, как я уже упоминал, это очень простой случай, когда мы ищем конечную точку регистрации для некоторых событий». Так что, возможно, ваша организация организует какие-то мероприятия, внутренние мероприятия, внешние мероприятия, где вам требуется регистрация участника. Итак, у нас есть бесплатный основной раздел здесь: события, регистрация, повестка дня, и, как вы можете видеть, у нас есть некоторые гости, а также некоторые POST-запросы для создания нового зарегистрированного человека, регистрации новых участников, и мы также можем получить повестку дня. Итак, вы привыкнете к этому, вы обычно получаете это, и ведущий разработчик придет с некоторыми дополнительными диаграммами. Я постараюсь показать диаграммы того, что они делают точно, но мы не хотим, чтобы архитектурный обзор превращался в обзор диаграмм, и мы не хотим тратить столько времени на наш стандарт, который мы уже установили за последние 6 месяцев, если только стандарт не был обновлен, тогда имеет смысл прийти и попытаться пересмотреть все остальное, но нам нужно дать команде возможность проводить собственный обзор, и теперь, если они действительно отклоняются от чего-либо, прежде чем выйти в эфир, это будет обсуждаться с архитекторами и представлено правильно, но нам нужно убедиться, что мы даем им возможность и силу двигаться быстро и быть очень гибкими, без того, чтобы команда архитекторов была препятствием. Итак, принимая это во внимание, мы обсуждаем некоторые соглашения об именовании. Итак, мы хотим, чтобы все конечные точки были множественными именами существительных. Хорошо, и если вы хотите получить одно событие, вы хотите предоставить идентификатор, потому что это то, что здесь предоставлено. Итак, давайте попробуем просмотреть эту спецификацию. Итак, обычно мы будем делать следующее: мы скопируем это и перейдем к, давайте используем ChatGPT. Хорошо, мы в ChatGPT, и мы хотим, чтобы ChatGPT мог просмотреть эту спецификацию для нас. Итак, обычно мы говорим: «Хорошо, мы хотим, чтобы вы просмотрели эту спецификацию». Итак, скажем, мы хотим, чтобы вы просмотрели эту спецификацию Open API на основе лучших практик. Итак, я вставлю спецификацию, и я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, я, *Я* не могу видеть чат. Хорошо, так что у нас есть вопрос от Руфа. Хорошо. Какую модель оркестрации вы рекомендуете для координации нескольких агентов в продакшене: централизованный контроллер, событийно-ориентированная архитектура? Мы хотим вернуться к этому, потому что это уведет нас от промптинга в архитектуре AI. Как структурировать операцию между слоями, потоками API, рабочими процессами и аудитом? Мы собираемся обсудить это через секунду, как автоматизировать весь рабочий процесс, потому что то, что мы делаем, если мы можем промптить это, мы можем создать сервис, мы можем создать микросервис, который фактически будет обрабатывать это для нас, где разработчик может просто предоставить спецификацию API Open API, и этот микросервис вернет этот JSON, этот JSON-результат. Итак, это некоторые из вопросов, которые у нас есть. Теперь, если кто-нибудь хочет что-то сказать, я могу включить микрофон и хорошо, просто позвольте мне вернуться к, извините, я на секунду потерял экран. Одна вещь, которую я хотел обсудить, потому что у нас уже есть этот промпт, промпт сейчас, и в промпте уже есть, я хотел обсудить ограничения, по сути, как мы останавливаем, как мы останавливаем модель от фабрикации стандартов, мы много это обсуждали, и что, если она интерпретирует политику, так что это две очень важные вещи для обсуждения, два очень важных вопроса. Итак, первое: что, если модель фабрикует стандарты, и что, если предприятие неверно интерпретирует эти политики, которые мы предоставляем? Итак, чтобы остановить фабрикацию стандартов, мы ввели стандарт явно в контекст. Итак, мы предоставили стандарт, так что очень простой стандарт: не изобретайте никаких стандартов, используйте стандарт, который я предоставляю, и это стандарт, который мы предоставили до сих пор, мы убедились, что он следует стандарту, не выходит за рамки этого, и в отношении, мы также убедились, что это очень важно, у нас есть номер версии для стандарта, очень важно версионировать ваш стандарт, потому что вы хотите вернуться и сказать: «Хорошо, эта спецификация Open API была проверена на соответствие стандарту архитектуры версии 1.3», если стандарт изменится, потому что вы добавили или удалили некоторые правила, так что вы добавили или удалили некоторые правила, вы также хотите, возможно, повторно проверить эти API или API функций, которые не предоставляют версионирование, например, вы удалили версионирование версии 1, так что строка строки 1 и новый входящий API не имеют версии. Мы не знаем точно, по какому стандартному архитектурному стандарту они были проверены. Итак, в этом случае версия 1.4. Хорошо. Так что очень важно версионировать этот стандарт. Теперь, если мы хотим, что-то еще, что я хочу добавить, версия дает нам регулируемость, мы только что упоминали ранее, что если мы удаляем некоторые правила или добавляем правила, мы хотим знать, какая версия стандарта добавила эти правила. Так что это отслеживаемость, мы можем вернуться к этой версии и посмотреть, что было добавлено. Мы можем даже посмотреть предыдущую версию и сравнить. Это то, что мы можем сделать, это то, что мы можем сделать как часть внутреннего обзора архитектуры, а затем это передается всем, и архитектурный стандарт должен быть проверен, зарегистрирован где-то и проверен. Так что, если мы можем сохранить его в каком-нибудь сервисе или каком-нибудь сервисном аудите, который хранит все версии и отслеживает, когда происходят какие-либо изменения и как эти изменения происходят. Это часть управления. Как мы меняем, как мы обновляем версии? Теперь команда архитекторов может сосредоточиться на этом. Хорошо. Итак, еще одна вещь, которую я хотел быстро сделать, если я перейду на страницу draw.io, страница загружается, секунду. Хорошо. Итак, одна вещь, которую мы хотим сделать, это превратить этот промпт в компонент, мы обсуждали это ранее, и мы хотим превратить его в компонент. Итак, очень просто, у нас есть клиент, и у клиента, вероятно, будет API-шлюз. Мы разберемся с этим. И то, что мы хотим сделать сейчас, это превратить этот процесс обзора в компонент. И этот компонент может называться, например, наш сервис обзора AI. Сервис обзора AI, где мы будем подключаться к LLM, это может быть ChatGPT. Итак, когда у нас есть это, мы переходим к обзору. Итак, мы пройдемся по нему через секунду. Итак, у нас есть валидатор, а затем у нас есть вывод, который является ответом. Итак, что происходит, это то, что разработчик работает на этом уровне. Итак, разработчик отправит спецификацию Open API, спецификацию Open API в API-шлюз. У нас есть наши сервисы, работающие на бэкэнде API-шлюза здесь, и сервисы обзора AI, мы берем эту спецификацию Open API и подключаемся к LLM. Теперь, что произойдет, что мы уже обсуждали ранее, когда мы делали промптинг. Итак, этот промпт будет введен в LLM вместе со спецификацией Open API, а затем, когда LLM и спецификация Open API вернутся с ответом, мы запустим валидатор. Итак, валидатор убедится, что сначала мы получим JSON-вывод, и мы точно знаем, что такое вывод от LLM. Убедившись, что LLM не изобрела никаких стандартов и не отклонилась, и следовала ограничениям, затем ответ будет возвращен клиенту в JSON. Теперь другая вещь, которую мы также можем увидеть, это то, что LLM не бесплатны. Итак, есть стоимость, каждый раз, когда вы делаете запрос к LLM, вам нужно платить за эти запросы. И потому что, если клиент продолжает отправлять одну и ту же спецификацию API, и мы знаем эту спецификацию API, мы также можем применять некоторое кэширование. Итак, стратегии кэширования могут основываться на нескольких факторах. Итак, это может быть, хорошо, не было изменений между предыдущей спецификацией, которую отправил разработчик, и новой. Следовательно, очень детерминировано, что будет тот же ответ, если не будет изменений в спецификации API. И, например, разработчик решает запускать команду сборки, CI/CD, несколько раз без внесения в нее изменений, нет смысла нам начинать смотреть на вызов LLM, потому что есть стоимость токенов, связанная с этим. Если ответ уже есть, мы кэшируем ответ и возвращаем его клиенту. Итак, здесь мы превращаем промпт в компонент системы, который они могут использовать в любом качестве части CI/CD для любой системы, которую они строят. Теперь команда архитекторов приближается к фактической доставке, к стороне кода. Другая вещь, которую мы также получаем, имея API-шлюз, это то, что мы можем получить такие вещи, как повторные попытки, мы можем получить логику повторных попыток, мы можем реализовать некоторую масштабируемость и все остальное, что нам нужно сделать. Итак, даже кэширование применяется, если команда разработки совместно использует код, и они еще не объединили код новых исправлений, которые были применены в спецификации Open API, и другой разработчик пытается запустить проверку, тогда лучше иметь кэширование, чем снова интегрировать LLM. Итак, верните кэшированный ответ в этом случае и представьте его разработчику. Итак, это очень важно. Теперь, если мы посмотрим на то, что я хотел сделать, я не уверен, есть ли у нас достаточно времени, чтобы вы могли поделиться своими собственными промптами. Вы можете, если вы посмотрите на первоначальный промпт и, возможно, если я вставлю его в чат, вы можете попытаться улучшить его по-своему, или если у вас есть какие-либо вопросы по промптингу, спрашивайте, я постараюсь помочь вам перейти от плохого промпта к промпту уровня архитектора. Итак, просто выводы из этой сессии, выводы из этой сессии, на самом деле, прежде чем перейти к выводам, я просто хочу вернуться к одной из диаграмм. Итак, это диаграмма, которую я сделал ранее о том, как вы можете фактически реализовать детерминированную систему в вашей команде. Итак, корпоративное управление — это то, где находятся архитектурные органы. У нас есть репозиторий стандартов. У нас есть шаблоны промптов. Архитекторы собираются вместе и создают эти стандарты, работают со всеми различными командами. Убедитесь, что команда доставки осведомлена о стандартах. Команда доставки также может вносить свой вклад, если один из стандартов нуждается в изменении или должен быть принят, убедитесь, что стандарт актуален для того, как они также работают, но архитектурный совет будет рассматривать стандарт, утверждать новые стандарты, утверждать стандарты и иметь репозиторий для всех стандартов. Вы также создадите библиотеку шаблонов промптов и будете хранить эти шаблоны промптов, потому что эти шаблоны промптов будут загружены в систему, которая фактически будет плоскостью выполнения. Итак, если вы посмотрите на плоскость корпоративного управления, где обычно живут другие архитекторы. Здесь создаются стандарты. Здесь создаются шаблоны для промптов, и здесь они также хранятся для аудита, они будут загружены в эту службу, которая находится вокруг плоскости выполнения AI, созданной, конечно, с помощью команды доставки, и эта плоскость выполнения AI — это то место, где у нас фактически будет LLM. Итак, мы будем вводить правила, мы будем вводить шаблоны, и эти правила и шаблоны будут использоваться движком LLM. Теперь, в этой диаграмме у меня была температура 0.0. Так что эта температура — это то, что LLM действительно используют. Если вы используете LLM через API, вы больше не находитесь в веб-приложении ChatGPT или в настольном приложении. Вы фактически взаимодействуете с ChatGPT или Code или Deep через API. И один из способов убедиться, что их ответы очень детерминированы, — это изменить температуру. Чем выше число, так что это 0.0, чем выше число, тем больше галлюцинаций будет добавлено к выводу, тем более креативным будет пытаться быть движок LLM. Так что, если вы хотите быть детерминированным, установите его на 0.0. Так что температура ноль позволит избежать детерминированности. Но это также означает, что он не будет таким креативным, как некоторые другие системы, которые требуют. Но как архитектор, мы не хотим этой креативности. Мы хотим, чтобы он применял стандарт, следовал стандарту, так что установите температуру на 0.0. И для доверия, как вы можете видеть из плоскости выполнения, мы хотим убедиться, что все, что мы делаем, регистрируется в журнале аудита. Мы знаем, что если поступает новый запрос для выполнения некоторой проверки, мы снова регистрируем это в журнале аудита. Какая бы версия шаблона у нас ни была, или какая бы версия стандарта у нас ни была, также должна быть зарегистрирована в журнале аудита. Так что все аудируется. Это очень важно, чтобы, когда вас аудирует сторонняя организация, вы могли показать им точно, как вы фактически проверили, как были обеспечены архитектурные стандарты и как система, которая была развернута, фактически следует этому стандарту. Итак, снова валидатор схемы, чтобы убедиться, что схема, генерируемая LLM, соответствует тому, что мы указали, и любые нарушения, они хранятся, и мы также можем генерировать отчеты, и это поможет команде архитекторов стать более проактивной и стать более поддерживающей организацией для команды доставки. С этим на месте у нас есть команда доставки. Итак, разработчик работает над своим новым конечным пунктом, возможно, платежным API. У него уже есть контракт. Используя спецификацию Open API, а затем он отправляет эту новую спецификацию в сборщик промптов, который вернет ответ в течение нескольких секунд, миллисекунд. Итак, хорошо, Open API, которую вы предоставили, фактически соответствует тому, что архитекторы уже обсуждали внутри архитектурного совета, и нет никаких проблем, она была одобрена, так что это автоматическое одобрение нового дизайна API, и есть аудиторский след. Так что, если в будущем возникнут какие-либо вопросы относительно спецификации, мы всегда можем вернуться к журналу аудита, и мы точно знаем, что это была за спецификация, какая спецификация Open API была проверена, когда она была проверена и когда она была проверена, так что у нас есть отслеживаемость. И мы можем, потому что мы также помним предыдущую диаграмму, где перед ней был API-шлюз, поэтому мы точно знаем, кто ее запустил и когда она была запущена. Так что это то, что я хотел обсудить, прежде чем мы перейдем к чему-то, что фактически мы коснулись, определение роли, определение области действия, структурированный вывод, контракт, инъекция контекста, мы также коснулись версионирования стандарта, ограничений, постобработки, валидации и наблюдаемости. Итак, это то, что мы называем микросервисом управления LLM. Ну, это теперь архитектура как услуга, и с архитектурой как услугой команда будет гораздо более гибкой. Они будут гораздо более эффективными, и они смогут предоставлять гораздо больше стандартизированных функций гораздо быстрее, и это улучшит не только затраты, но и время выхода на рынок. Это также уменьшит технический долг и приблизит команду архитекторов к команде доставки и разрушит эту «башню из слоновой кости». Итак, если у вас есть эта система, один из вопросов, который я задам: «Вы доверяете этому?» Вы доверяете этому, чтобы убедиться, что все, что было отправлено разработчиком, соответствует стандарту. Вы доверяете этому? И я верю, что да. Я верю, что вы доверяете этому, потому что система следует стандартам, которые вы установили. И, знаете, один из вопросов: как мы обрабатываем исключения, потому что система здесь будет автоматически проверять, и мы упомянули, что вы отклоняетесь от фактического стандарта. Как мы упоминаем исключения? Потому что у нас есть валидатор, который вернет сбой. Мы можем видеть исключение. Мы можем видеть журнал аудита. У нас есть хранилище валидации, которое также хранится, и мы можем иметь отчет, но хотим ли мы, чтобы это было полностью автоматизировано, чтобы разработчик не взаимодействовал ни с одним архитектором, потому что это уже автоматизировано через систему, или мы хотим, чтобы человек был вовлечен, или мы должны сказать, что архитектор вовлечен, чтобы обрабатывать исключения? Я думаю, что это то, что архитектурный совет должен будет обсудить, и исходя из их собственных требований, требуется ли человек или автоматизация лучше. Хорошо. Итак, мы подходим к концу сессии. Я надеюсь, что вам всем понравилось, и если есть какие-либо вопросы, пожалуйста, дайте мне знать. У нас есть сессия два, которая начинается на следующей неделе. Мы снова отправим приглашения, мы разместим ссылку в чате. Итак, что мы сделали сегодня, это то, что мы спроектировали один компонент AI. Это компонент AI, который мы обсуждали, мы спроектировали его через лучший промптинг, убедились, что промпт структурирован, мы предоставили контекст, мы предоставили роли, мы предоставили наши стандарты, мы предоставили, как должен выглядеть вывод, и на основе всего этого мы также обсудили, как автоматизировать это, чтобы сделать его более проактивным для фактического разработчика, чтобы он мог автоматизировать это как часть их собственного рабочего процесса. Итак, это автоматизированный рабочий процесс обзора архитектуры. И его можно запускать где угодно. Итак, спасибо, что присоединились к нам, и сессия два, второе мероприятие будет посвящено тому, как архитекторы используют AI для проектирования систем в три раза быстрее, не теряя контроля. Итак, это будет немного похоже на кодирование для архитекторов, или мы должны назвать это архитектурой? Я не уверен. Давайте возьмем кодирование сейчас. Итак, кодирование для архитекторов будет сессией два, и я надеюсь увидеть вас всех там. Спасибо всем. Есть ли вопросы? У нас есть что-нибудь, что вы хотите добавить, мистер Мухаммад? Нет, если нет, спасибо всем. Пока-пока.