Вопрос не в онкологе. Не нужно переводить в данную плоскость. Потому что за врачём законодательно закреплена ответственность. В том числе и за врачебную ошибку. Но речь ведь не об этом. Про то, как доказать врачебную ошибку тоже отдельная тема. И никакого отношения не имеющая к тому что я написал.
Нежелание ответить относительно программного обеспечения и перевод в другую плоскость это часто встречающаяся практика в подобных дискуссиях. Я сам разработчик. И некоторое время работал с медициной. Существует пока что незрелая позиция разработчиков, которые считают, что их системы призваны заменить врача. На самом деле при этом в утверждениях больше слышится подменить. Но вреальости какую бы систему н использовал врач, он все-равно ответственное лицо. Не программа.
Ещё очень часто в подобных дискуссиях подменяют понятия неточности прибора и ошибки в логике программы. Которые, к тому же, могут быть неявными.
Опять же изучив огромное количество историй болезни система с высокой вероятностью предполагает, что такая-то методика лечения будет более эффективной. А я, вот, не хочу чтобы меня лечили с какой-то долей вероятности. В таких случаях многие врачи скажут, что система не соответствует клиническому мышлению. Его, кстати, никто не отменял. И именно ему учат врачей. Так что и система помощник должна опираться не только на большие даннве,. А, наверное, должна приближаться в своей логике к клиническому мышлению врача. Тогда, если я выпал из процента, можно избежать ошибки. Ведь речь идёт о здоровье.
Тогда отвечу вопросом на вопрос. А почему увидит? Это вопрос из практики, а не теории. Почему-то разработчики идеализируют свои системы. Особенно, когда их ещё не реализовали. Вы реально решали задачу по сканированию клеток со стекла?
И мой вопрос является ключевым — почему увидит?)
Если позволите, я все-таки свою ложку дегтя в бочку меда положу.
1) Самое главное в машинном обучении будет достоверность данных из историй болезни. Не скажу про зарубежную медицину. Но я точно не хочу чтобы появилась система, которая обучалась на истории болезней в России. Кто обращался в поликлинику, наверняка, меня поймет. Поэтому проблема применения ИИ в медицине скорее лежит в другой плоскости.
2) Я так же пока что критично отношусь к системам, которые автоматически определяют патологии. Был свидетелем разговора онколога с разработчиком. Онколог привел простой пример из практики. Анализ на гистологию, который был прислан. И онколог фактически случайно на периферии рассмотрел одну раковую клетку. И возник вопрос относительно как будет автоматизированная система анализировать визуально? Увидит ли она на периферии так же эту одну раковую клетку?
При всем уважении статья охватывает рекомендательные системы несколько бытового уровня. Хотелось бы примеры из более серьезных областей как медицина. Так же акцент сделан сторону машинного обучения. В то время как это не единственный способ реализации таких систем.
Пример из медицины выглядит не совсем удачно. Желательно что-то менее спорное приводить в качестве примера.
И не понятно каким именно образом будут выявляться дефекты системы. Даже, с учетом вывода данных и "мышления" системы?
Хотелось бы так же услышать о прикладной модели внесения данных. И, что более важно, исправления ошибок в заложенных данных и логической модели. Еще бы и схематично отобразить такой бизнесс-процесс с учетом ролей. Это не критика, а замечание относительно содержимого статьи.
Так же есть возможность в блоке данных выводить дополнительную информацию. Это могут быть и комментарии. Визуально выглядит как два блока текста разделенных чертой горизонтальной или вертикальной. Правда не проверял наифигурах отличных по форме от прямоугольных.
Я в своем проекте сппр так же использую Graphviz. Это позвояет визуализировать логическую структуру. Так же следует упомянуть о других возможностях. Это использование svg формата. Что позволяет визуализировть в браузерах (более удобно) и возможностях гипер-ссылок. Что позволяет сделать отображение еще и интерактивным.
Не сочтите критикой. Лицо я заинтересовпнное в теме статьи. Не скажу, что все так радужно как описано. Как быть, когда система, которую сопровождают очень быстро развивается и расширяется? Когда идет быстрое масштабирование географически? Когда вы не можете контролировать уровень знаний принятых в регионах на работу людей, которые осуществляют поддержку? И как обеспечить такое же высокое качество работы новых сотрудников? Как решить проблему их страхов и/или бездеятельности при столкновении с новой для них проблемой?
Извиняюсь за такой список вопросов. Это не полный перечень того, что приходится решать в рамках руководства службой поддержки. Тут описан больше магазин. Но есть же и другие области применения. Некоторые достаточно сложные и ответственные. Где нельзя полагаться на одно сопереживание. Когда ожидается скорейшее решение. Кстати, все ли сотрудники готовы сопереживать?)
Это понятно. Внимательно прочитал. Но это диалог "ни о чем". То есть прикладного характера не несёт. Скорее демонстрация метода и технологии. Вопрос был о возможном конкретном применении. Реальном прикладной применении.
Идея использовать генераторы понравилась. Но пока нет понимания прикладного применения Вашего подхода в чат-боте. Если можно приведите какой-нибудь пример.
Я в своей статье описал как раз пример приложения экспертной системы и чат-бота для Telegram, который является ещё одним способом общения с логикой системы. В чем-то это мне показалось удобнее. Никто и ни кого убивать не должен. Но взаимное дополнение является хорошим способом реализации.
Прошу прощения за не русский язык. Очистки в метро.
Внести можно много и очень много. База данных позволяет хранить в себе огромное количество информации. Фактически каждый элемент — это одна запись.
Я бы больше беспокоится не об объёме информации, а о том, кто её будет вносить? И о компетенции тех, кто будет вносить. И о бюрократии согласования.
На самом деле я ит-специалист. И медицину отдаю на откуп медикам. Данная платформа позволит им реализовать в рамках одной системы различные экспертные системы. У меня есть алгоритм по дисциплинарным взысканиям для ЛПУ. Не совсем медицина. А тоже нужная и важная часть в работе.
Что до скорой помощи, то она проще в алгоритмах, чем реальное ведение пациента в ЛПУ.
Про статистику могу дополнить. Данная система записывает все шаги и маршруты по алгоритму. Что даёт возможность выстраивать полную статистику в различных разрезах. То есть устанавливать закономерности, частоту ошибок. И выявлять отклонения. Причём отклонения можно выявлять точечно или точно. Всегда можно предметно обсуждать причину отклонения. Не секрет, что все ошибаются. Иногда ошибается и логика системы. И врач, отклонения от алгоритма может допустить по причине не согласия. Это позволит ему указать на ошибку. И в алгоритм можно внести исправления.
Да. Думаю что Вы правы. Но не во всем. Восстребованности я не заметил. Максимум что посоветовали: писать диссертацию. Забавно.
А если серьёзно. Эта система обладает рядом преимуществ.
1) платформа. Можно самим доктора создавать эту систему. ИТ разработчики не нужны.
2) система может использоваться как обучающий материал молодыми специалистам, как успешная система в работе, как средство контроля принимаемых решений специалистом в конкретном случае.
3) система проследить за тем, чтобы не была упущенное ни одна деталь. В нужный момент она сама создаст параллельную нить рассуждений (это может быть множество параллелей).
4) система позволяет для каждого элемента хранить справочный материал. При использовании отображается значение есть справка. При нажатии на этот значок этот материал выдаётся на экран.
5) при прохождении создаётся протокол рассуждений. В случае медицины — рассуждений врача.
6) возможно развивать и связывать между собой Алгоритмы различных проф. областей. Это значит, что с помощью такой системы можно вести пациента с учётом всех его диагнозом и заболеваний.
7) система представляет собой одновременно и экспедицию систему, и регламентную. Позволяет быть более широкой, чем любая распространения система.
8) открытость модели буквально. То есть глядя на диаграммы профессиональное сообщество всегда может выявить ошибку. А инструмент Алгоритм-дизайнер всегда даст возможность внести исправление. При этом нет сложного периода связанного с утверждением тех. задания, разработки и тестирования. Все правки можно проверять при редактировании.
Здравствуйте, коллега! :) На чем построено ядро — это предмет 3-й статьи, которая является Частью 1-й. :) Должен извиниться за такую обратную очередность изложения материала. Но она продиктована именно тем, что так понятнее. Переходом от более простого к более сложному. Статья готова и скоро я ее опубликую.
Забегая чуть вперед скажу, что использовалась платформа СППР Универсальные алгоритмы. На скриншоте в этой статье есть Алгоритм-Дизайнер. Собственно, это и есть инструмент, в котором создается логическая модель алгоритма СППР. Для использования модели был разработан Алгоритм-Навигатор — web-приложение, которое работает на всех устройствах. И в дополнение был разработан чат-бот Telegram, который просто использует уже созданную модель.
Причем, сама платформа позволяет создавать экспертные системы для любой проф. области. При этом обладает открытой логической моделью (всегда можно печатать диаграммы) и может создаваться уже без участия программистов. То есть экспертом или группой из своей проф. области.
Подробно я опишу платформу в 1-й части. Надеюсь Вам будет интересно. :)
Приветствую! Мне жаль, что без исходника чат-бота Вам не интересно. Потому что статья посвящена конкретной прикладной проблеме — поддержке оборудования, выход из строя которого приводил к серьезным проблемам и задержкам в работе. Так же сложности многоуровневой поддержки в распределенной филиальной сети. И способу решения этой задачи путем применения методики и платформы для создания экспертных систем. В данном случае экспертная система строилась для службы поддержки. Решалась задача по быстрому и эффективному решению возникающих проблем.
Если внимательно посмотреть на скриншот Алгоритм-Дизайнера, то видно. что задумка была охватить гораздо больше оборудования в отделениях. Позволить часть проблем решать персоналу самостоятельно дав им в руки инструмент, который проведет их шаг за шагом к локализации проблемы и ее решению.
Уверяю, что чат-бот не содержит в себе ничего особенного. Там просто вывод сообщений с кнопками и функция редактирования сообщений. Он писался как надстройка над уже существующим логическим ядром экспертной системы. Частично логику Вы можете увидеть в скриншотах диаграмм. Ну, и сам чат бот при вводе команды /listsit выдает ситуации и ссылки на функцию генерации диаграммы для выбранной ситуации. То есть Вы можете просмотреть всю логику, потому что при движении по алгоритму Вы делаете всего лишь несколько шагов.
Но и функция генерации диаграмм не есть часть чат-бота. Она была уже реализована в рамках ядра экспертной системы. Потому что оно строится по принципу «Открытого исходного кода» логической модели. Если интересно, то диаграммы строятся средствами Graphviz.
Вопрос не в онкологе. Не нужно переводить в данную плоскость. Потому что за врачём законодательно закреплена ответственность. В том числе и за врачебную ошибку. Но речь ведь не об этом. Про то, как доказать врачебную ошибку тоже отдельная тема. И никакого отношения не имеющая к тому что я написал.
Нежелание ответить относительно программного обеспечения и перевод в другую плоскость это часто встречающаяся практика в подобных дискуссиях. Я сам разработчик. И некоторое время работал с медициной. Существует пока что незрелая позиция разработчиков, которые считают, что их системы призваны заменить врача. На самом деле при этом в утверждениях больше слышится подменить. Но вреальости какую бы систему н использовал врач, он все-равно ответственное лицо. Не программа.
Ещё очень часто в подобных дискуссиях подменяют понятия неточности прибора и ошибки в логике программы. Которые, к тому же, могут быть неявными.
Опять же изучив огромное количество историй болезни система с высокой вероятностью предполагает, что такая-то методика лечения будет более эффективной. А я, вот, не хочу чтобы меня лечили с какой-то долей вероятности. В таких случаях многие врачи скажут, что система не соответствует клиническому мышлению. Его, кстати, никто не отменял. И именно ему учат врачей. Так что и система помощник должна опираться не только на большие даннве,. А, наверное, должна приближаться в своей логике к клиническому мышлению врача. Тогда, если я выпал из процента, можно избежать ошибки. Ведь речь идёт о здоровье.
Тогда отвечу вопросом на вопрос. А почему увидит? Это вопрос из практики, а не теории. Почему-то разработчики идеализируют свои системы. Особенно, когда их ещё не реализовали. Вы реально решали задачу по сканированию клеток со стекла?
И мой вопрос является ключевым — почему увидит?)
Если позволите, я все-таки свою ложку дегтя в бочку меда положу.
1) Самое главное в машинном обучении будет достоверность данных из историй болезни. Не скажу про зарубежную медицину. Но я точно не хочу чтобы появилась система, которая обучалась на истории болезней в России. Кто обращался в поликлинику, наверняка, меня поймет. Поэтому проблема применения ИИ в медицине скорее лежит в другой плоскости.
2) Я так же пока что критично отношусь к системам, которые автоматически определяют патологии. Был свидетелем разговора онколога с разработчиком. Онколог привел простой пример из практики. Анализ на гистологию, который был прислан. И онколог фактически случайно на периферии рассмотрел одну раковую клетку. И возник вопрос относительно как будет автоматизированная система анализировать визуально? Увидит ли она на периферии так же эту одну раковую клетку?
Не обязательно решать задачу ML для того чтобы реализовать данный функционал.
Можно пояснить, что именно подразумевается под шаблонизацией заявок?
При всем уважении статья охватывает рекомендательные системы несколько бытового уровня. Хотелось бы примеры из более серьезных областей как медицина. Так же акцент сделан сторону машинного обучения. В то время как это не единственный способ реализации таких систем.
Пример из медицины выглядит не совсем удачно. Желательно что-то менее спорное приводить в качестве примера.
И не понятно каким именно образом будут выявляться дефекты системы. Даже, с учетом вывода данных и "мышления" системы?
Хотелось бы так же услышать о прикладной модели внесения данных. И, что более важно, исправления ошибок в заложенных данных и логической модели. Еще бы и схематично отобразить такой бизнесс-процесс с учетом ролей. Это не критика, а замечание относительно содержимого статьи.
Так же есть возможность в блоке данных выводить дополнительную информацию. Это могут быть и комментарии. Визуально выглядит как два блока текста разделенных чертой горизонтальной или вертикальной. Правда не проверял наифигурах отличных по форме от прямоугольных.
Я в своем проекте сппр так же использую Graphviz. Это позвояет визуализировать логическую структуру. Так же следует упомянуть о других возможностях. Это использование svg формата. Что позволяет визуализировть в браузерах (более удобно) и возможностях гипер-ссылок. Что позволяет сделать отображение еще и интерактивным.
А можно раскрыть тему длинных текстов в кнопках, которые обре0аются при выводе на экран?
Приветствую! А можно урочнить ваше отношение к медицине и предметной области вчастности? Есть ли у вас в команде реальные медики-практики?
Не сочтите критикой. Лицо я заинтересовпнное в теме статьи. Не скажу, что все так радужно как описано. Как быть, когда система, которую сопровождают очень быстро развивается и расширяется? Когда идет быстрое масштабирование географически? Когда вы не можете контролировать уровень знаний принятых в регионах на работу людей, которые осуществляют поддержку? И как обеспечить такое же высокое качество работы новых сотрудников? Как решить проблему их страхов и/или бездеятельности при столкновении с новой для них проблемой?
Извиняюсь за такой список вопросов. Это не полный перечень того, что приходится решать в рамках руководства службой поддержки. Тут описан больше магазин. Но есть же и другие области применения. Некоторые достаточно сложные и ответственные. Где нельзя полагаться на одно сопереживание. Когда ожидается скорейшее решение. Кстати, все ли сотрудники готовы сопереживать?)
Это понятно. Внимательно прочитал. Но это диалог "ни о чем". То есть прикладного характера не несёт. Скорее демонстрация метода и технологии. Вопрос был о возможном конкретном применении. Реальном прикладной применении.
Идея использовать генераторы понравилась. Но пока нет понимания прикладного применения Вашего подхода в чат-боте. Если можно приведите какой-нибудь пример.
Я в своей статье описал как раз пример приложения экспертной системы и чат-бота для Telegram, который является ещё одним способом общения с логикой системы. В чем-то это мне показалось удобнее. Никто и ни кого убивать не должен. Но взаимное дополнение является хорошим способом реализации.
Прошу прощения за не русский язык. Очистки в метро.
Внести можно много и очень много. База данных позволяет хранить в себе огромное количество информации. Фактически каждый элемент — это одна запись.
Я бы больше беспокоится не об объёме информации, а о том, кто её будет вносить? И о компетенции тех, кто будет вносить. И о бюрократии согласования.
На самом деле я ит-специалист. И медицину отдаю на откуп медикам. Данная платформа позволит им реализовать в рамках одной системы различные экспертные системы. У меня есть алгоритм по дисциплинарным взысканиям для ЛПУ. Не совсем медицина. А тоже нужная и важная часть в работе.
Что до скорой помощи, то она проще в алгоритмах, чем реальное ведение пациента в ЛПУ.
Про статистику могу дополнить. Данная система записывает все шаги и маршруты по алгоритму. Что даёт возможность выстраивать полную статистику в различных разрезах. То есть устанавливать закономерности, частоту ошибок. И выявлять отклонения. Причём отклонения можно выявлять точечно или точно. Всегда можно предметно обсуждать причину отклонения. Не секрет, что все ошибаются. Иногда ошибается и логика системы. И врач, отклонения от алгоритма может допустить по причине не согласия. Это позволит ему указать на ошибку. И в алгоритм можно внести исправления.
Да. Думаю что Вы правы. Но не во всем. Восстребованности я не заметил. Максимум что посоветовали: писать диссертацию. Забавно.
А если серьёзно. Эта система обладает рядом преимуществ.
1) платформа. Можно самим доктора создавать эту систему. ИТ разработчики не нужны.
2) система может использоваться как обучающий материал молодыми специалистам, как успешная система в работе, как средство контроля принимаемых решений специалистом в конкретном случае.
3) система проследить за тем, чтобы не была упущенное ни одна деталь. В нужный момент она сама создаст параллельную нить рассуждений (это может быть множество параллелей).
4) система позволяет для каждого элемента хранить справочный материал. При использовании отображается значение есть справка. При нажатии на этот значок этот материал выдаётся на экран.
5) при прохождении создаётся протокол рассуждений. В случае медицины — рассуждений врача.
6) возможно развивать и связывать между собой Алгоритмы различных проф. областей. Это значит, что с помощью такой системы можно вести пациента с учётом всех его диагнозом и заболеваний.
7) система представляет собой одновременно и экспедицию систему, и регламентную. Позволяет быть более широкой, чем любая распространения система.
8) открытость модели буквально. То есть глядя на диаграммы профессиональное сообщество всегда может выявить ошибку. А инструмент Алгоритм-дизайнер всегда даст возможность внести исправление. При этом нет сложного периода связанного с утверждением тех. задания, разработки и тестирования. Все правки можно проверять при редактировании.
Забегая чуть вперед скажу, что использовалась платформа СППР Универсальные алгоритмы. На скриншоте в этой статье есть Алгоритм-Дизайнер. Собственно, это и есть инструмент, в котором создается логическая модель алгоритма СППР. Для использования модели был разработан Алгоритм-Навигатор — web-приложение, которое работает на всех устройствах. И в дополнение был разработан чат-бот Telegram, который просто использует уже созданную модель.
Причем, сама платформа позволяет создавать экспертные системы для любой проф. области. При этом обладает открытой логической моделью (всегда можно печатать диаграммы) и может создаваться уже без участия программистов. То есть экспертом или группой из своей проф. области.
Подробно я опишу платформу в 1-й части. Надеюсь Вам будет интересно. :)
Если внимательно посмотреть на скриншот Алгоритм-Дизайнера, то видно. что задумка была охватить гораздо больше оборудования в отделениях. Позволить часть проблем решать персоналу самостоятельно дав им в руки инструмент, который проведет их шаг за шагом к локализации проблемы и ее решению.
Уверяю, что чат-бот не содержит в себе ничего особенного. Там просто вывод сообщений с кнопками и функция редактирования сообщений. Он писался как надстройка над уже существующим логическим ядром экспертной системы. Частично логику Вы можете увидеть в скриншотах диаграмм. Ну, и сам чат бот при вводе команды /listsit выдает ситуации и ссылки на функцию генерации диаграммы для выбранной ситуации. То есть Вы можете просмотреть всю логику, потому что при движении по алгоритму Вы делаете всего лишь несколько шагов.
Но и функция генерации диаграмм не есть часть чат-бота. Она была уже реализована в рамках ядра экспертной системы. Потому что оно строится по принципу «Открытого исходного кода» логической модели. Если интересно, то диаграммы строятся средствами Graphviz.