Всем привет!

Это моя первая статья на Хабре, решил поделиться с общественностью своей идеей и тем, чем последнее время я занимаюсь в свободное время.

Любая критика (а также предложения и/или пожелания) категорически приветствуются.
Приятного чтения!

Идея

Не так давно по состоянию здоровья вынужден был погрузиться в мир глюкозы и ее мониторинга. В продаже довольно много всяких‑разных глюкометров, которые с более‑менее приемлемой точностью помогают мониторить уровень глюкозы. Но, в наш век информационных технологий, электромобилей и умных домов подавляющее количество этих устройств — это просто «экранчики с кнопками», показания которых никуда нельзя передать, никак нельзя экспортировать (ну кроме банального переписывания в тетрадку с экрана). В общем, говоря «современным языком» умных домов — по большей части эти устройства «глупые». К слову, да — я в курсе про системы непрерывного мониторинга уровня глюкозы и про них здесь тоже будет сказано (спойлер — не все так радужно в тамошних королевствах).

И вот на фоне этих мыслей возникла идея создать «нечто», что поможет сделать из такого «глупого» устройства «умное». Для начала стоит определиться, какие именно устройства мы будем здесь рассматривать в качестве «глупых». Берем любой банальный глюкометр. У него есть экран с показаниями (сегментированными, как правило) и… все. Получается, что в нашем случае, «глупое» устройство — это устройство с экраном (или шкалой) для отображения показателей и не имеющее интерфейсов для выгрузки данных (кроме визуального, само собой — посмотрел глазками, записал на бумажку — чем не интерфейс?).

На этом этапе пришло осознание, что под такое определение попадает практически любое измерительное устройство от красивого вольтметра до школьной линейки. Т. е., потенциально, создаваемое «нечто» может получать на вход экран любого устройства и считывать с него данные в известном формате.

При этом, я исхожу из того, что вносить изменения в конструкцию, например, глюкометра (для простоты здесь и далее я буду рассматривать глюкометр, но вместо него потенциально может быть любой девайс, который что‑то измеряет и отображает результат), чтобы читать из него данные, мы не хотим, но получать их как‑то нужно. А как в принципе можно получить данные с экрана чего‑либо? Вариантов не так, чтобы много — или визуально распознать сразу с экрана или прочитать голосом с экрана, а потом распознать нужные данные уже из голоса.

И вот таким нехитрым способом рождается концепт этого «нечто» — оно должно уметь распознавать данные с фотографии экрана устройства и/или с «диктовки данных с экрана» устройства. В качестве базы прекрасно подходит любой смартфон, он и фотографии делает, и звук писать умеет, в целом все, что нужно. А для самого процесса распознавания прекрасно подходят нейросети. Осталось соединить все воедино и сделать. Думал я тогда…

Анализ

По итогу возник такой концепт: берем смартфон, фотографируем экран устройства (глюкометра), получаем значения, с которыми можем уже делать все, что захотим: сохранять, анализировать, делиться. Но распознавание таких данных с фото с более‑менее приемлемой точностью оказалось задачей практически невыполнимой. Особенно с учетом того, что потенциально система должна распознавать данные с экрана любого устройства (а глюкометров много разных и данные на экране у них сегментированы по‑разному).

Основная проблема  — качество распознавания как моделями (например, Yandex Vision OCR), так и другим специализированными софтом (например, Tesseract OCR), опять же, с учетом того, что исходник (картинка) не стандартизирован. Возможно, если импортным моделям дать фоточку экрана глюкометра, они что-то и распознают, но, честно говоря, сомневаюсь в качестве.

Эта идея, наверное, могла бы сработать (что, кстати, думаете?), если подойти к ней с точки зрения создания собственной модели и ее обучения конкретно под распознавание разных типов экранов разных устройств с более точной детализацией данных на входе — например, если модель будет заранее знать, экран какого именно устройства она пытается распознать и, соответственно, понимать сегментацию данных на этом экране. Но этот подход довольно ресурсоемок с точки зрения инфраструктуры под реализацию (хотя, модель, распознающая заведомо известные экраны с заведомо известной сегментацией, не кажется мне очень сложной и большой по размерам) и с точки зрения поддержки в целом (например, добавление нового устройства приведет к необходимости дообучения модели). Да и заходить так глубоко в это мне пока не хотелось.

Поэтому, я перешел к более простому и универсальному способу фиксации информации — через голос. Логика следующая — пользователь надиктовывает данные с экрана устройства (глюкометра, опять же), а система пытается их распознать и сохранить. Технически это может выглядеть так: голос распознается в текст через Yandex Speech Kit, полученный текст стандартизируется через Yandex Gpt, распознается и сохраняется.

Реальность

После того, как концепт, в целом, родился, мне стало интересно, а что же вообще происходит в плане умных устройств, связанных с мониторингом уровня глюкозы сейчас.

Во‑первых, все таки существуют глюкометры, которые способны передавать информацию на смартфон в момент совершения измерения. Это логика обычного глюкометра (ткни сам себя иголкой в палец), к которому приделали Bluetooth и дали некое приложение, в котором можно смотреть результаты этих измерений.

