Transcription
Привет всем. Я Апурва, и я дата-сайентист, ставшая разработчиком-адвокатом, в настоящее время работающая в MongoDB. Первую часть своей карьеры я посвятила созданию приложений машинного обучения для различных сценариев использования в области кибербезопасности, а теперь я использую эти прикладные знания машинного обучения, чтобы помочь создателям ИИ успешно разрабатывать приложения ИИ с помощью MongoDB и Voyage AI. В этом выступлении вы узнаете, как подходить к созданию систем ИИ от начала до конца, от идеи до производства. Мы рассмотрим реальный сценарий использования и пройдемся по всем этапам его проектирования, и, надеюсь, в конце вы уйдете с повторяемой структурой, которую сможете применить к любой системе ИИ, которую вы спроектируете.
Теперь вы можете подумать: в эпоху ИИ, нужно ли нам вообще думать о том, что мы строим? Просто напишите код и отправьте его, верно? Но именно с этого я хочу начать.
Итак, вот в чем проблема. "Напиши и отправь" отлично работает, когда вы создаете для удовольствия, ставки низки, и вы можете легко оценить, правилен ли результат того, что вы создаете. Но в тот момент, когда вы строите что-то реальное, на что полагаются другие люди, что-то с реальными последствиями, просто "отправить" на самом деле довольно опасно. И это не только я говорю, люди из Anthropic и OpenAI, которые так оптимистично настроены в отношении кодирования с помощью ИИ, говорят то же самое. Это фактически цитаты из их выступлений за последние несколько месяцев.
Спецификации — это новое кодирование. Искусство заключается в определении требований к продукту, системного дизайна и критериев оценки, чтобы вы могли быть уверены, что ваши ИИ-помощники по кодированию создают правильную вещь. И остальная часть этого выступления посвящена именно этому. Как мы можем сделать это хорошо?
Полезно думать об этом как о структуре. Четыре этапа. Вы начинаете с требований к продукту. Что вы на самом деле строите, для кого, и каковы ограничения? Затем системный дизайн, данные, архитектура, шаблоны, которые фактически помогают вам удовлетворить эти требования. Затем идет оценка и мониторинг. Как вы узнаете, что создаваемое действительно работает до и после отправки? И, наконец, как вы оптимизируете затраты, не только точность, но и затраты, задержку и надежность до отправки и/или по мере обнаружения пробелов в производстве.
Вместо того чтобы абстрактно говорить о структуре, я подумал, почему бы не применить ее к реальному сценарию использования, чтобы вы могли увидеть, как именно каждое решение перетекает из одного этапа структуры в следующий.
Итак, давайте возьмем в качестве примера систему рассмотрения страховых медицинских претензий. Исторически сложилось так, что рассмотрение медицинских страховых претензий было чрезвычайно трудоемким процессом, где медицинские рецензенты должны были перекрестно проверять клинические рекомендации, страховые полисы, историю болезни пациента и прочее, чтобы решить, покрывается ли медицинское лечение, процедура или лекарство страховым полисом пациента. Теперь, если вы живете там, где есть бесплатное здравоохранение, даже там есть вещи, которые покрываются, а которые нет вашей системой здравоохранения. Так что вы все равно подпадаете под действие какой-то версии этого процесса.
Наша цель при создании этой системы — посмотреть, сможем ли мы улучшить или упростить работу медицинских рецензентов с помощью ИИ.
Итак, давайте посмотрим, как может выглядеть этап требований к продукту для этого приложения. Первое, что нужно сделать, — это количественно оценить бизнес-проблему. Бизнес-проблема должна быть сосредоточена на чем-то конкретном, четко указывать, кто является пользователями приложения, текущее состояние дел и количественно оценивать болевые точки пользователей. Она не должна предписывать, какой будет система, будет ли это агент, многоагентная система или что-то еще. Это придет позже.
Итак, вот как может выглядеть бизнес-проблема для нашей системы рассмотрения претензий. Медицинские рецензенты в MDB Health тратят в среднем 2 дня на обработку запросов на рассмотрение претензий, что в четыре раза превышает отраслевой стандарт для не срочных случаев и в 12 раз — для срочных. Задержки такого масштаба откладывают уход за пациентами, особенно для срочного лечения.
Как вы можете видеть, эта бизнес-проблема является специфичной для пользователя. Она говорит, что это предназначено для медицинских рецензентов. Она описывает текущее состояние, которое представляет собой этот ручной процесс, из-за которого они тратят 2 дня на обработку рассмотрения претензий. Она измерима, поскольку указывает некоторые базовые уровни. Она не зависит от решения. Она не говорит вам, как должна выглядеть система, и она очень сосредоточена на конкретной проблеме.
Далее, вам нужно собрать любые бизнес-ограничения для приложения. Итак, любые нормативные требования соответствия, любые ограничения на данные, покидающие вашу организацию, ограничения на закупки, то есть, есть ли определенные поставщики, не одобренные для использования в организации. Все это было бы полезно знать еще до того, как вы начнете проектировать систему.
Итак, для нашего приложения, скажем, это некоторые из бизнес-ограничений. Данные пациента должны оставаться в одобренной облачной среде. Могут использоваться только модели, доступные в одобренном облаке. Есть некоторые сценарии использования, где требуется человеческое рассмотрение. Итак, любые сложные сценарии использования требуют рассмотрения старшим врачом. Что еще? Любые решения об отказе должны быть рассмотрены человеком-рецензентом. Так что есть случаи, которые вы не можете полностью автоматизировать с помощью ИИ. Так что, да, все это полезные входные данные для проектирования. Так что вы хотите иметь их как можно скорее. Также полезно знать о любых требованиях к производительности. Нужны ли нам ответы менее чем за миллисекунду, или у нас есть некоторая свобода действий? Сколько мы можем тратить в месяц на вывод LLM? Есть ли SLA по времени безотказной работы, о которых нужно знать?
Далее, если вы создаете продукт ИИ, полезно определить роль ИИ в вашем продукте. И мне нравится думать о роли ИИ по трем измерениям. Во-первых, является ли ИИ критически важным для вашего продукта или дополняющим? В данном случае, дополняющим, поскольку претензии уже обрабатываются без ИИ, но они просто медленнее.
Далее, будет ли это реактивная или проактивная система? То есть, запускается ли она пользователем или событием, или она проактивно выполняет действия? В данном случае это будет реактивная система, поскольку она запускается фактическим представлением заявки на претензию.
И, наконец, каков уровень автономии для ИИ в приложении? Итак, в нашем случае бизнес-ограничения предписывают человеческое рассмотрение в определенных случаях. Так что наша система может быть максимум полуавтономной.
И, наконец, в рамках определения того, что вы решаете, вы также хотите придумать один-два метрики успеха, соответствующие бизнес-проблеме, чтобы вы могли понять, как выглядит успех. Хорошая метрика успеха является конкретной, измеримой, достижимой, релевантной и ограниченной по времени.
И вот пример метрики успеха для нашего приложения рассмотрения претензий. Итак, он говорит, что он говорит: "Сократить среднее время обработки срочных запросов на рассмотрение претензий с 2 дней до 1 часа в течение 90 дней после запуска". Так что это очень конкретно. Это измеримо, потому что говорится, что время обработки должно составлять 1 час. Это кажется достижимым, потому что ИИ будет в процессе, так что, надеюсь, любой сбор информации, получение первоначальной рекомендуемой рекомендации будет быстрее. Это очень релевантно и основано на предыдущей бизнес-проблеме, и ограничено по времени, потому что дает вам окно, когда мы должны начать видеть успех.
Хорошо, на этом этапе мы выяснили "что". Давайте посмотрим на "как". Первое, о чем вы хотите подумать, — это ваша стратегия работы с данными. Какие данные нужны вашему приложению? Есть ли у вас вообще к ним доступ? Где они находятся? Готовы ли они к потреблению в сыром виде, и так далее?
Итак, для нашего приложения рассмотрения претензий, это источники данных, которые нам могут понадобиться, где они находятся, и как могут выглядеть их сырые форматы доступа. Итак, нам нужны клинические рекомендации, вероятно, которые описывают, какой уход подходит для данного состояния. Политики покрытия MDB Health, которые указывают, что MDB Health будет и не будет оплачивать. И, наконец, история претензий пациента, чтобы знать любые прошлые состояния, выполненные процедуры, когда они были выполнены, и так далее.
Предположим, что клинические рекомендации и политики покрытия хранятся в виде PDF-файлов в чем-то вроде Confluence, а претензии хранятся в MongoDB по мере их обработки.
Следующее, о чем стоит подумать, — это частота обновления данных. Как часто обновляются источники данных? Теперь, если вы выполняете какую-либо обработку данных на этих сырых источниках данных, а вы обычно это делаете, эти конвейеры должны работать с правильной частотой, чтобы не отставать. В противном случае наша система будет работать на устаревшей информации, и это нехорошо, особенно в таком высокорискованном сценарии использования.
Итак, давайте проработаем это для нашей системы рассмотрения претензий. Клинические рекомендации, вероятно, обновляются ежегодно. Внутренние политики покрытия могут обновляться ежеквартально, а история претензий пациента должна обновляться каждый раз, когда обрабатывается новая претензия. И в наших метриках успеха, если вы помните, мы сказали, что хотим стремиться к 1-часовому сроку для рассмотрения срочных претензий, так что они, вероятно, будут обновляться ежечасно.
Далее, могут ли данные потребляться непосредственно нашим приложением, или они нуждаются в какой-либо обработке? Для клинических рекомендаций, которые обычно являются длинными документами, вы, вероятно, захотите разбить их на части, встроить эти части, а также извлечь метаданные, такие как названия процедур, даты публикации, чтобы сделать их пригодными для поиска с использованием чего-то вроде векторного поиска или гибридного поиска. То же самое относится и к политикам покрытия, но для истории претензий пациента, которая уже хорошо отформатирована и хранится в MongoDB, нам, возможно, придется просто удалить лично идентифицируемую информацию перед передачей ее в LLM.
Далее, мы хотим подумать о том, какие методы поиска лучше всего подходят для каждого из источников данных. И вы уже начинаете думать об этом на этапе обработки данных, но давайте быстро формализуем это. Теперь клинические рекомендации и политики покрытия хорошо подходят для векторного поиска, но они могут содержать медицинскую терминологию, такую как коды диагнозов, коды процедур, которые векторный поиск может не уловить. Так что, но они будут уловлены фильтрами метаданных или чем-то вроде поиска по ключевым словам. Так что для них вы либо захотите использовать векторный поиск с предварительной фильтрацией метаданных, либо гибридный поиск. Для получения истории претензий пациента вы можете выполнить точное совпадение по имени пациента или идентификатору, в зависимости от того, какой идентификатор пациента используется в системе.
Далее, вы хотите подумать о том, как выглядит архитектура системы. Теперь может возникнуть соблазн сразу же перейти к созданию агента. Вокруг них так много ажиотажа, или позволить кодирующему агенту решать, какой должна быть архитектура системы, но вы рискуете получить переусложненную систему, сделав это. Так что вместо этого вы хотите начать с самого простого дизайна, оценить его, найти пробелы во время оценки и итерировать оттуда.
Чтобы решить, как должна выглядеть система, давайте сначала наметим, как страховая претензия будет проходить через систему, потому что это поможет нам информировать архитектуру. Итак, сначала запрос на претензию и любые клинические заметки от врача поступают в нашу систему. Затем система должна извлечь любые клинические рекомендации и политики покрытия, которые относятся к текущей претензии, а также извлечь историю претензий пациента. Затем вся эта информация, наряду с самой претензией и любыми системными подсказками о том, как LLM должна генерировать рекомендации, все это передается LLM, и она использует их для генерации рекомендации о том, следует ли одобрить или отклонить претензию.
Теперь, если это сложный случай, наша система или LLM в этот момент должны отправить свою первоначальную рекомендацию старшему врачу. И если рекомендация LLM — отклонить претензию, то она также должна быть передана человеку-медицинскому рецензенту. И, наконец, окончательное решение должно быть занесено в MongoDB, где мы храним наши документы о претензиях, вместе с обоснованием, почему претензия была одобрена или отклонена.
Теперь давайте поговорим о некоторых наиболее распространенных шаблонах проектирования ИИ, которые мы видим в системах ИИ сегодня, и посмотрим, какие из них могут применяться к нашей системе.
Итак, первое — это RAG, сокращение от Retrieval Augmented Generation. Вы все, вероятно, знаете это к этому моменту. В основном, в этих системах вы просто дополняете предварительно обученные знания LLM внешними источниками знаний. То есть информацией из внешних источников знаний.
Затем есть ИИ-агенты, где вы даете одному LLM или нескольким LLM в случае многоагентных систем полную автономию для выполнения задач от начала до конца с помощью набора инструментов.
А затем есть агентные системы, которые охватывают широкий спектр полуавтономных систем ИИ. Распространенным архитектурным шаблоном для таких систем являются управляемые потоки, где LLM выполняют определенные задачи в рабочем процессе, но последовательность шагов в самом рабочем процессе предопределена дизайном или кодом.
Затем есть LLM как маршрутизатор, где LLM имеют ограниченную автономию, поскольку их задача просто заключается в категоризации входящих запросов и их маршрутизации в различные последующие рабочие процессы.
Затем у вас есть человек в цикле, где LLM или агент могут выполнять определенные действия, но им требуется вмешательство человека где-то в процессе.
И, наконец, есть дообучение. Так что, если вы наблюдаете, что сбои LLM являются поведенческими, а не проблемами данных или оркестрации, или если вам нужна превосходная производительность в доменно-специфичной задаче, то дообучение — это хороший метод для изучения.
У меня нет времени углубляться в это здесь, но если вы хотите узнать больше об этих шаблонах проектирования, я оставлю этот ресурс для вас, чтобы вы могли ознакомиться с ним позже.
Итак, мы продумали, как должен выглядеть рабочий процесс этой системы. Мы говорили о нескольких различных шаблонах проектирования ИИ. Теперь давайте применим их и решим, какие шаблоны проектирования нам нужно реализовать для нашей системы.
Итак, поскольку нам нужно извлекать клинические рекомендации, политики покрытия и прочее для информирования решения, это определенно похоже на компонент RAG. Так что нам нужна какая-то форма RAG. Рабочий процесс предопределен тем, что LLM сначала предоставляет свою рекомендацию о том, следует ли одобрить или отклонить претензию, и в очень специфических и четко определенных случаях она должна передавать претензии на рассмотрение человека. Так что это звучит как управляемый рабочий процесс. Вы также можете утверждать, что это немного похоже на LLM как маршрутизатор, особенно если вы используете дополнительный вызов LLM, чтобы определить, что такое сложный случай, если это уже не четко определено. Так что, да, это может быть LLM как маршрутизатор, но пока давайте просто остановимся на управляемом потоке. И, наконец, есть также элемент человека в цикле, верно? Поскольку люди-рецензенты являются очень важной частью рабочего процесса.
И, наконец, на этапе проектирования вы также хотите подумать о пользовательском опыте и о том, как вы будете собирать обратную связь от ваших пользователей для улучшения системы. Вот несколько вопросов, которые стоит задать себе на этом этапе, чтобы помочь продумать, как должны выглядеть UX и механизм обратной связи.
Итак, во-первых, что система принимает в качестве входных данных? В нашем случае это будет форма запроса на претензию какого-либо рода. Затем, что система производит в качестве выходных данных? Итак, в нашем случае это будет вердикт об одобрении или отклонении вместе с объяснением, почему претензия была одобрена или отклонена. Где находится система? Есть ли у нее отдельное приложение? Встроена ли она в существующий веб-сайт? Это бот Slack? И так далее. Итак, для нашего приложения, скорее всего, оно будет встроено в основной веб-сайт MDB Health, скажем. Что запускает систему? Итак, в нашем случае, совершенно очевидно, подача претензии. Какова роль человека? Итак, в нашем случае они будут рассматривать оценку системы и принимать окончательное решение в некоторых случаях. Как система объясняет себя? В нашем случае она объясняет себя, предоставляя цитаты, то есть цитируя клинические рекомендации и политики покрытия, которые информировали оценку системы. И, наконец, как она дает обратную связь? Итак, помните, для нашей системы потребителями являются медицинские рецензенты. Так что они могут предоставлять обратную связь, переопределяя вердикт LLM, а также регистрируя причину, почему. Они также могут, возможно, пометить любые неуместные цитаты. Так что, если их LLM галлюцинирует клинические рекомендации и политики или цитирует неправильные для конкретной претензии, тогда мы можем пометить их как таковые.
Хорошо. Итак, на этом этапе мы решили, как должна выглядеть архитектура нашей системы, но нам также нужно решить, как будет выглядеть наш стек. Опять же, может возникнуть соблазн иметь кодирующего агента, рекомендующего, какие инструменты использовать, но они не обязательно могут подходить для вашей системы, или вы можете не иметь возможности их использовать на основе ограничений, которые мы определили на этапе требований к продукту. Так что у нас были ограничения на то, что модели должны поддерживаться нашим облачным провайдером и тому подобное. Я не буду вдаваться в это слишком сильно, поскольку наши ограничения, ну, гипотетические, но я просто хочу упомянуть, что это следующий шаг и различные решения по инструментам, которые нужно принять, такие как какая модель будет использоваться. Существует множество инструментов для обработки данных, которые имеют хорошие возможности обработки данных "из коробки". Если извлечение является частью вашей системы, и вы используете что-то вроде векторного поиска, то вам, возможно, придется решить, какие модели встраивания использовать, какую векторную базу данных использовать. Затем есть фреймворки оркестрации и так далее. Так что я просто оставлю это здесь для справки позже.
Далее, давайте поговорим об оценке и мониторинге. Как вы узнаете, что то, что вы построили, работает до и после отправки? Итак, оценка — это до, мониторинг — это после отправки, и вам нужны оба. Но прежде чем перейти к метрикам оценки, давайте поговорим о защитных механизмах, потому что до LLM их на самом деле не было. Причина, по которой они стали предметом обсуждения, заключается в том, что, в отличие от традиционного программного обеспечения, системы на основе LLM являются вероятностными системами и могут выдавать неожиданные, неправильные или даже вредные результаты. И защитные механизмы — это попытка снизить эти риски и обеспечить, чтобы ваша система вела себя в допустимых пределах. И каковы эти пределы — это то, что вам нужно определить.
Итак, для входных данных вашей системы цель обычно состоит в том, чтобы обнаружить недопустимые, неуместные или вредные входные данные. Так что для нашей системы рассмотрения претензий такой ввод, как "напиши мне стихотворение", неуместен, и наша система должна отклонить эту претензию. Аналогично, для выходных данных цель состоит в том, чтобы обнаружить недопустимые, неправильные или галлюцинированные или вредные выходные данные. Так что для нашего приложения претензий мы будем считать ответ недопустимым, если система не предоставляет цитаты для того, что информировало одобрение или отклонение.
Теперь соответствие защитным механизмам — это не единственное, что вы хотите измерить. Вы хотите измерить качество ответов, создавать и измерять доменно-специфичные метрики точности, а также общее состояние системы.
Итак, для соответствия входным защитным механизмам, для нашей системы мы можем рассчитать коэффициент отклонения претензий. Как часто наша система отклоняет претензии, потому что они не соответствуют нашим входным защитным механизмам? Теперь, если она отклоняет слишком часто, то это повод для расследования, но если вы не измеряли это в первую очередь, то вам нечего будет расследовать, так что вот оно. Вот почему вам нужны метрики.
Для соответствия выходным защитным механизмам мы можем иметь что-то вроде коэффициента отсутствия цитат, сколько раз LLM выдает ответы без цитат. Для качества ответов мы можем измерить верность, то есть является ли одобрение или отклонение претензии фактически основанным на извлеченной информации, такой как клинические рекомендации и политики. Затем вы хотите определить по крайней мере одну доменную или специфичную для приложения метрику. Так что в нашем случае, что-то вроде времени обработки претензии может быть хорошим, потому что это действительно наша главная цель. И метрики на уровне системы обычно связаны с общим состоянием системы. Так что, какова средняя стоимость токенов вашей системы, использование токенов, среднее количество ходов в разговоре. Так что здесь, чтобы не иметь еще одной метрики задержки, я указал что-то вроде стоимости за рекомендацию.
Теперь, когда вы оценили свою систему и отправили продукт пользователям, наступает этап мониторинга системы на предмет регрессий в реальном времени. Теперь, в производстве, вы все еще хотите отслеживать метрики, которые вы использовали для офлайн-оценки, то есть метрики, о которых мы говорили, но вы также можете отслеживать дополнительные метрики, которые могут служить неявными индикаторами успеха вашего продукта или того, насколько счастливы пользователи вашим продуктом и общим состоянием системы.
Например, для приложения рассмотрения претензий вы можете отслеживать, как часто человек-рецензент переопределяет вердикт ИИ. Теперь вы хотите, чтобы этот коэффициент был низким, потому что это означает, что система не выполняет свою работу. Так что, если вы когда-нибудь начнете видеть, что он увеличивается выше определенного порога, вам нужно будет пойти и расследовать. Или вы можете отслеживать, например, сколько времени требуется человеку, чтобы рассмотреть рекомендацию ИИ. Если это занимает слишком много времени, что означает, что ответы могут быть очень многословными, запутанными. Так что, да, это были бы хорошие индикаторы для отслеживания после отправки вашего продукта в производство.
Теперь, как только у вас есть рабочий прототип, который вы оценили, точность выглядит хорошо, пора переходить к производству, верно? Ну, а как насчет затрат, задержки и надежности? Эти ограничения становятся абсолютно не подлежащими обсуждению, когда вы переносите свой продукт в производство. Так что вам, возможно, придется сделать еще несколько итераций, оценок и тестирований между "точность выглядит хорошо" и "переход к производству".
Итак, давайте поговорим о некоторых методах оптимизации для каждого из них. Оптимизация точности. В приложениях на основе LLM это сводится к оптимизации информации, которая попадает в контекстное окно LLM. И вот некоторые методы, которые вы можете использовать позже, но давайте быстро поговорим о том, какие из них могут применяться к нашему приложению рассмотрения претензий.
Инженерия подсказок, конечно. Переранжирование — это еще один хороший вариант, потому что извлечение является его важной составляющей. Так что переранжировщик убедится, что извлекаемая информация располагается в правильном порядке релевантности, что важно при работе с LLM. Мы также сохраняем историю пациента в MongoDB, так что у нашего приложения уже есть некоторая форма памяти, но вы также можете подумать о других типах информации, которые могут быть полезны для сохранения между сессиями.
Вот методы оптимизации затрат и задержки. Для нашего сценария использования семантическое кэширование может быть полезным для ускорения принятия решений на основе аналогичных претензий из прошлого. Пакетная обработка, возможно, для обработки претензий пакетами, а не по одной.
И, наконец, оптимизация надежности. Большинство из них будут полезны для нашего сценария использования, поскольку они в основном решают проблемы сбоев API, но я хочу особо выделить структурированные выходные данные, которые были бы хорошим способом убедиться, что наша система всегда выдает структурированный вывод, который содержит не только решение, но и цитаты.
Это подводит меня к концу моего выступления, но я хотел бы оставить вам несколько ключевых выводов. Глубоко продумайте требования к вашему продукту, прежде чем ИИ будет генерировать какой-либо код. Спецификация продукта — это теперь сложная часть, а не код. Ваш бюджет задержки, ваш предел затрат, любые нормативные требования — все это формирует каждое архитектурное решение впоследствии. Так что полезно определить бизнес- и производительные ограничения, прежде чем начинать проектировать ваше приложение.
Разрабатывайте простейшую систему, которая соответствует вашим потребностям. Оцените ее, а затем итерируйте. Самая распространенная ошибка, которую я вижу, — это переусложнение решения, прежде чем узнать, что на самом деле не работает, или даже не оценивая, что на самом деле не работает. И это подводит меня к оценке. Встраивайте оценку с самого начала. Вы не можете улучшить то, что не можете измерить.
Ссылка на наш сборник рецептов GenAI, который содержит множество примеров различных методов извлечения, агентных шаблонов проектирования, а также некоторых методов оценки и оптимизации, о которых я говорил. И да, спасибо большое за то, что уделили время прослушиванию моего выступления. Увидимся на конференции. >> конференция.