Медицинские тексты: почему ИИ тут тупит

Выгрузите тысячу выписок из больницы. Попробуйте найти все упоминания креатинина. Или все случаи, когда МРТ показала отек. Или все пациентов с температурой выше 39. Звучит просто? А вот и нет.

Медицинские документы - это свободный текст. Врач пишет как хочет: "Креатинин 120 мкмоль/л", "креат. 120", "уровень креатинина повышен до 120". ИИ, обученный на общих данных, тут пасует. Он не понимает контекст, единицы измерения, синонимы.

Традиционные подходы - документо-центрические. Весь текст - один большой объект. Вы ищете по ключевым словам, используете регулярки. Но это хрупко. Одна опечатка - и все летит в тартарары.

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

Проблема в том, что медицинские данные неструктурированы. Но при этом они содержат критически важную информацию. Как ее извлечь? Как сделать так, чтобы ИИ понимал смысл, а не просто слова?

Фактор-центрическая модель: смена парадигмы

Забудьте о документах. Запомните: факторы. Фактор - это атомарный кусочек информации. Креатинин = 120 мкмоль/л. Температура = 38.5°C. На МРТ - отек в левой височной доле.

Фактор-центрическая модель разбивает текст на такие атомарные факты. Каждый факт - это триплет: сущность, атрибут, значение. Иногда с контекстом: время, источник, достоверность.

💡

Фактор-центрическая модель не хранит документы. Она хранит факты, извлеченные из документов. Документ - это просто источник, который можно выбросить после обработки.

Почему это лучше? Потому что факты можно агрегировать, искать, анализировать. Можно строить графы знаний. Можно тренировать модели на фактах, а не на текстах.

Переход от документо-центрической к фактор-центрической модели - это как перейти от бумажных карточек к реляционной базе данных. Только в медицине.

Разбираем на атомы: как работает семантическая декомпозиция

Семантическая декомпозиция - это процесс разбиения текста на атомарные факты. Не просто токены, а смысловые единицы.

Возьмем предложение: "При поступлении креатинин 120 мкмоль/л, через сутки снизился до 110."

Что здесь факты?

Факт 1: креатинин = 120 мкмоль/л, время: при поступлении
Факт 2: креатинин = 110 мкмоль/л, время: через сутки после поступления

Обратите внимание: мы извлекли два факта, хотя в предложении одно упоминание креатинина. Потому что значение изменилось.

Как это делается? С помощью NLP-моделей, обученных на медицинских текстах. Но не просто NER (распознавание именованных сущностей), а полноценная семантическая разметка.

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

Для этого нужны модели, которые понимают медицинский контекст. Например, BioBERT или ClinicalBERT. Но и их недостаточно. Нужна дополнительная тренировка на задачах извлечения фактов.

Архитектура, которая не сломается

Как построить систему для фактор-центрической модели? Давайте по шагам.

1Захват данных

Медицинские тексты поступают из разных источников: EHR (электронные медицинские карты), лабораторные системы, врачебные записи. Нужен коннектор, который вытягивает данные в сыром виде. Форматы: PDF, DOCX, plain text, HL7, FHIR. Да, всё вместе.

2Предобработка

Очистка текста: удаление шапок, подписей, служебной информации. Нормализация: приведение единиц измерения, стандартизация терминов. Сегментация: разбивка на предложения или абзацы. Для длинных документов, как в статье про Docling, это критически важно.

3Семантическая декомпозиция

Ядро системы. NLP-модель, которая принимает текст и выдает список фактов. Каждый факт - это структурированный объект с полями: тип сущности, атрибут, значение, единицы измерения, время, контекст, достоверность.

Модель должна быть многозадачной: извлекать биомаркеры, витальные параметры, диагнозы, процедуры, лекарства. И делать это точно. Оценка точности - отдельная тема, как в FACTS Benchmark Suite.

4Хранение фактов

Факты складываем в базу данных. Но какую? Реляционная БД - скучно. Графовая база - интереснее, потому что факты можно связать. Например, пациент -> имеет показатель -> креатинин -> значение -> 120 -> время -> дата.

Я предпочитают комбинированный подход: PostgreSQL для метаданных и Elasticsearch для полнотекстового поиска по фактам. Но это уже детали.

5Валидация и обогащение

Факты нужно проверять. Креатинин 120 - это нормально? А 1200? Добавляем правила валидации: диапазоны нормальных значений, логические проверки (например, дата рождения не может быть позже даты смерти).

Обогащение: связываем факты с онтологиями типа SNOMED CT или UMLS. Это повышает семантическую ценность.

6API и доступ

Факты должны быть доступны через API. REST или GraphQL. Чтобы другие системы могли их использовать: аналитика, отчетность, клинические решения.

Вот так выглядит архитектура. Непросто, но работает.

Биомаркеры, находки МРТ и другие примеры

Где это применяется? Да везде.

Извлечение биомаркеров: из текста лабораторных отчетов. Креатинин, гемоглобин, лейкоциты. Со значениями, единицами, временем. Позволяет строить динамику показателей.

Находки МРТ: "На МРТ головного мозга выявлен отек левой височной доли". Факт: тип = находка МРТ, атрибут = локализация, значение = левая височная доля, дополнительно = отек.

Витальные параметры: температура, давление, пульс. Часто записываются в таблицах, но иногда в тексте. Фактор-центрическая модель вытягивает их отовсюду.

И так далее. Чем больше типов фактов, тем богаче модель.

💡

Фактор-центрическая модель - это не только для хранения. Она для анализа. Можно искать корреляции, строить прогнозы, выявлять аномалии. Например, найти всех пациентов с креатинином выше нормы и температурой выше 38.5. За секунды.

Где вас ждут подводные камни

Казалось бы, все прекрасно. Но нет.

Ошибка 1: Слишком много фактов. Если извлекать все подряд, система захлебнется. Нужно определять, что важно. Клиническая релевантность - ключевое слово.

Ошибка 2: Неточность моделей. NLP-модели ошибаются. Особенно на медицинских текстах. Нужна постобработка, валидация, а иногда и ручная проверка. Как в статье про Text-to-SQL, 90% точности недостаточно.

Ошибка 3: Игнорирование контекста. Факт без контекста - это мусор. Время, источник, статус (предположительный, подтвержденный). Все это нужно сохранять.

Ошибка 4: Сложность интеграции. Медицинские системы - старые, закрытые. Вытянуть данные оттуда - подвиг. Придется писать кастомные коннекторы, парсить PDF, как в статье про длинные PDF.

Ошибка 5: Юридические вопросы. Медицинские данные - персональные. Их нельзя просто так хранить и обрабатывать. Нужны согласия, анонимизация, шифрование. DevOps-инженер должен это понимать.

Самый большой подводный камень: врачи ненавидят изменения. Если ваша система усложняет им работу, они найдут способ ее обойти. Дизайн для людей, а не для машин.

Что будет дальше?

Фактор-центрическая модель - это будущее медицинского AI. Но будущее не наступит само.

Совет: начните с малого. Выберите один тип фактов (например, лабораторные показатели). Настройте извлечение для него. Отработайте пайплайн от текста до базы данных. Затем масштабируйте.

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

И последнее: не надейтесь только на ИИ. Человеческий контроль все еще нужен. Особенно в медицине, где ошибка стоит жизни.

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