Transcription
[музыка] >> Отлично. Эм, спасибо, что присоединились к моей сессии. >> [аплодисменты] >> Спасибо, друг. Э, я Сэнди. Э, я технический руководитель, э, по данным и ИИ в Databricks. Э, до работы в Databricks я работал в Amazon Web Services, э, в течение 5 лет в качестве главного архитектора по данным и ИИ. Э, за последние несколько лет я активно занимался построением и масштабированием платформ данных и ИИ с использованием распределенных систем и технологий. А за последние пару лет, в частности, я работал с клиентами, пытаясь понять, что мы можем сделать с этой новой технологией ИИ. Э, когда я говорю "новый ИИ", ИИ существует уже давно, но мы все начали экспериментировать довольно экспоненциально, э, за последние пару лет, верно? И я извлек большой урок из создания демонстраций и того, как перевести эти демонстрации в продакшн, работая с различными клиентами в, э, B2B программных индустриях, а затем, э, в регулируемых индустриях, таких как финансовые, э, услуги. Итак, в этой сессии я хочу поделиться руководством, фреймворком, который я составил на основе уроков, которые я извлек, работая "в окопах", э, который вы можете взять и применить, когда будете думать о том, как вывести ваши ИИ-системы в продакшн. И я думаю, что эта сессия удачно расположена во второй половине дня, потому что то, что вы можете сделать сейчас, в этом фреймворке, это вписать различные, э, знания, знания, которые вы собрали, посещая эти различные сессии в течение дня, и увидеть, где они вписываются в каждый из этих, знаете ли, элементов фреймворка. Итак, когда я начинал 2 года назад, это был паттерн, который я заметил в каждом разговоре с клиентом, верно? Итак, каждый хотел что-то сделать с ИИ. Э, было огромное давление сверху что-то сделать, создать демонстрацию. И каждый разговор начинался с "давайте выберем модель", верно? И это ничья вина, потому что рынок был таким. Мы говорили о моделях, модели были для нас новой технологией, верно? И каждый разговор начинался: "Использовать ли нам GPT? Использовать ли нам Claude?". Знаете, были огромные дебаты внутри организаций. Затем вы выбирали модель, создавали некоторые функции, решали, какие функции создать для этого приложения. Э, вы создавали это в контролируемой среде, с предсказуемыми наборами данных, знаете, э, ограниченными сценариями, и тогда это выглядело отлично как демонстрация, и тогда руководство было довольно, они утверждали это, и они помещали это в среду, в производственную среду. Затем, через несколько недель, люди начинали задавать вопросы: "Что, черт возьми, делает ИИ?" Верно? Почему он не отвечает на вопросы так, как мы ожидали, когда мы делали демонстрации? Э, это приводило не только к меньшему, знаете ли, отсутствию окупаемости инвестиций, но и к потере денег и усилий на создание этих демонстраций, которые никогда не могли быть масштабированы до продакшена. Во время этих, э, встреч я собрал три вывода, которые связаны со всем, о чем мы говорим, когда думаем о выводе, э, ИИ в продакшн. Первый — это разрыв в наблюдаемости, верно? Когда мы используем ИИ и выводим его в продакшн, если мы не можем видеть, что он на самом деле делает, если мы не можем отследить каждое принимаемое им решение, он бесполезен в продакшне. Второй — это разрыв в оценке. Много из этих разговоров, которые мы вели, мы на самом деле не думали о том, что является, что является той одной вещью, которую мы измеряем. Да, мы говорим об точности, мы говорим о задержке, мы говорим о обоснованности, но мы не определяли, что именно важно для бизнеса, и как мы можем построить систему, которая может постоянно измерять это, улучшается ли она, не улучшается ли она, знаете ли, какую систему нам нужно построить. И это был тот разрыв в оценке, который я заметил. И третье — это разрыв в управлении. Мы на самом деле не думали, что произойдет, когда ИИ потерпит неудачу в продакшне. Кто несет ответственность? К кому мне обратиться, когда что-то случится в 3 часа ночи, верно? Кто должен владеть данными, которые питают некоторые ответы ИИ? Что произойдет, если ИИ, знаете ли, э, скажет, э, э, э, чушь клиенту, верно? Что произойдет, верно? Итак, нет ответственности, нет управления этим. И эти три вывода привели меня к созданию фреймворка о том, как, по моему мнению, ИИ должен выводиться в продакшн, и это было реализовано в нескольких клиентских организациях, и я думаю, что это то, что вы можете взять отсюда. Это пять столпов, и это абсолютно то, о чем вам нужно подумать еще до начала проекта, верно? Затем вы начинаете строить их постепенно, предпочтительно последовательно, но в реальной жизни я знаю, что эта последовательность не работает, но это столпы, о которых вы должны знать и о которых вы должны думать, когда начинаете строить. Первый — это оценка. Прежде чем прикасаться к какому-либо коду, прежде чем обсуждать какие-либо модели, какие-либо функции, вы должны подумать о том, как мы будем измерять, когда построим эту систему. Как выглядит успех, и какая система поможет нам постоянно измерять, как выглядит успех для нас? Второй — как мы отслеживаем каждое решение, которое принимает ИИ. Это важно не только для производительности ИИ-системы, но и для регуляторов. В Европе или во многих компаниях, особенно в регулируемых отраслях, вы не можете даже вывести ИИ в продакшн без наличия отслеживания и наблюдаемости. Так что это обязательное условие. Третий — это основа данных, верно? Э, я, я, я, я думаю об основе данных двумя способами. Один — это данные для запросов, то есть данные, необходимые ИИ для ответов на вопросы, которые пользователи ему задают. Так что это могут быть ваши данные для предварительного обучения, данные для пост-обучения, данные, которые вы используете через API для получения ответа, который нужен пользователю. Другой — это данные для отслеживания, связанные с данными для отслеживания в наблюдаемости, но когда вы думаете с точки зрения основы данных и, э, стратегии данных, это должно быть обработано в этом столпе, потому что вам нужна полная стратегия данных сейчас с данными для отслеживания, особенно когда вы запускаете сотни агентов в вашей организации. Четвертый — оркестрация. Один агент будет работать довольно хорошо. Вам не нужно думать об оркестрации. Но когда вы подключаете пять агентов, сложность экспоненциально возрастает, верно? У вас будет несколько шаблонов координации между этими агентами, им нужно будет общаться друг с другом множеством разных способов, им нужно будет ждать ответов друг друга, возникает много сложностей. И именно здесь шаблоны оркестрации и размышления о том, как вы будете оркестрировать своих агентов в конкретной системе, становятся действительно важными. Пятый — управление. Здесь вы думаете о том, что произойдет, когда что-то пойдет не так. Кто несет ответственность? Как мы управляем данными? Как мы их защищаем? Как мы защищаем наши системы? Как мы гарантируем, что никто не вмешается в нашего агента и не приведет к, знаете ли, неправильному поведению, верно? Или потере репутации. Итак, в оставшейся части сессии я углублюсь в каждый из этих столпов и расскажу вам, как вы можете думать о них, когда начнете работать с ними, верно? Первый — это оценка. Оценка — это, по сути, спецификация для вашей ИИ-системы. Вы определяете успех. Как я уже упоминал, это не просто разговор о точности. Вы должны определить это в числах, например, какая точность хороша для вашего бизнес-кейса, верно? Определите это в числах. Э, определите, какие виды, знаете ли, ложных срабатываний вы можете обработать. Каким должно быть отклонение? Так вот, это пример из розничного чат-бота, верно? Банковского чат-бота, где при внедрении чат-бота с ИИ-агентом одной из основных целей является перенаправление простых запросов, э, агенту, чтобы человеку-агенту не приходилось, э, иметь с ними дело, верно? И поэтому вам нужно, э, вам нужно отслеживать эти запросы и отслеживать эти числа и внедрять эту систему. Второй — создание тестовых случаев, таких как набор данных для оценки. Вы слышали о золотых наборах данных при оценке. Поговорите с экспертами предметной области и выясните, что на самом деле происходит в реальной жизни. Например, какой ответ дал бы человек-агент поддержки, э, клиенту на конкретный вопрос. Соберите эту информацию. Что происходит в серых зонах, в крайних случаях, например, что происходит, когда человек видит, как клиент задает запутанный вопрос, верно? Соберите это в набор данных, а затем автоматизируйте тестирование ИИ, верно? Итак, вы задаете вопрос ИИ, он отвечает, берете этот ответ, сравниваете с тестовым набором, и автоматизируете весь этот конвейер, чтобы, когда вы выводите ИИ в продакшн, этот конвейер мог фактически принимать ответы в реальном времени и оценивать их по сравнению с тестовым набором данных, который вы создаете, а затем давать вам результат в виде того, как ИИ работает по сравнению с этими числами и целями, которые вы определили. Когда мы говорим об оценке, я вижу три основных уровня, которые появляются в организациях, и это архитектурное решение, которое вам нужно принять при создании этих систем оценки, верно? Первый уровень — детерминированный. Это простые вещи, например, проверка форматов, знаете ли, проверка форматов электронной почты, телефонных форматов, вещи с регулярными выражениями, которые мы уже делали с нашими системами кодирования, верно? Э, другие — это, знаете ли, вы можете использовать классические ML-модели для распознавания именованных сущностей, для классификации намерений, для понимания того, что такое имя, фамилия, обнаружение PII и т. д. Так вот, это простые вещи, дешевые вещи, их следует убрать. Мы уже делаем это годами. Второй уровень — недетерминированные семантические вещи, хорошо? Здесь вступает в игру обоснованность. Здесь мы внедряем такие технологии, как LLM-судьи. Мы все знаем, что такое LLM-судьи, верно? Все? Хорошо, я вижу много кивков. Итак, э, опять же, это довольно простая версия того, как может выглядеть промпт для LLM в качестве судьи. Э, Итак, с LLM в качестве судьи вы используете отдельный LLM от основного LLM для оценки ответа основной модели. И когда вы это делаете, вы говорите вторичной, модели-судье, как она должна, э, оценивать вывод основной модели. Так что это может быть связано с безопасностью, обоснованностью, знаете ли, релевантностью ответа и т. д. и т. д., верно? Опять же, это может использовать много, э, наборов данных для оценки, которые вы создали, верно? Чтобы посмотреть, какие ожидаемые ответы, а затем она может проверить их. Это пример промпта о том, как это работает, но я уверен, что вы посетили некоторые из этих сессий, где вы видели, как поставщики делают это автоматически в масштабе. Э, например, в Databricks в MLflow вы найдете автоматического LLM-судью, э, где вы можете создавать этих пользовательских LLM-судей, которые работают автоматически по трассировкам. Это ваш второй уровень. Третий уровень — поведенческий, верно? Здесь вы думаете о вызовах инструментов, например, вызывает ли наш агент правильный инструмент? Не попадают ли они в циклы? Так, например, э, знаете ли, на первом уровне пользователь может задать вопрос: "Каков мой баланс на счете?" И вы можете проверить, что, хорошо, с этим нет детерминированной проблемы. Семантика — агент ответил правильно, что "Ваш баланс на счете составляет столько-то долларов". И это было правильно, и вы можете видеть, что это правильно, но когда вы переходите к поведенческим проверкам, вы увидите, что агент фактически сделал три вызова к базе данных, чтобы получить этот ответ. Верно? И это потому, что он делал дублирующие вызовы по какой-то причине. Вызовы не удались, знаете ли, вызовы не сработали, он повторил и тому подобное. Теперь три вызова API в демонстрационной среде — это нормально, но в продакшне, когда вы получаете тысячи запросов от пользователей каждый день, и есть дублирование вызовов API, это дорогостоящая операция. И именно здесь вам нужно подумать о поведенческой оценке. И этот уровень очень, очень важен. Я вижу, что многие организации, многие команды пропускают его, когда говорят об этом. Второй уровень — наблюдаемость, верно? Э, и в этом столпе мы говорим о трассировке, верно? Итак, вы собираете [хмыкает] все решения, которые принимает агент. Итак, я хочу объяснить это на примере сценария, верно? И это сценарий из реального проекта, над которым я работал с банковским, э, розничным, розничным банковским чат-ботом. Теперь, очевидно, если вы видели данные трассировки, они не так красивы, как этот слайд, верно? Итак, я упростил его и сделал красивым для этого слайда. Но что говорит этот слайд, по сути, это то, что пользователь приходит и говорит: "Знаете, мне начислили комиссию за овердрафт, можете ли вы отменить ее для меня?" Потому что пользователь думает, что клиент думает, что это не законно. Итак, агент выполняет классификацию намерений, и вы все знаете об этом, потому что вы включили наблюдаемость, вы захватываете трассировки, и вы фактически видите, что делает агент, верно? Что делает ИИ. Классификация намерений выполнена, это заняло столько-то секунд, это был показатель уверенности. Затем он подключается к счету клиента, возможно, в базе данных, вызывает API, подключается к базе данных клиента, получает детали счета. Он извлекает документы политики. Он проверяет из векторной базы данных RAG, э, какова, э, какова политика в отношении овердрафта, верно? Законно ли то, что утверждает клиент? Итак, он проверяет документы политики. Затем он проводит рассуждение о том, что следует, э, знаете ли, ответить клиенту, а затем выполняет некоторые окончательные проверки безопасности и отвечает клиенту. Теперь, если вы не настроили систему, которая помогает вам визуализировать все эти трассировки, когда клиент приходит к вам и предъявляет претензию, у вас нет способа проверить, что сделал ИИ. Верно? Вам некуда идти, и вы в конечном итоге говорите, что я понятия не имею. Давайте, давайте дадим клиенту скидку или что-то еще, и тогда сделаем его счастливым. Итак, вот почему вам это нужно, и вот почему регуляторы, э, по сути, предписывают это, потому что иначе не будет производственной системы, если вы не сможете делать такие вещи. Итак, здесь, э, знаете ли, вы, вы, вы обнаруживаете пример, который я привел о дублирующих вызовах API. Здесь вы начинаете обнаруживать такие вещи. Итак, когда вы, когда вы включаете эти трассировки, вы можете фактически перейти и увидеть дублирующие вызовы, а затем предпринять соответствующие действия на их основе. Не только это, вы можете фактически делать это в онлайн-мониторинге. Итак, когда это происходит в продакшне, в режиме онлайн, вы можете настроить онлайн-мониторинг, и в этот момент, если он делает дублирующие вызовы, вы можете применить стратегии отката. Или даже если он делает вызов, который не удается, вы можете фактически применить стратегию, где он скажет: "Хорошо, попробуйте еще три раза, не более трех раз. Если это больше трех раз, то сообщите куда-нибудь или передайте человеку, чтобы он принял какие-то меры." Третий столп — самый важный столп, на мой взгляд, — это основа данных, данных, данных, верно? Э, в моих типичных проектах я трачу 60% своего времени, э, и я вижу, что многие организации тратят много времени здесь, потому что никто не ожидал, что агенты внезапно появятся на рынке и начнут запрашивать данные. Данные всегда строились для людей, а люди всегда прощали. Вы находите неверные данные в отчете, вы просто идете и просите кого-нибудь исправить это. Агенты не прощают вас, верно? Агенты найдут это неправильно, они уверенно дадут вам неправильный ответ. Верно? И вы не будете знать, что происходит. И именно поэтому качество данных, установка правильной стратегии данных, стало настолько важным для предприятий сейчас. Я разделяю это на два раздела. Один — это данные для запросов, как я объяснял, данные, необходимые для фактического предоставления результата ИИ. И другой — это данные для отслеживания. Это данные наблюдаемости, данные трассировки, о которых я говорил ранее. Вам нужен надлежащий план того, как вы собираете эти данные для отслеживания, и как вы предоставляете их аудиторам, регуляторам, для онлайн-мониторинга, для запуска LLM-судей по трассировкам и всему остальному, верно? Так что там нужна надлежащая стратегия того, как вы структурируете схему и все остальное для данных отслеживания. Э, В Databricks, э, мы создаем надежную основу данных для наших клиентов, используя некоторые из технологий, которые мы предоставляем. Если вы не знаете Databricks, Databricks построен на некоторых технологиях с открытым исходным кодом, таких как Apache Spark, MLflow и Delta Lake. Э, мы предоставляем ряд возможностей поверх этого. Итак, синий слой внизу — это, по сути, ваше облачное хранилище. Databricks работает на трех основных облаках: Google, AWS, Azure. Хорошо. Я думал, это для меня. Итак, Итак, когда вы храните необработанные данные в вашем облачном хранилище, э, данные затем, э, э, э, мы вводим слой, называемый Delta Lake, который, э, который, по сути, добавляет свойства, подобные базе данных, поверх ваших необработанных данных. Так что у вас есть изображения, текстовые файлы, видеофайлы или что-либо еще. Мы помогаем вам создать эту, э, знаете ли, структуру, похожую на таблицу, поверх нее, используя файлы манифеста, верно? И мы помогаем вам инкрементально загружать данные, выполнять все эти, э, задачи управления данными структурированным образом. Поверх этого мы вводим Unity Catalog, который является каталогом данных. Э, с Unity Catalog вы можете централизованно применять разрешения к данным. Вы можете, э, вы можете, э, делиться данными с помощью, э, Delta Sharing, но также, э, что происходит с Unity Catalog, это то, что вы можете включить обнаружение и, знаете ли, возможности владения, тегирования метаданных на уровне каталога. Что это значит, когда вы применяете описание таблицы, описание столбца, э, тегируете столбцы, такие как столбцы PII, с метаданными, становится очень легко для ИИ получить этот контекст, когда он запрашивает эти таблицы поверх Unity Catalog. Итак, все управляется на одном уровне через Unity Catalog, и поверх этого мы предоставляем различные приложения. Так что, будь то ИИ через Mosaic AI, для создания LLM, настройки LLM, или даже создания ИИ-приложений, мы предоставляем возможности хранилища данных, возможности BI, и, э, и некоторые другие возможности text-to-SQL. У нас есть Genie, который, э, помогает вам писать на естественном языке для выполнения SQL-запросов и т. д. И одно из применений этого в наблюдаемости и данных для отслеживания, как я показывал, это это. Итак, по сути, подумайте о том, когда я говорил о стратегии данных для отслеживания. Организации, особенно предприятия, не будут запускать ИИ только в одном фреймворке. Они будут использовать различные фреймворки, CrewAI, LangChain и т. д. и т. д. Они будут использовать различные облачные платформы. И как только они это сделают, вам нужен централизованный уровень сбора данных трассировки, чтобы вы могли обслуживать несколько вариантов использования справа. Так что, будь то операционные дашборды, для поддержки первой линии, э, многим из этих команд первой линии, э, первой линии обороны нужны дашборды для мониторинга работоспособности, верно? Эти команды также могут писать SQL, используя Databricks Genie, для text-to-SQL. Но они также могут создавать приложения Databricks, используя кодирующих агентов, для создания общих рабочих пространств или пользовательских пользовательских интерфейсов, которые могут понадобиться клиентам для различных, э, различных вариантов использования. И затем у нас есть Agent Bricks и MLflow, которые предоставляют вам LLM-судей из коробки и проактивно мониторят. Идея в том, что, независимо от того, где работает ваш ИИ, вы можете создать такую стратегию, собирая данные в одном общем месте и обслуживая различные команды из одного общего расположения. Четвертый столп — шаблоны оркестрации с несколькими агентами. Как я сказал, один агент — это хорошо, несколько агентов увеличивают сложность. Вот где вы начинаете думать о том, какой шаблон подходит для вашего варианта использования. Первый, который я описываю здесь, — это шаблон "оркестратор-рабочий". Где у вас есть один оркестратор, который оркестрирует всю работу, который контролирует всю работу с централизованной плоскости и затем распределяет эту работу различным агентам на основе их специализированных навыков. И затем каждый запрос проходит через оркестратор, так что у вас есть центральный контроль. Если что-то пойдет не так, вы можете перейти к журналам оркестратора и посмотреть их и увидеть, что произошло. Верно? Так что это шаблон данных оркестрации. Есть этот шаблон хореографии, где каждый агент независим, они автономны, они не зависят от оркестратора. Все они общаются с шиной сообщений и слушают события, которые их интересуют. Верно? Так что подумайте об агентах, которые независимы друг от друга, верно? Они могут работать параллельно. Так что они не последовательны, как один агент не зависит от другого. Так что они работают параллельно, они слушают шину сообщений для событий, которые их интересуют. Возможно, это триггер, скажем, для заявки на ипотеку, и он говорит, знаете ли, заявка на ипотеку, агент, один из агентов просматривает детали клиента, верно? Другой агент просматривает детали одобрения и все остальное, верно? Они могут работать параллельно, и преимущество, которое это дает вам, — это снижение задержки, потому что они не зависят от оркестратора и обмена сообщениями туда и обратно. Верно? Так что это шаблон хореографии. И третий — "человек в цикле", где, когда агент пересекает порог или работает ниже порогового значения уверенности, тогда в рабочий процесс вызывается человек, чтобы он посмотрел на шаблон, э, посмотрел на то, что сделал агент, и затем принял меры на основе этого. Я сделал подробное видео о шаблонах оркестрации с несколькими агентами для онлайн-трека этой конференции. Оно уже есть на YouTube, так что вы можете посмотреть его. Я говорю о реальных последствиях, когда вы думаете о шаблонах с несколькими агентами. Один — это управление состоянием, другой — отказоустойчивость, например, что происходит, когда что-то выходит из строя, как вы ими управляете? Я говорю о различных шаблонах. А затем говорю о том, как вы думаете о масштабировании их в больших масштабах на предприятиях. Столп 5 — управление, верно? Теперь здесь я вообще не говорю об управлении данными. Это само собой разумеется, оно нам нужно, верно? С точки зрения ИИ, о чем мы думаем? Регуляторные требования, верно? Аудиторские следы, есть ли у нас след каждого действия, каждого подключения пользователя, каждого запроса, всего, что происходит в системе? Захватываем ли мы все? Выполняем ли мы предварительную проверку личной информации? Используем ли мы распознавание именованных сущностей? Простые вещи, регулярные выражения и все такое, верно? В нашем примере, над работой, которую я делал с клиентом, которого я упомянул, мы уже обнаружили 47 нарушений PII во время фазы тестирования, применив этот уровень. Так что это действительно важно. Четвертое — версионирование промптов. Вы должны относиться к версионированию промптов как к управлению изменениями в корпоративном решении. Это не может быть просто изменение промпта и фиксация в Git. Это должно пройти через надлежащие процессы управления изменениями, как вы делаете с кодом. Так что, по сути, отношение к промпту как к коду. Третье — управление изменениями моделей. Так что, поскольку модели меняются, поставщики моделей обновляют эти модели, у вас должна быть система, чтобы понять, будет ли обновленная модель хороша для вашего варианта использования, для ваших данных. Верно? Поставщики моделей размещают эталонные тесты на трех эталонных досках, но они не очень полезны, когда вы помещаете их в свой контекст, в свое предприятие. Так что именно здесь пригодятся эти наборы данных для оценки, где вы тестируете эти различные модели на этом наборе данных для оценки и пытаетесь понять, какая работает лучше. И этим управлением нужно заниматься, потому что с точки зрения риска вы не можете полагаться на одну единственную модель. У вас должна быть гибкость переключаться на разные модели, а также тестировать их на своих собственных данных. Этим управлением нужно заниматься. Э, в Databricks, э, мы учли все эти пункты, эти столпы, о которых я говорил, в Agent Bricks. Мы создаем Agent Bricks, чтобы сделать все эти операции готовыми к использованию для вас, э, чтобы было легко внедрять производственные ИИ-приложения в ваших предприятиях. Итак, я хотел быстро коснуться тематического исследования, просто чтобы дать вам представление о том, как все это происходит, верно? Итак, когда я работал с этим клиентом, они были розничным банком, они строили розничный банковский чат-бот, знаете ли, полтора-восемнадцать месяцев назад. Их проблема, проблема, которую они хотели решить, заключалась в том, что они получали около 20 000 звонков в месяц от клиентов по их чат-боту. Они хотели перенаправлять, они видели, что около 60% из них были простыми запросами, "каков мой баланс на счете", знаете ли, "что мне делать с моим овердрафтом" и все такое прочее, что можно было ответить просто. Так что они хотели снизить зависимость от агентов-людей для этих ответов. Итак, они определили эти запросы и хотели их автоматизировать. Верно? Они потратили около 85 тысяч долларов за 6 месяцев на POC, который не увенчался успехом. Когда мы вмешались, мы обнаружили те выводы, о которых я говорил, например, никто не знал, почему все шло не так, когда это было в продакшне, когда, когда это было в продакшне. Никто не мог на самом деле измерить, почему это не удается, и никто не мог на самом деле понять, кто за что несет ответственность, когда что-то идет не так. Верно? Итак, цель, которую мы поставили для них, — ИИ-агент обрабатывает 60% пользовательских запросов, верно? Которые были простыми пользовательскими запросами, а затем способ их идентификации и отслеживания. Ключевое отличие в этом проекте, которое мы сделали, заключается в том, что мы выбрали модель на седьмой неделе, как в восьминедельном POC. Верно? И вот как это получилось. На первую и вторую неделю мы построили слой оценки. Мы собрали 200 случаев ответов их реальных агентов-людей на простые запросы клиентов и поняли, как они отвечают на них. Мы создали эту базу данных. Затем мы определили метрики успеха. Что для вас означает успех? Итак, из, скажем, 100 запросов, вам нужно, чтобы 60 запросов или 60% запросов, которые являются простыми, были обработаны агентом, верно? Им нужна была какая-то точность. Так что 85% — это была цель около 85% точности. Им нужна была задержка, все операционные цели, которые вам нужны. Они были там. Затем мы создали для них этот автоматизированный конвейер оценки. И что я имею в виду под этим, это автоматизированная система, где вы можете захватить вопрос пользователя и ответ ИИ-агента. Вы берете это, сравниваете это с вашим набором данных для оценки. Вы оцениваете это, и если оценка ниже определенного порога, вы передаете это на проверку человеку. И если что-то идет не так, вы убеждаетесь, что находите решение. Так что это может быть изменение промпта, это может быть изменение системы вызова инструментов или что-то еще. Как только вы это сделали, вы добавляете этот тестовый случай в набор тестовых данных. Так что, когда это произойдет в следующий раз, тестовые случаи их поймают. Итак, резюме этой истории в том, что ваш набор данных для оценки — это живая система. Вы начинаете с 200, возможно, здесь нет правильного числа, но как только вы начинаете, как только вы начинаете строить в продакшне, это живая система. Она будет расти. И чем больше она растет, тем лучше будет ваша система. На второй неделе мы думали об основополагающем слое, верно? Итак, данные для запросов, мы подумали: "Хорошо, если нам нужно обратиться к базе данных, правильно ли настроены соединения API? Есть ли у вас система, которая может отслеживать соединения API? Безопасны ли они, верно? Мы тогда не говорили о MCP. Верно? Это были просто прямые вызовы API к базе данных для выполнения запросов. Есть ли у вас распределенное хранилище? Собираете ли вы трассировки? И именно здесь, когда мы начали тестирование после создания этих систем, мы смогли поймать эти дублирующие вызовы API, верно? Мы смогли понять, почему удовлетворенность клиентов падает и тому подобное. И затем на седьмой-восьмой неделе мы начали говорить о моделях. Теперь, когда у нас был набор данных для оценки, мы могли запускать различные модели на этом наборе данных, чтобы увидеть ответы, сравнить их с ожидаемыми ответами и рассчитать число по точности, верно? Это помогло нам решить, какую модель использовать. Теперь это решение не заняло много времени, верно? Как я объяснил во введении, мы неделями спорили, какую модель использовать, но если вы возьмете другой подход, вы сможете сделать это очень быстро. Итак, как только это сделано, мы объединили все, о чем я говорил, касательно наблюдаемости, оценки, уровней оценки. Как только у нас была система, которая могла сделать ИИ видимым, измеримым и подотчетным, мы начали запускать ее в продакшн. И именно тогда, э, вот результат — через шесть недель после запуска, мы рассчитали операционные метрики, конечно, знаете ли, точность, коэффициент перенаправления, время ответа, удовлетворенность клиентов CSAT. Но что важно здесь, так это то, что через несколько недель, когда возникла проблема с, э, так, одна из вещей, которая произошла, заключалась в том, что банк изменил некоторые политики, связанные с процентными ставками. Так что, когда они изменили политику, они фактически отправили электронные письма клиентам или уведомления в приложении, в мобильном банковском приложении, об изменении политики. Но когда клиенты приходили и задавали вопросы в чат-боте, они не могли получить правильные ответы, и они ставили "большой палец вниз" на ответы. Так что они получали эту обратную связь, верно? Так что обратная связь снизилась. Проблема с такой системой, если бы у вас не было этой системы измерения, заключается в том, что вы не могли бы знать, что происходит. Но поскольку у нас была система измерения, этот спад CSAT был обнаружен, верно? Потому что мы получали негативную обратную связь от клиентов. Мы могли фактически посмотреть на решения трассировки и увидеть, что агент смотрел на документ политики, который был устаревшим. Так, новый документ политики не был обновлен в векторной базе данных. Векторные представления не прошли. Поскольку они не прошли, он давал устаревшие ответы. И именно тогда мы пошли и исправили это. Но все это было возможно, потому что мы построили эти системы, которые позволили нам обнаружить это. Прежде чем вы уйдете, я обычно на таких сессиях делюсь различными артефактами, которые вы можете забрать. В конце у меня есть QR-код для скачивания, и вы найдете несколько артефактов. Один из важных артефактов, о котором я хочу поговорить, — это руководство по инцидентам в продакшне. Это то, что многие из нас склонны упускать, когда работаем над ИИ-проектами. И это руководство — это, по сути, определение того, что нужно делать, когда что-то идет не так в продакшне. Сначала вы обнаруживаете с помощью нашей панели оценки. Затем вы диагностируете с помощью трассировки, как я объяснил. Затем вы сдерживаете. Так, по сути, вы версионируете свои промпты. Есть ли, есть ли, если есть проблема с промптом, вы убираете этот промпт, верно? И начинаете изменения, перенаправляете к человеку. Или в моем видео об оркестрации с несколькими агентами я говорил о нескольких шаблонах отказоустойчивости и восстановления после сбоев, таких как шаблон саги, шаблон компенсации и шаблон автоматического выключателя, которые вы можете посмотреть в видео. Я подробно объяснил их, как вы можете с ними справиться. А затем вы используете библиотеку тестовых случаев для исправления. Итак, вы смотрите на отчеты LLM-судей, вы смотрите на отчеты вашего набора данных для оценки. Затем вы исправляете свою проблему. Как только вы исправили проблему, вы добавляете эти тестовые случаи в свой набор данных, верно? И создаете этот набор для оценки, который является живой системой, которая будет расти. И вы продолжаете улучшать свою ИИ-систему на его основе, верно? Но это руководство должно быть на месте. Когда оно будет работать в продакшне, вам нужно будет интегрировать его с вашей ITSM-системой, чтобы оно оповещало нужного человека в нужное время. Знаете, у многих из этих организаций будут существующие ITSM-системы, верно? Которые используются для оповещения и, знаете ли, обеспечения того, чтобы нижестоящие системы не пострадали и т. д. Так что, как только у вас будет это на месте, вы можете перейти и связать это с другими системами. Итак, что вы можете сделать завтра, верно? Начните с, если у вас есть проект на уме, начните с определения успеха. Успех не с технической точки зрения, а с точки зрения бизнеса. Что это значит для бизнеса, верно? Придумайте несколько примеров того, как выглядят хорошие ответы. И создайте набор данных для этого. А затем постройте этот конвейер, используя простой код Python. Посмотрите, можете ли вы автоматизировать это, чтобы, когда вы запускаете ИИ и получаете какой-то ответ, он мог сравнить. Вы можете сравнить ответ с этим набором данных, и тогда это может быть доставлено клиенту. Теперь, это три урока, которые я извлек, делая все это с моими, вы знаете, моими легко упускаемыми. Библиотека тестовых случаев, как я объяснил, — это растущая система. Она будет расти со временем. И поскольку она растет со временем, вам нужно какое-то управление ею. Вам нужен владелец, верно? Вам нужно, вам нужно выяснить, какие тестовые случаи относятся к какому типу проблемы. Так что, когда вы вернетесь к ней, вы сможете связать свои ответы с такими типами проблем, верно? Если это безопасность, если это вход в систему, то вы можете сказать, что агент не запрашивал учетные данные для входа, когда клиент запрашивал ответ. И все эти виды проблем могут быть отнесены к категории безопасности в этом наборе данных. Так что категоризируйте строки в вашем наборе данных, чтобы вы могли выбрать, что изменилось, и сравнить это с ними. Второе — версионирование промптов. Теперь, когда вы начинаете версионировать промпты, используя Git, знаете ли, мы все знаем, что когда вы помещаете сообщения коммитов Git, они, как правило, простые сообщения коммитов. Но вам нужно иметь управление тем, какие сообщения коммитов вы помещаете при изменении этих промптов, потому что вам нужно понимать, когда промпт был изменен, по какой именно причине он был изменен, верно? Какая неудача привела к изменению этого промпта? Какой тип неудачи он должен был устранить, и что он должен был исправить, верно? В следующей версии. Это должно быть задокументировано. Иначе становится трудно, потому что когда вы возвращаетесь и смотрите на версионирование промптов и смотрите на разные версии, и вы не можете отследить, почему эти изменения были сделаны, тогда становится трудно отследить, что происходит. Третье — эвалюации уровня 3, верно? Так что поведенческие эвалюации, о которых я говорил, касающиеся вызовов инструментов и тому подобного, они могут быть очень дорогими, поскольку ваш набор данных для оценки также растет. Так что, когда у вас есть неправильный вызов инструмента, например, и вы хотите исправить эту систему, когда вы ее исправляете и запускаете против набора данных для оценки, вам нужно, по сути, запустить его против, скажем, если у вас есть 300, 400, 500 строк в наборе данных, вам нужно запускать его против них. И вы делаете все тестирование снова и снова и снова и снова, это может стоить вам много денег. Так что вам нужно какое-то управление этим. Так, например, когда в вашем конвейере непрерывной интеграции, когда вы вносите изменение в промпт, вы можете фактически добавить некоторые проверки, просто выбирая небольшую подмножество набора данных для оценки для тестирования. И вы делаете полное тестирование только тогда, когда сливаетесь в основную ветку. Так что вы можете внедрить такие решения, чтобы снизить затраты на, знаете ли, дорогостоящие решения для оценки. Если вы отсканируете этот QR-код, он приведет вас по ссылке на Google Drive, где я разместил несколько примеров того, как выглядят эти шаблоны, как должен выглядеть чек-лист оценки. Я дал вам некоторые руководства по настройке трассировки с использованием технологий с открытым исходным кодом, чтобы вы могли быстро настроить трассировку и начать тестирование в тестовой среде, прежде чем решите, какие инструменты вы хотите использовать. Большое спасибо за то, что выслушали меня. Этот QR-код приведет вас в мой профиль LinkedIn. Так что я делюсь, у меня есть информационный бюллетень, где я делюсь такими темами каждую неделю. Так что, если вам интересно, вы можете присоединиться. Это бесплатно. Я, по сути, делюсь тем, что узнаю в полевых условиях, работая с клиентами, верно? Так что это может быть полезно для вас. Большое спасибо. >> [аплодисменты]