Комментарии 29
Вы бодались с "медицинским распознаванием" человеческой речи, вместо того, чтобы формализовать ввод описания, и заниматься именно анализом для постановки диагнозов, я так понял.
А лучше бы сделали систему ввода симптомов в виде жесткого шаблона (как в игре "кто\с кем\когда\как\что делали"):
Что ? Список сущностей: рука, нога, нос, позвоночник ....
Что происходит ? Список глаголов\состояний: болит, кровоточит, ноет, покрывается чем-то....
Где ?
В какое время ?
При каких доп. обстоятельствах ?
Ссылка на уже введенную сущность - связь вводимых симптомов\сущностей.
...
И пациент по такому шаблону вводит 3...10.... фраз итерационно. Т.е. надо было исключить вообще произвольный ввод текста.
Ну и сосредоточится на анализе введенных шаблонов.
Похоже, они упёрлись в непонимание, как собираются жалобы и анамнез. Вначале человек пишет неструктурированный текст о причине обращения, потом на базе этого нужна серия наводящих вопросов из алгоритма сбора анамнеза под основные нозологии.
Так работает врач. Так понятно пациенту. И это создаёт большую уверенность у пациента, что бот поможет найти правильного врача и увеличивает конверсию.
Такой подход, конечно, возможен, но в случае если человек не пишет никакой текст от себя, то на первом этапе у нас слишком много вариантов - основных сущностей несколько десятков, и даже самых распространённых из них довольно много.
Кроме того, как написал DASpit, итеративный опрос понятен пациенту, а выбор значений в жестких шаблонах может вызвать непонимание и недоверие.
Медицинские экспертные системы — это хорошо, это прекрасно, они могут диагностировать проблему лучше 90% врачей. Но они теряют всякий смысл, если им на вход подавать мусор в виде якобы распознанного текста.
Может, это и вызывает большее доверие у какой-то части ЦА — например, бабушек и дедушек. Но тогда возникает вопрос к этичности такого проекта.
Дак интерактивности сколько угодно, к примеру вот так, последоватально:
1. Выберите: на что жалоба ? {список фиксированных сущностей для выбора}
2. Пациент: позвоночник
3. Система анализирует ввод, подбирает облако тэгов связанных со словом "позвоночник"
4. Выберите: позвоночник: что с ним происходит ? {список фиксированных глаголов\состояний для выбора}
5. Пациент: болит
6,7) Выберите: позвоночник: болит: где (сверху, снизу, слева, справа)?
8) Система далее подбирает облако тэгов суммарно по всем введенным сущностям, задавая дальнейшее переменное кол-во вопросов в зависимости от найденных тэгов
...
35) Когда уже надоедает - пациент жмет кнопочку постоянно видимую "Закончить ввод симптомов"
36) Система анализирует всё полученное
37) Диагноз: понос :)
Я когда-то делал приложение Android "Что и как" (how4what), где техзадание составляется короткими фразами максимум по 5 слов во фразе, где на каждой следующей итерации надо описывать 5ю словами каждое введенное на предыдущей итерации слово - и без всяких нейросетей очень быстро заканчивается список слов для описания желаемого.
Хотя в медицине, вероятно, можно долго жаловаться на болячки... :)
Что-то странное вы наворотили. Обычной экспертной системы с баессовскими фильтрами хватило бы, чтобы отправить человека в терапевту или врачу общей практики - по стандарту всё, кроме травм, через них первично и проходит.
Ваш проект напомнил capstone project в рамках Data Science specialization на Курсере, чистка и подготовка данных занимает гораздо больше времени и отнимает больше сил, чем собственно моделлирование. Работая с подобными данными на разных языках быстро стало понятно что, во-всяком случае из коробки, все работает сильно лучше на английском.
По опыт внедрения AI \ DS систем на практике неоднократно поднималось два вопроса: 1) отсутствие объяснения "почему" алгоритм классифицировал так-то и так-то вводные данные 2) понятное не желание конечного пользователя общаться с ботами вообще. Как с телфонными так и с он-лайн, значительная часть пользователей сразу пытается использовать short-cuts которые вывели бы на оператора (типа жать 0 в меню выбора департаментов и т.п.) Если "фильтр" в лице бота или меню на телефоне больше 2-3х уровней пользователи просто уходят. И это еще не в медтехе, в медтехе подозреваю всё еще суровее. Делали ли вы какой-то анализ на этот счет?
Мы в итоге пришли к другой парадигме - dimensions reduction, если грубо - анализировать поток сознания пользователя (или поток данных от множества датчиков) что бы выделить несколько наиболее вероятных кластеров (или сжать многомерное облако множества переменных) до чего-то удобоваримого для специалиста в данной области. Пользователь ничего этого не видит, но специалист получает синтез \ вероятные векторы для анализа. В медтехе опять же не было проектов, были в индустрии \ на производстве.
Спасибо за ответ, Ваш опыт звучит интересно!
Согласен, что из коробки на английском больше рабочих инструментов, но, к сожалению, из-за особенностей домена и русского языка не было возможности их использовать.
Если "фильтр" в лице бота или меню на телефоне больше 2-3х уровней пользователи просто уходят. И это еще не в медтехе, в медтехе подозреваю всё еще суровее. Делали ли вы какой-то анализ на этот счет?
Да, анализировали - в связи с этим были сделаны разнообразные ограничения, например:
ограничивать количество показываемых вариантов ответа. Например, мы не можем спросить человека "что у Вас болит" и показать 150+ вариантов ответа - никто не будет все их просматривать. Поэтому была сделана иерархическая структура, чтобы на каждом шаге показывать небольшое количество вариантов ответа;
именно для упрощения интерфейса ввели возможность ввода ответа в свободной форме;
старались минимизировать количество вопросов, задаваемых пользователю. Большинство людей будет готово ответить на несколько вопросов, но если их будет 20+, то многие бросят это;
анализировать поток сознания пользователя (или поток данных от множества датчиков) что бы выделить несколько наиболее вероятных кластеров (или сжать многомерное облако множества переменных) до чего-то удобоваримого для специалиста в данной области.
К сожалению, такой вариант нам не подходил: обычно люди не пишут всю необходимую информацию (пациент скорее всего напишет "вот у меня вчера нога заболела", а не "у меня сильная боль в лодыжке второй день при ходьбе"), и если брать только написанный ими текст, то врачу всё равно прийдётся доопрашивать пациента, а значит чат-бот теряет изначальный смысл.
А не было идеи перевести входные данные на английский, работать уже дальше на нем, а в конце перевести диагноз? Это наверное сильно уменьшило бы количество проблем хотя бы с датасетом.
Участвовал в одном проекте, там все-таки предлагались варианты для пользователя:
Edema, lasts for minutes - Отек, длится минуты
Edema, lasts for hours - Отек, длится часами
Edema, lasts for days - Отек, длится несколько дней
Edema, increases while in a sedentary position - Отек, усиливающийся при сидячем положении.
...
Edema, exacerbated by increased intake of salty food - Отеки, усугубляющиеся повышенным потреблением соленой пищи.
Простите, может в статье было (вы меня потеряли где-то на нейронках). А после формализации входных данных, как вы получили соответствие "симптомы - врач" и "симптомы - диагноз"? Или где-то есть такой датасет? ;)
Это хороший вопрос :)
Изначально у нас была идея попробовать получить такой датасет у поликлиник (что само по себе сложно из-за того, что это персональные данные), а потом считать на нём статистики (что, например, если человек жалуется на боли в горле, то с вероятностью N% это ангина). Но при таком подходе нам обязательно сразу иметь модели NER высокого качества или делать полную разметке таких датасетов на все сущности. Сделать это было нереально на тот момент.
Поэтому мы использовали другой подход: врачи-эксперты вручную составляли таблицы взаимосвязей между симптомами и врачами/диагнозами и ставили коэффициенты на основе своего опыта. Это не так масштабируемо, но зато надёжно, понятно и легко редактируемо.
Такие проекты надо начинать с CJM, с пути пользователя и с точками на этом пути. И очень быстро станет ясно, что этих точек не так много - ровно столько, сколько есть врачей общей практики в поликлинике. И то, по каким сценариям работают эти врачи. А врачей не так то и много и они легко разделяются одним простым вопросом: "<Болит горло - к лору, болит нога - к хирургу, болит голова - к неврологу". И нет смысла пытаться определить, фарингит у него или ларингит - всё равно врач будет осматривать заново на месте и писать свой диагноз, а не ориентироваться на то, что там человек накликал в чат-боте. Детали диагноза человек всё равно сам не опишет - ну болит у него спина, тут без специалиста не понять - мышечный это спазм, нервный или ушиб какой. Тут всё равно терапевт нужен. А прийти к хирургу с нервной болью, чтобы он молча перенаправил тебя к неврологу - это уже потеря ожидаемой экономии на осмотре. То есть вся инновационная идея ИИ разобьётся о то, как законодательно регламентирована медицинская деятельность и как работают врачи в реальности.
«мучаюсь очень сильными головными болями, иногда даже темнеет в глазах от боли». Слово «болями» является сущностью «боль». А вот слово «боли» в конце не является сущностью «боль» — это скорее условие при котором темнеет в глазах
по моему у вас изначально не совсем правильный подход решению.
думаю, что для решения подобных задач нужно решать общую задачу построения синтаксического графа/дерева предложения.
и не именно в области медицинской тематики, а вообще в языке, в данном случае русском.
плюс медицинская тематика добавит проблем с массой ошибок в написании: «фарингит/форингит/фаренгит/форенгит/..» — кто знает, как это пишется?))
В самом начале (ещё до моего прихода) как раз пробовали строить синтаксические деревья, но они очень плохо работали на медицинских терминах и при опечатках, которые делали пользователи.
А Вы сравнивали с вариантом "нанять 10 опытных терапевтов из заМКАДЬя или интернов, посадиить их на телефон и пусть собирают анамнез"? Это не дешевле? Как говаривал Илон Маск "Люди недооценены"
Очень интересная статья.
Ваш проект очень похож на цифровой ассистент по обработке обращений граждан, который создает наша команда уже почти год в Государственном Архиве РФ.
Сложность проекта в том, что ответ чатбота должен быть однозначным и 100% достоверным. Вопросы граждан состоят из множества смыслов, так называемые мультиинтентные.
Наша команда практически на 99% состоит из сотрудников архива, не являющихся ИТ-специалистами. Зато, каждый член команды является экспертом по своей тематике и формирует по ней датасеты, включающие наборы сущностей, стоп-слова, размеченные сущностями типовые запросы и ответы. После этого каждый проектирует свой чатбот. Существует мастер чатбот, который объединяет порядка 12 тематических чатботов.
Мы решаем задачу постепенно:
на первом этапе подключили ответы на наиболее часто задаваемые вопросы;
второй этап состоит в реализации диалогов на основе предварительно выявленных смыслов;
на третьем этапе - автоматическое проактивное дополнение датасетов из архивных данных, ранее созданных датасетов и самообучение чатбота этими данными
Подчеркну очень важный момент нашей работы - создание Датасетов, обучение и тестирование чатботов ведут сами архивные сотрудники, владельцы данных. Они фактически создают своих цифровых двойников и максимально заинтересованы в результате.
Попробуйте сформировать такую команду из экспертов и у Вас получится :)
Это звучит очень интересно! И я вполне согласен, что привлечение большего количества экспертов заметно помогло бы работе над проектом. Увы, у меня не было инструментов для продавливания такого решения.
По сути это действительно организационное решение.
Но мы к нему пришли не сразу.
В нашем случае, мы вначале обратились к ведущим национальным центрам ИИ и предложили сделать пилоты на основе наших Датасетов. Результат полугодовой работы был отрицательным для всех поставщиков отечественных решений.
Мы поняли, что гарантированно правильные ответы можно получить только, если чатбот будут обучать и проектировать владельцы данных, но не ИТ-шники.
Я в большинстве случаев знаю к какому врачу я хотел бы попасть. Или имею набор из двух-трёх вариантов. Может быть стоило начинать с вопроса: "А какой врач вам нужен? " И затем "почему? " С вариантами ответа. Многие имеют хронические заболевания и знают куда с ними идти. С кожными заболеваниями тоже не так много вариантов. Разного рода спортивные и бытовые травмы - вполне себе ясные точки входа. Ну и вариантц по сбору анамнеза у каждого специалиста поуже будут. Это похоже будет уже на вариант коллеги из архива, описанный выше.
Я очень не люблю общаться с ботами, которые начинают сильно из далека. Очень часто я уже имею чёткий и ясный запрос. Однако бот заставляет меня проходить меня какие-то варианты от рождения вселенной. Стараюсь перключить на реального человека
С интересом прочитал статью, жаль, что просела продуктовая часть. Тут стоило бы применить дымовое тестирование. Как предлагали выше, посадить интернов для того, чтобы обрабатывать такие запросы в реальном времени. Но не потому, что так дешевле, а для того, чтобы сформировать внятные метрики успеха и функциональные требования к системе. И посмотреть как люди будут ей пользоваться.
Как мы не смогли создать медицинского чат-бота. История проекта, который так и не увидел свет