Во‑вторых, существуют более интересные «системы непрерывного мониторинга глюкозы», суть которых сводится к тому, что пользователь крепит себе на руку (или на пузо) некий датчик, который непрерывно (обычно, раз в несколько минут) измеряет уровень глюкозы и отправляет данные на смартфон через тот же Bluetooth (в некоторых системах данные можно считать принудительно через NFC). Таких систем довольно много, все они обладают весьма разными степенями точности (хотя заявляются, формально, очень близкие показатели), но все эти системы объединяет один факт — все они работают какое‑то конкретное время (в районе 14 дней обычно), после которого датчик превращается в тыкву (скорее всего, сам датчик продолжает слать показания, но приложение их уже не принимает из‑за программной блокировки, хотя, не исключается и аппаратная блокировка в самом датчике, но верится в это слабо) и требует замены, что может быть весьма накладно, учитывая стоимость этой системы. Кроме того, эти системы зачастую имеют проблемы с выгрузкой данных в «сыром» виде — я вот, например, не хочу видеть красивые графики, я хочу табличку с двумя столбцами: дата измерения и значение — и получить такое, как это ни странно, может быть проблемой. Я, например, пользовался тремя разными системами и адекватно выгрузить из них сырые данные смог только 1 раз.

А в контексте рассматриваемой идеи, данные из таких устройств можно было бы загружать в это наше «нечто» для хранения и анализа в одном месте, что тоже может быть удобно и полезно.

Реализация

По итогу, после всех рассуждений и анализа, можно приступать к реализации этого «нечто» уже вживую.

Изначально, все это хотелось оформить в виде приложения на Android, так как был интерес к мобильной разработке и очень хотелось поскорее изобрести свой собственный велосипед, но со временем акцент сместился в более «простой» вариант — телеграм‑бота.

«Простой» этот вариант потому, что у нас сразу есть уже готовый UI в виде приложения Телеграм (причем, сразу на разных платформах) и остается только реализовать «обратную сторону» бота, которая должна «общаться» с пользователем.

С учетом всех ранее описанных изысканий получается следующая функциональность:

• распознавание, запись и хранение значений показателей (потенциально, любых, а не только уровня глюкозы);

• анализ этих показаний (графики, граничные условия, отклонения и так далее), в том числе, с помощью ИИ;

• импорт и экспорт значений показателей.

С точки зрения же пользователя, это должно работать так:

• обращаемся к боту с командой «сохранить данные»;

• выбираем показатель из списка тех, что бот «знает»;

• вводим (текстом или голосовым сообщением) значение показателя, дату, если нужно, и, например, какой‑то комментарий (пример: отправляем боту голосовое сообщение «сегодня в полдень съел конфетку и глюкоза стала 12.0»);

• бот анализирует данные, распознает (сегодня, полдень, конфетка, 12.0) их и сохраняет;

• при необходимости можно (командой) выгрузить данные или попросить бота провести анализ и/или построить какие‑то специфичные данному показателю отчеты;

• можно (опять же, командой) и массово загрузить данные, например, из тех самых систем непрерывного мониторинга, если требуется.

Теперь, когда понятно, что нужно сделать, можно определиться с тем, как это будет делаться — определить стек технологий: пускай это будет aspnet 8.0 приложение, работающее в докере, почему бы и нет? Собственно, на том и порешил.

Если подробнее, то в проекте используются:

• Telegram.Bot (https://telegrambots.github.io/book/index.html) — общение с Телеграмом.

• WorkflowCore (https://github.com/danielgerlag/workflow‑core) + Redis — обработка команд пользователя.

• Entity Framework Core (https://learn.microsoft.com/en‑us/ef/core/) — работа с БД.

• Serilog (https://serilog.net/) — логирование.

• ScottPlot (https://scottplot.net/) — графики.

• CsvHelper (https://joshclose.github.io/CsvHelper/) — выгрузка/загрузка данных.

• HangFire (https://www.hangfire.io/) — периодические задания.

• MailKit (https://mimekit.net/) — работа с почтой.

Установлено все это добро на простенькой VPS из бесплатного пула (aka Free Tier) одного из облачных провайдеров, ML (Translation Kit, Speech Kit, TextGeneration) + еще некоторые сервисы (Object Storage, Postbox) — Яндекс Облако (не реклама). И да, это стоит небольшую денежку.

Заключение

Как говорится, если хочешь узнать о недостатках (или преимуществах) чего‑либо, пользуйся этим сам (а еще лучше — покажи соседу). В процессе пользования этим концептом приходит осознание того, что некоторые вещи можно серьезно упростить (например, за счет ИИ) или вообще убрать, так как, лично мне, они так и не понадобились. В свободное плавание, до этого момента, концепт не запускал, так как считал (и считаю по сей день), что он еще не готов к тому, чтобы увидеть свет. С другой стороны, если ты хочешь получить отзывы, нельзя бесконечно пользоваться чем‑то в одиночку. Рано или поздно, но должны появиться еще пользователи. Хорошие или плохие, хейтеры или фанаты — это неважно, так как любой отзыв — это опыт и повод подумать.

К слову, размышлял я и на тему использования других ИИ, например, для распознавания и анализа данных. Сейчас, как уже описано выше, используется стек Яндекса, но потенциально он может быть переключен на любого другого вендора (достаточно использовать OpenAI API).

В целом, этот концепт, конечно, не является готовым решением, еще много чего можно сделать и улучшить, но суть он показывает очень неплохо и, при необходимости, его можно довольно быстро доделать, адаптировать и масштабировать.

На этом я (пока) заканчиваю эту сагу, всем спасибо за внимание и удачи!

P. S.

К слову, хотелось бы узнать в целом мнение сообщества (причем любое, не стесняйтесь в эпитетах, господа) о таком проекте. Нужен ли он? Потенциально, сообщество людей, которым он может(!) быть полезен — огромно, но, как говорится, человек предполагает… Впрочем, не будем о грустном. В любом случае, я расцениваю этот проект как возможность погрузиться во что‑то новое и приобрести главное, что сложно купить за деньги — опыт.

И да, конечно, лучше сто раз увидеть, чем один раз прочитать. Ищите по названию MyDiabeticBot в ТГ.