Transcription
[Музыка] Всем привет. Я Кристофер Лавджой. Я врач, ставший инженером по искусственному интеллекту, и я собираюсь поделиться руководством по созданию нативного для домена LLM-приложения. Я около восьми лет обучался и работал врачом, а затем последние семь лет занимался созданием систем ИИ, которые включают медицинскую экспертизу. Я делал это в нескольких различных стартапах. Я работал в технологическом стартапе в сфере здравоохранения под названием Serakare, занимаясь технологически обеспеченным уходом на дому. Недавно стартап достиг годового оборота в 500 миллионов долларов. Я работал в различных других стартапах, и в настоящее время работаю в Anterior. Anterior — это нью-йоркская компания, возглавляемая клиницистами. Здесь мы предоставляем инструменты клинического обоснования для автоматизации и ускорения администрирования медицинского страхования и здравоохранения. Мы обслуживаем около 50 миллионов, мы обслуживаем поставщиков медицинского страхования, которые покрывают около 50 миллионов жизней в США. И мы много времени уделяем размышлениям о том, что означает создание нативного для домена LLM-приложения, будь то в здравоохранении или в других областях. И именно об этом я собираюсь говорить сегодня. И, в частности, наша ставка заключается в том, что, когда дело доходит до вертикальных приложений ИИ, система, которую вы создаете для включения ваших доменных знаний, гораздо важнее, чем сложность ваших моделей и ваших конвейеров. Таким образом, ограничением в наши дни является не то, насколько мощна ваша модель и может ли она рассуждать на нужном вам уровне. Скорее, может ли ваша модель понять контекст в этой отрасли для конкретного клиента и выполнить необходимое рассуждение, а способ, которым вы это обеспечиваете, и способ, которым вы быстро итерируете с вашими клиентами, заключается в создании системы вокруг нее, и у этого есть различные компоненты, о которых я собираюсь говорить. Итак, это высокоуровневая схема, и мы пройдемся по каждой из этих частей на протяжении всего выступления. Как вы увидите, прямо посередине находится менеджер по продукту, и, по нашему опыту, имеет смысл, чтобы это был менеджер по продукту, являющийся экспертом в домене. В нашем контексте это клиницист, и я скоро более подробно рассмотрю это. Но сначала я думаю, что стоит сделать быстрый шаг назад и спросить, почему так сложно успешно применять большие языковые модели к специализированным отраслям. Мы думаем, что это из-за проблемы последнего мили. И под проблемой последнего мили я подразумеваю проблему, на которую я только что намекнул, связанную с предоставлением модели и вашей системе ИИ в целом контекста и понимания конкретного рабочего процесса для этого клиента, для этой отрасли. И я проиллюстрирую это примером из клинического случая, который мы обработали. Наш ИИ Anterior называется Флоренс, и 78-летняя пациентка обратилась с болью в правом колене. Врач рекомендовал артроскопию коленного сустава, и, чтобы решить, было ли это лечение подходящим, было ли решение врача правильным, Флоренс должна ответить на различные вопросы. Один из этих вопросов: есть ли документация о безуспешной консервативной терапии в течение как минимум шести недель? И, на первый взгляд, это может показаться относительно простым. Я понимаю, что, возможно, в зале не так много врачей, поэтому вы можете не знать, что такое консервативная терапия, но на самом деле есть много скрытой сложности в ответе на такой вопрос. Например, консервативная терапия обычно означает, что есть какой-то вариант более агрессивного лечения, возможно, хирургическая операция, это как бы хирургическое лечение. А затем, если вы решаете не оперировать и хотите сначала попробовать что-то консервативное, это как бы консервативная терапия. Так что это может быть, например, физиотерапия, снижение веса, какие-то неинвазивные вещи, которые могут помочь решить проблему. Но на самом деле есть некоторая неопределенность, потому что в некоторых случаях прием лекарств может быть консервативной терапией. В некоторых случаях это на самом деле более агрессивное лечение, а есть что-то еще более консервативное. Так что здесь есть один уровень неопределенности. Затем, когда мы говорим о безуспешности, ну, что такое безуспешность? Допустим, у кого-то есть боль в колене, он проходит какое-то лечение, и его симптомы значительно улучшаются, но они не полностью исчезают. Так это успешно? Нужна ли нам полная ремиссия симптомов, или достаточно частичной ремиссии? Если частичная, то в какой момент этого достаточно, чтобы квалифицировать как успешное? Так что снова есть сложность и нюансы в том, как это интерпретируется. И, наконец, документация в течение как минимум шести недель. Опять же, документация. Мы говорим, что в медицинской карте указано, что они начали физиотерапию 8 недель назад, а затем она больше не упоминается? Можем ли мы поэтому предположить, что они делали это в течение 8 недель? Или нам нужна явная документация о том, что они начали лечение, делали это в течение 8 недель, и оно завершено? Где мы проводим черту в отношении того, что мы можем вывести? И, да, просто чтобы повторить нашу мысль. Это действительно наша ставка на то, что система важнее. Мы считаем, что в каждой вертикальной отрасли команда, компания, которая побеждает, — это та, которая создает лучшую систему для получения этих доменных знаний и быстрого их преобразования в конвейер, предоставления этого контекста и итерации для создания этих улучшений. И мы также, я думаю, чтобы возразить этому, модели, я имею в виду, модели, очевидно, важны. И прогресс в моделях облегчает наличие хорошей отправной точки, но это только до определенного базового уровня. И мы обнаружили, что мы достигли насыщения около 95%. Поэтому мы вложили много времени и усилий в улучшение наших конвейеров. Очевидно, 95% — это все еще довольно неплохо. И это выполнение основной задачи, которую выполняет наша система ИИ, — одобрение запросов на уход в контексте медицинского страхования. Итак, у нас 95%, и затем мы итерировали на основе этой системы, которую я собираюсь описать, и мы действительно достигли почти смешной точности в 99%. Мы получили эту награду несколько недель назад за это. И на самом деле, что мы обнаружили здесь и что мы наблюдали, это то, что модели рассуждают очень хорошо. Они достигают отличного базового уровня. Но если вы находитесь в отрасли, где вам действительно нужно выжать этот последний километр производительности, вам нужно иметь возможность затем предоставить модели, конвейеру этот контекст. Итак, как мы это делаем? Мы называем это нашим адаптивным движком доменного интеллекта. И то, что он выполняет, — это получение специфических для клиента доменных знаний и их преобразование в улучшения производительности и создание системы вокруг этого. И у этого есть две основные части. Первая часть — это измерение. Итак, как работает наш текущий конвейер? А остальное — это сторона улучшений. Итак, я сначала немного подробнее расскажу об измерениях, а затем немного об улучшениях. Измерение производительности в конкретной области. Первое, и я думаю, что многое из этого — это просто лучшая практика в целом, но первый шаг — определить, что действительно волнует ваших пользователей в качестве метрик. В контексте здравоохранения, очевидно, я говорил об обзорах медицинской необходимости, это наш хлеб с маслом, и здесь клиенты действительно заботятся о ложных одобрениях. Они хотят минимизировать ложные одобрения, потому что ложное одобрение, когда вы одобрили уход, означает, что пациент, которому не нужен был уход, может получить какой-то уход, который ему не нужен, и, очевидно, с точки зрения страховой компании, они платят за лечение, за которое они не обязательно хотят платить. И часто определение этих метрик — это сотрудничество между экспертами в домене вашей компании и клиентами, чтобы действительно перевести, какие метрики вас волнуют. Это могут быть одна или две, или обычно есть всего несколько метрик, которые имеют наибольшее значение. Так что в нескольких других отраслях, таких как юридическая, при анализе контрактов, возможно, вы действительно хотите минимизировать количество пропущенных критических терминов при идентификации этих положений в контракте для обнаружения мошенничества. Ваша основная метрика может быть чем-то вроде предотвращения убытков от мошенничества. В образовании вы можете захотеть оптимизировать улучшение результатов тестов. Я думаю, что это определенно полезное упражнение — заставить себя подумать, если я оптимизирую для одной или двух метрик, какая метрика является наиболее важной. И затем вы можете сделать это рука об руку, что очень полезно, немного отклоняясь от нижней части, но это разработка онтологии режимов отказа. И под этим я подразумеваю выполнение задачи и определение всех различных способов, которыми ваш ИИ терпит неудачу, и это может быть на уровне высших категорий, например, здесь у нас есть извлечение медицинских записей, клиническое рассуждение и интерпретация правил. Мы обнаружили, что для обзора медицинской необходимости это три широкие категории, три широких способа, которыми ИИ может потерпеть неудачу, а затем внутри них есть различные подтипы. И это итеративный процесс. Есть различные методы для этого. Я думаю, что здесь важно привлечь ваших экспертов в домене. Я думаю, что один режим отказа заключается в том, что кто-то смотрит на ваши трассировки ИИ в изоляции и приходит к этим выводам, не имея при этом контекста о том, как все работает. Я думаю, что это критический шаг, чтобы эксперты в домене возглавляли этот процесс. Но на самом деле, я думаю, что большая добавленная стоимость возникает, когда вы делаете и то, и другое одновременно, потому что это дает вам, и это панель инструментов, которую мы создали внутри компании. Я понимаю, что текст может быть немного мелким, но, по сути, справа у вас есть медицинская карта пациента. У вас также есть руководящие принципы, по которым оценивается карта. Слева — выходные данные ИИ. Итак, это принятое им решение, обоснование его решения, и мы позволяем нашим экспертам в домене здесь, нашим клиницистам, приходить, отмечать, правильно это или неправильно, и если неправильно, то это поле предназначено для определения режима отказа. Таким образом, из онтологии, которую мы только что видели на предыдущем слайде, они могут сказать, что это потерпело неудачу таким образом, и одновременное выполнение этих действий и наличие вашего эксперта в домене в этот момент, делающего и то, и другое, очень ценно, потому что это позволяет вам понять такие вещи. Итак, на оси X у нас количество ложных одобрений. Это метрика, которая нас действительно волнует в нашем контексте. А затем у нас есть различные режимы отказа на оси Y. И, очевидно, это говорит нам, что если мы хотим минимизировать наши ложные одобрения и хотим оптимизировать эту главную цель, которая нас волнует, то именно их мы хотим решать в первую очередь, в таком порядке. Что, как менеджер по продукту, является полезной информацией для приоритизации работы, которую вы хотите выполнить. Итак, это сторона измерений. Теперь я собираюсь поговорить об улучшениях, особенно в этом доменном контексте. Итак, что еще дает нам эта маркировка режимов отказа, о которой мы говорили ранее, — это готовые наборы данных, против которых вы можете итерировать. И эти наборы данных очень ценны, потому что они поступают непосредственно из производственных данных, что означает, что вы знаете, что они репрезентативны для распределения входных данных, которое вы увидите, больше, чем синтетические данные. И теперь вы можете, когда вы видели эти приоритеты на предыдущем слайде, мы видели, какие режимы отказа вызывали наибольшее количество ложных одобрений. Вы можете взять этот набор данных из, скажем, 100 случаев, которые прошли через производственный режим отказа. Вы можете передать его инженеру. Инженер может итерировать против него, и вы можете продолжать тестирование. Как сейчас выглядит моя производительность против этого конкретного режима отказа? И это позволяет вам сделать что-то вроде этого, где на оси X у нас версия конвейера. На оси Y у нас показатель производительности. По определению, по этим сбоям мы начинаем очень низко для каждого из этих наборов данных режимов отказа, но каждый раз, когда вы увеличиваете версию конвейера, возможно, вы потратили некоторое время, сосредоточившись на этом конкретном режиме отказа, и вам удалось добиться большого скачка в производительности. А затем вы можете увидеть, как другие тоже растут, в последующих выпусках. И вы также можете использовать это, чтобы отслеживать, что вы не регрессируете ни по одному конкретному режиму отказа. Так что это полезная визуализация. И вы можете пойти еще дальше и фактически привлечь ваших экспертов в домене к процессу улучшений и итераций. И это выглядит как создание инструментов, которые позволяют эксперту в домене, который не обязательно является техническим специалистом, прийти. Они могут предлагать изменения в конвейере приложения. Они также могут предлагать новые доменные знания, которые становятся доступными для конвейера. И, очевидно, они лучше всего подходят для того, чтобы делать такие мнения о том, какие доменные знания могут быть актуальны. А затем у вас есть ваш конвейер посередине, готовый использовать их, если он захочет. И справа у вас есть эти доменные оценки, которые могут быть оценками режимов отказа. У вас также могут быть более общие наборы оценок, и они могут сообщить вам на основе данных, следует ли это предложение доменных знаний от эксперта в домене перейти в производственную версию платформы, и теперь она находится в производстве, и затем, конечно, она должна улучшать производительность для реальных клиентов. И весь этот цикл может происходить очень быстро. Например, и я думаю, что на следующем слайде, да, я просто покажу, так это панель инструментов, которую мы видели раньше, но это с этой дополнительной кнопкой, которая является кнопкой добавления доменных знаний. И снова мы сохраняем тот же контекст, у нас есть эксперт-клиницист, который приходит сюда, он просматривает случай, говорит, правильно ли это, неправильно ли это, говорит, какой режим отказа, и теперь он может сказать: я думаю, что эти доменные знания будут полезны для производительности приложения, и, возможно, я думаю, что в этом случае, хотя я понимаю, что это может быть не очень легко читаемо, модель делает какую-то ошибку, связанную с подозрением на состояние, потому что у пациента есть состояние, и говорится: «Нет подозрения на состояние», но на самом деле оно есть, и есть информация, которую можно предоставить модели для медицинского контекста того, как мы интерпретируем подозрительный или подозрение как слово, которое затем повлияет на ответ. Или может быть, что рассуждение использует какую-то систему оценки, и вы понимаете, что на самом деле у модели нет доступа к этой системе оценки. Вы снова можете добавить это как доменные знания, чтобы постоянно расширять возможности модели. И это помогает, да, с точки зрения скорости итерации, вы можете сделать это, возможно, вы хотите, чтобы ваши оценки автоматически позволяли это, или, возможно, вы хотите иметь какой-то человеческий контроль, но это просто означает, что у вас может быть этот очень быстрый процесс. Происходит производство, вы анализируете его с клинической точки зрения, а затем в тот же день вы, по сути, исправили это, добавив доменные знания, которые должны решить проблему. Вы можете доказать это с помощью оценок, а затем это будет в производстве. И это означает, что эти обзоры экспертов в домене, которые действительно обеспечивают большую часть информации, которую вы получаете, дают вам три основные вещи. Они дают вам метрики производительности, они дают вам эти режимы отказа и они дают вам эти предлагаемые улучшения — все в одном. Да. Да, хороший вопрос. Вопрос в том, как вы определяете эксперта в домене? Какой уровень экспертизы вам здесь нужен? Я думаю, что это действительно зависит от конкретного рабочего процесса, который вы выполняете, и от того, что вы оптимизируете. В нашем контексте, если вы оптимизируете для клинического рассуждения и качества клинического рассуждения, то вам нужен кто-то с как можно большим клиническим опытом, в идеале врач, желательно, чтобы у него был соответствующий опыт в той области, с которой вы имеете дело. Но это действительно зависит от вашего варианта использования. Возможно, есть и более простые вещи, которые мы также можем сделать, в этом случае такой уровень экспертизы не требуется, и вы могли бы иметь, скажем, более младшего клинического специалиста, но идея в том, что это либо медсестра, либо врач, либо кто-то, кто имеет опыт выполнения этого рабочего процесса в реальном мире. Это имеет смысл? Да. Еще один вопрос. Да. Это специализированные инструменты. И я думаю, что в целом моя философия заключается в том, что если вы действительно придаете большое значение тому, что вы генерируете, и это различными способами влияет на вашу систему, как я описывал, то, вероятно, имеет смысл делать это с помощью специализированных инструментов, которые вы создаете сами, потому что вы хотите интегрировать это с остальной частью вашей платформы, и это просто будет проще, если вы делаете все сами. Да. Являются ли ваши эксперты в домене пользователями? Чтобы они могли прийти. Да, отличный вопрос. Я думаю, что это может быть и то, и другое. По нашему опыту, мы обычно начинаем с найма нескольких сотрудников, которые приходят и делают это для нас, чтобы предоставить нам эти начальные данные, чтобы мы могли провести эту итерацию. Я думаю, что определенно существует мир, в котором сам клиент также может захотеть провести валидацию вашего ИИ, и они могут фактически выполнить этот процесс сами, в этом случае это становится клиентским продуктом для них. Да. Хорошо. Итак, мне нравятся вопросы, но мы оставим время для Криса, чтобы он продолжил. Звучит хорошо. И я просто, это последние несколько слайдов. Итак, собирая все вместе. Это общий поток, и, по сути, то, как это может выглядеть, это ваша производственная система. Она генерирует эти решения, эти выходные данные ИИ. Ваши эксперты в домене просматривают это, предоставляя эти сведения о производительности. Это такие вещи, как метрики, режимы отказа. Затем у вас есть ваш менеджер по продукту, ваш эксперт в домене, который находится посередине. Затем у него есть эта богатая информация о том, что мне следует приоритизировать на основе режимов отказа, на основе метрик. Затем он может обратиться к инженеру и сказать: я хочу, чтобы ты исправил этот режим отказа, потому что он меня действительно волнует, и я хочу, чтобы ты исправил его до этого порога производительности. Так что они могут сказать: прямо сейчас, в производстве, мы получаем 0% или 10% на этом конкретном наборе данных. Я хочу, чтобы ты ушел и поработал над этим, пока не получишь 50%. А затем инженер может провести различные эксперименты, иметь разные идеи о том, как они могут улучшить это, изменяя подсказки, изменяя модели, выполняя тонкую настройку, все это. Затем у них есть очень тесный цикл итераций, потому что у них есть эти готовые наборы данных режимов отказа. Они могут провести оценку. Они могут увидеть влияние этих оценок. А затем, когда они прошли этот цикл и достигают нужного процента, они могут вернуться к менеджеру по продукту и сказать: «Вот изменения, которые я внес. Вот их влияние». Затем менеджер по продукту может использовать эту информацию и принять решение о запуске. Они могут взять эти метрики оценки, они могут посмотреть на более широкий контекст того, как это изменение может повлиять на другие части продукта, а затем решить, запускать ли это в производство. Итак, окончательный вывод, чтобы подвести итог: чтобы создать нативное для домена LLM-приложение, вам нужно решить проблему последнего мили. Это не решается просто использованием более мощных моделей или более сложных конвейеров. Вам нужен адаптивный движок доменного интеллекта. Эксперты в домене могут питать эту систему, просматривая выходные данные ИИ для генерации метрик, режимов отказа и предлагаемых улучшений. И это очень мощно, потому что оно берет производственные данные в реальном времени из контекста вашего клиента и использует их для предоставления вашему LLM-продукту тонкого понимания рабочих процессов клиента и постоянной итерации к этому и выжимания конечного уровня производительности. И конечным результатом является этот самосовершенствующийся, основанный на данных процесс, которым может управлять менеджер по продукту, эксперт в домене, находящийся посередине. Спасибо за ваше внимание. Если вы интересуетесь вертикальными приложениями ИИ или оценками и управлением продуктами ИИ в целом, я писал об этом на своем веб-сайте chrislovejoy.me. Всегда интересно поговорить об этом. Так что не стесняйтесь писать по адресу chrisanser.com. И мы также нанимаем сотрудников прямо сейчас. Так что заходите на anio.com/comp, чтобы узнать об открытых вакансиях. Спасибо. [Музыка]