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, и э, и некоторые другие возможности преобразования текста в SQL. У нас есть Genie, который помогает вам писать на естественном языке для выполнения SQL-запросов и т. д. И одно из применений этого в наблюдаемости и данных отслеживания, как я показывал, это это. Итак, по сути, подумайте о том, когда я говорил о стратегии данных отслеживания. Организации, особенно предприятия, не будут запускать ИИ только в одном фреймворке. Они будут использовать различные фреймворки, CrewAI, LangChain и т. д. и т. д. Они будут использовать различные облачные платформы. И как только они это сделают, вам нужен централизованный слой для сбора этих данных трассировки, чтобы вы могли обслуживать несколько вариантов использования справа. Так что, будь то операционные дашборды, поддержка первой линии, э, многим из этих команд первой линии э, первой линии обороны нужны дашборды для мониторинга состояния, верно? Эти команды также могут писать SQL, используя Databricks Genie, для преобразования текста в SQL. Но они также могут создавать приложения Databricks, используя кодовых агентов, для создания общих рабочих пространств или пользовательских пользовательских интерфейсов, которые могут понадобиться клиентам для различных, различных вариантов использования. А затем у нас есть Agent Bricks и MLflow, которые предоставляют вам LLM-судьи из коробки и проактивно мониторят. Идея в том, что независимо от того, где работает ваш ИИ, вы можете создать такую стратегию, собирая данные в одном общем месте и обслуживая различные команды из одного общего расположения. Четвертый столп — шаблоны оркестрации с несколькими агентами. Как я сказал, один агент — это хорошо, несколько агентов увеличивают сложность. Вот где вы начинаете думать о том, какой шаблон подходит для вашего варианта использования. Первый, который я описываю здесь, — это шаблон «оркестратор-рабочий». Где у вас есть один оркестратор, который оркестрирует всю работу, который контролирует всю работу с централизованной плоскости и затем распределяет эту работу различным агентам на основе их специализированных навыков. И затем каждый запрос проходит через оркестратор, так что у вас есть центральный контроль. Если что-то пойдет не так, вы можете обратиться к журналам оркестратора и посмотреть их и увидеть, что произошло. Верно? Так что это шаблон данных оркестрации. Есть этот шаблон хореографии, где каждый агент независим, они автономны, они не зависят от оркестратора. Все они общаются с шиной сообщений и слушают события, которые их интересуют. Верно? Так что подумайте об агентах, которые независимы друг от друга, верно? Они могут работать параллельно. Так что они не последовательны, один агент не зависит от другого. Так что они работают параллельно, слушают шину сообщений для событий, которые их интересуют. Возможно, это триггер, скажем, для заявки на ипотеку, и он говорит, знаете ли, заявка на ипотеку, агент, один из агентов просматривает детали клиента, верно? Другой агент просматривает детали одобрения и все остальное, верно? Они могут работать параллельно, и преимущество, которое это дает, — это снижение задержки, потому что они не зависят от оркестратора и обмена сообщениями туда и обратно. Верно? Так что это шаблон хореографии. И третий — «человек в цикле», где, когда агент пересекает порог или работает ниже порогового значения уверенности, тогда в рабочий процесс вызывается человек, чтобы посмотреть на шаблон, посмотреть на то, что сделал агент, а затем принять меры на основе этого. Я сделал подробное видео о шаблонах оркестрации с несколькими агентами для онлайн-трека этой конференции. Оно уже есть на YouTube, так что вы можете посмотреть его. Я говорю о реальных последствиях, когда вы думаете о шаблонах с несколькими агентами. Один — это управление состоянием, другой — отказоустойчивость, например, что происходит, когда что-то идет не так, как вы ими управляете? Я говорю о различных шаблонах. А затем говорю о том, как вы думаете о масштабировании их в больших масштабах на предприятиях. Пятый столп — управление, верно? Теперь здесь я вообще не говорю об управлении данными. Это само собой разумеется, оно нам нужно, верно? С точки зрения ИИ, о чем мы думаем? Регулирование, верно? Аудиторские следы, есть ли у нас след каждого действия, каждого подключения пользователя, каждого запроса, всего, что происходит в системе? Собираем ли мы все? Выполняем ли мы предварительную проверку личной информации? Используем ли мы распознавание именованных сущностей? Простые вещи, регулярные выражения и все такое, верно? В нашем примере, работа, которую я проводил с клиентом, которую я упомянул, мы уже обнаружили 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, верно? Мы смогли понять, почему удовлетворенность клиентов падает и тому подобное. А затем на седьмой-восьмой неделе мы начали говорить о моделях. Теперь, когда у нас был набор данных для оценки, мы могли запускать различные модели на этом наборе данных, чтобы видеть ответы, сравнивать их с ожидаемыми ответами и рассчитывать число по точности, верно? Это помогло нам решить, какую модель использовать. Теперь это решение не заняло много времени, верно? Как я объяснил во введении, мы неделями спорили, какую модель использовать, но если вы примете другой подход, вы сможете сделать это очень быстро. Итак, как только это будет сделано, мы объединили все, о чем я говорил, касательно наблюдаемости, оценки, уровней оценки. Как только у нас появилась система, которая могла сделать ИИ видимым, измеримым и подотчетным, мы начали запускать ее в продакшн. И именно тогда, это результат шести недель после запуска, мы рассчитали операционные метрики, конечно, знаете ли, точность, коэффициент перенаправления, время ответа, удовлетворенность клиентов. Но что здесь важно, так это то, что за несколько недель, когда возникла проблема с, так, одна из вещей, которая произошла, это то, что банк изменил некоторые политики, связанные с процентными ставками. Так, когда они изменили политику, они фактически отправили электронные письма клиентам или уведомления в приложении в мобильном банковском приложении об изменении политики. Но когда клиенты приходили и задавали вопросы в чат-боте, они не могли получить правильные ответы, и они ставили пальцы вниз под ответами. Так что они получали эту обратную связь, верно? Так что обратная связь уменьшилась. Проблема с такой системой, если бы у вас не было этой системы измерения, заключается в том, что вы не могли бы знать, что происходит. Но поскольку у нас была система измерения, этот спад удовлетворенности клиентов был обнаружен, верно? Потому что мы получали негативные отзывы от клиентов. Мы могли фактически просмотреть решения трассировки и увидеть, что агент смотрел на документ политики, который был устаревшим. Так, новый документ политики не был обновлен в векторной базе данных. Вложения не прошли. Поскольку они не прошли, он давал устаревшие ответы. И именно тогда мы пошли и исправили это. Но все это было возможно, потому что мы построили эти системы, которые позволили нам обнаружить это. Прежде чем вы уйдете, я обычно на таких сессиях делюсь различными артефактами, которые вы можете забрать. В конце у меня есть QR-код для загрузки, и вы найдете несколько артефактов. Один из важных артефактов, о котором я хочу поговорить, — это сборник правил по инцидентам в продакшне. Это то, что многие из нас склонны упускать, когда работаем над проектами ИИ. И этот сборник правил — это, по сути, определение того, что нужно делать, когда что-то идет не так в продакшне. Во-первых, вы обнаруживаете с помощью нашей панели оценки. Затем вы диагностируете с помощью нашей трассировки, как я объяснил. Затем вы сдерживаете. Так, по сути, вы версионируете свои промпты. Есть ли, есть ли, если есть проблема с промптом, вы убираете этот промпт, инициируете изменения, перенаправляете к человеку. Или в моем видео об оркестрации с несколькими агентами я говорил о нескольких шаблонах отказоустойчивости и восстановления после сбоев, таких как шаблон саги, шаблон компенсации и шаблон автоматического выключателя, которые вы можете посмотреть в видео. Я подробно объяснил их, как вы можете с ними справиться. А затем вы используете библиотеку тестовых случаев для исправления. Итак, вы смотрите на отчеты LLM-судьи, вы смотрите на отчеты вашего набора данных для оценки. Затем вы исправляете свою проблему. Как только вы исправите свою проблему, вы поместите эти тестовые случаи в свой набор данных, верно? И создадите этот набор для оценки, который является живой системой, которая будет расти. И вы будете постоянно улучшать свою ИИ-систему на его основе, верно? Но этот сборник правил должен быть на месте. Когда он будет работать в продакшне, вам нужно будет интегрировать его с вашей системой ITSM, чтобы она оповещала нужного человека в нужное время. Знаете, у многих из этих организаций будут существующие системы ITSM, верно? Которые используются для оповещения и, знаете ли, обеспечения того, чтобы нижестоящие системы не пострадали и т. д. Так что, как только у вас будет это на месте, вы можете пойти и связать это с другими системами. Итак, что вы можете сделать завтра, верно? Начните с, если у вас есть проект на уме, начните с определения успеха. Успех не с технической точки зрения, а с точки зрения бизнеса. Что это значит для бизнеса, верно? Придумайте несколько примеров того, как выглядят хорошие ответы. И создайте набор данных из этого. А затем постройте этот конвейер, используя простой код Python. Посмотрите, можете ли вы автоматизировать это, чтобы, когда вы запускаете ИИ и получаете ответ, он мог сравнить ответ с этим набором данных, и тогда это может быть доставлено клиенту. Теперь, это три урока, которые я извлек, занимаясь этим с моими, вы знаете, моими легко упускаемыми. Библиотека тестовых случаев, как я объяснил, — это растущая система. Она будет расти со временем. И поскольку она растет со временем, вам нужно некоторое управление ею. Вам нужен владелец, верно? Вам нужно выяснить, какие тестовые случаи связаны с каким типом проблемы. Так что, когда вы вернетесь к ней, вы сможете связать свои ответы с такого рода проблемами, верно? Если это безопасность, если это вход в систему, то вы можете сказать, что агент не запрашивал учетные данные для входа, когда клиент просил ответ. И все эти виды проблем могут быть помещены в категорию безопасности в этом наборе данных. Так что категоризируйте строки в вашем наборе данных, чтобы вы могли понять, что изменилось, и сравнить это с ними. Второе — версионирование промптов. Теперь, когда вы начинаете версионировать промпты, используя Git, знаете ли, мы все знаем, что когда вы помещаете сообщения коммитов Git, они, как правило, простые сообщения коммитов. Но вам нужно иметь управление тем, какие сообщения коммитов вы помещаете при изменении этих промптов, потому что вам нужно понимать, когда промпт был изменен, по какой именно причине он был изменен, верно? Какая неудача привела к изменению этого промпта? Какой тип неудачи он должен был устранить и что он должен был исправить, верно? В следующей версии. Это должно быть задокументировано. Иначе становится трудно, потому что когда вы возвращаетесь и смотрите на версионирование промптов и смотрите на разные версии, и вы не можете отследить, почему эти изменения были внесены, тогда становится трудно отследить, что происходит. Третье — эвалы уровня три, верно? Так что поведенческие эвалы, о которых я говорил, касающиеся вызовов инструментов и тому подобного, они могут быть очень дорогими, поскольку ваш набор данных для оценки также растет. Так что, когда у вас есть неправильный вызов инструмента, например, и вы хотите исправить эту систему, когда вы ее исправляете и запускаете против набора данных для оценки, вам нужно, по сути, запускать его против, скажем, если у вас есть 300, 400, 500 строк в наборе данных, вам нужно запускать его против них. И вы делаете все тестирование снова и снова и снова и снова, это может стоить вам много денег. Так что вам нужно иметь некоторое управление этим. Например, когда в вашем конвейере непрерывной интеграции вы вносите изменение в промпт, вы можете фактически добавить некоторые проверки, просто выбрав небольшую подмножество набора данных для оценки для тестирования. И вы проводите полное тестирование только при слиянии в основную ветку. Так что вы можете внедрить такие решения, чтобы снизить затраты на дорогостоящие решения для оценки. Если вы отсканируете этот QR-код, он приведет вас по ссылке на Google Drive, где я разместил несколько примеров того, как выглядят эти шаблоны, как должен выглядеть чек-лист оценки. Я дал вам некоторые руководства по настройке трассировки с использованием технологий с открытым исходным кодом, чтобы вы могли быстро настроить трассировку и начать тестирование в тестовой среде, прежде чем решите, какие инструменты вы хотите использовать. Большое спасибо за то, что выслушали меня. Этот QR-код приведет вас в мой профиль LinkedIn. Так что я делюсь, у меня есть информационный бюллетень, где я делюсь такими темами каждую неделю. Так что, если вам интересно, вы можете присоединиться. Это бесплатно. Я, по сути, делюсь тем, что узнаю в полевых условиях, работая с клиентами, верно? Так что это может быть полезно для вас. Большое спасибо. >> [аплодисменты]