Почему существует этот бенчмарк и что он проверяет
Анализ крови с помощью ИИ всё чаще используется в потребительских и клинических рабочих процессах, однако воспроизводимые оценочные рамки, адаптированные под лабораторную медицину, остаются редкостью. В этом контексте важны не те вопросы, которые охватываются общими бенчмарками по медицинскому вопросно-ответному поиску: может ли движок отличить железодефицит от талассемии при одинаковом среднем объёме эритроцитов, не ставит ли он чрезмерный диагноз синдрома Жильбера как гепатит и не «конструирует» ли он патологию в полностью нормальной панели скрининга?
Один анализ крови в виде панели обычно содержит достаточно сигналов, чтобы поддерживать несколько конкурирующих интерпретаций, и задача врача, выполняющего расшифровку, — сопоставить эти интерпретации между собой, а не извлечь «правильный ответ» из учебника. Двигатель, который хорошо справляется с задачами из учебников, всё равно может провалиться на тех случаях, которые важнее всего: на типичных ловушках дифференциальной диагностики, на доброкачественных вариантах, которые по отдельности выглядят тревожно, и на полностью нормальных панелях, которые провоцируют уверенных ассистентов «изобретать» патологию.
Этот бенчмарк был построен именно вокруг таких режимов отказа. Все пятнадцать случаев были отобраны по конкретному диагностическому признаку: железодефицитная микроцитозность, которую нужно отличать от носительства бета-талассемии при одинаковом среднем объёме эритроцитов, клиническая картина синдрома Жильбера, где единственным отклонением является изолированная непрямая гипербилирубинемия, и скрининговая панель из пятнадцати параметров, в которой каждый показатель находится в пределах референсного диапазона. Критерий поощряет двигатели, которые читают каждый случай в его собственных терминах, и штрафует двигатели, которые пытаются поставить уверенный диагноз там, где такой диагноз не обоснован.
Как Томас Кляйн, доктор медицины, я выбрал эту панель случаев, потому что именно эти паттерны чаще всего ошибочно интерпретируют ассистенты в лабораторной медицине. Дорогой режим отказа — это не "пропустить редкое заболевание"; это выдумать рутинную патологию у пациентов, у которых её нет. Наш Медицинская валидация hub описывает более широкую основу; эта страница описывает первоначальное proof-of-concept V11 и V11 второе обновление, которое масштабировало его до 100 000 синтетических случаев, взятых из синтетического набора случаев, охватывающего 127 страновых меток — с использованием той же оценочной рубрики, байт-в-байт, без разрешения постфактум настройки.
Последний эталонный прогон — V11 Second Update (26 апреля 2026)
Эталонный прогон V11 Second Update от 26 апреля 2026 сформировал 99.80% составной балл 100 000 синтетических случаев взятых из синтетического набора случаев Kantesti и охватывающих 127 страновых меток и языки 75+. Каждый случай завершился по основному пути движка; активации флага гипердиагностического «trap-case» оставались на 0 / 87,412. Первоначальный прогон V11 от 23 апреля 2026 включал 15 вручную отобранных случаев (составной 99.12%) и валидировал рубрику; Second Update сохраняет эту рубрику побайтно идентичной и расширяет оценку до когорты популяционного масштаба.
Формула составного балла объединяет три компонента: структурное соответствие с семью обязательными разделами отчёта и шестнадцатью обязательными подразделами, точность содержания измеряется как полнота по ключевым словам плюс полнота по системе оценивания плюс проверка валидности вероятностного распределения, и задержка ответа относительно целевого показателя уровня сервиса для основного пути. Точная декомпозиция показана в формуле рубрики ниже — ни эти веса, ни подрубрики не были изменены для Second Update.
Оставшиеся 0.20 процентных пункта «запаса» почти полностью раскладываются на клинический подбалл — небольшая доля случаев (преимущественно в Гепатологии и Ревматологии) имела одно ожидаемое ключевое слово системы скоринга, отсутствующее в интерпретации движка, несмотря на то, что диагностическое содержание было корректным. Ни один случай в когорте Second Update из 100 000 случаев не пропустил сам диагноз. Задержка улучшилась со среднего значения 20.17 s в первоначальном выпуске V11 до 13.26 s во Second Update, что отражает оптимизации производственного движка между двумя прогонами; рубрика, код скоринга и конечная точка API не изменены.
Составные баллы по каждой метке варьировались от 0,9971 до 0,9985 среди 30 наиболее представленных страновых меток. Длинный хвост из 97 дополнительных меток (в сумме ≈ 7 300 случаев) не показал систематической деградации. Самые частые метки по числу случаев: Соединенные Штаты (10 500), Бразилия (9 500), Испания (9 000), Италия (8 000), Германия (7 800), Франция (7 400), Португалия (5 800), Türkiye (3 400), Соединенное Королевство (2 900) и Мексика (2 500).
От 15 случаев до 100 000: эволюция когорты по 127 страновым меткам
Исходная панель случаев V11 охватывала семь специальностей — гематологию, эндокринологию, метаболическую медицину, гепатологию, нефрологию, кардиологию, ревматологию — плюс два выделенных случая ловушек гипердиагностики, при этом каждый случай представлял собой синтетически сгенерированную панель анализа крови. Второе обновление V11 расширяет оценку до 100 000 синтетических случаев по 127 страновым меткам, распределённых по восьми специальностям (исходные семь плюс выделённая внутренняя «bucket» по внутренней медицине, которая поглощает подмножество trap). Одна и та же рубрика скоринга применяется побайтно идентично в обоих прогонах.
Поскольку все случаи синтетически сгенерированы, нет реальных идентификаторов, которые нужно удалять, и не задействованы персональные данные. Каждый синтетический случай несет внутренний код случая бенчмарка (BT-NNN-LABEL в первоначальном наборе V11, стабильный case_uid во Втором обновлении). Ни в одном месте опубликованного стенда, технического отчета или выпущенных наборов данных не встречаются персональные данные.
первоначальным выпуском V11 — 15 вручную отобранных случаев
Исходная панель кейсов V11 была вручную отобрана доктором Томасом Кляйном, чтобы прорабатывать диагностические паттерны, которые чаще всего ошибочно интерпретируют помощники в лабораторной медицине. Каждый из пятнадцати кейсов был выбран по определённому диагностическому признаку, перечисленному ниже.
Почему именно такое распределение
Гематология получает три кейса, потому что микоцитарные дифференциалы и макроцитарные дифференциалы — это ловушки с наибольшим объёмом в реальной лабораторной практике. Эндокринология получает три, потому что проявления болезни Хашимото, СПКЯ и дефицита витамина D имеют разные диагностические «формы» (обусловленные аутоантителами, обусловленные соотношениями гормонов, обусловленные одним маркером). Специализации с одним кейсом всё равно остаются значимыми, потому что у ХБП, риска ASCVD и СКВ (SLE) есть собственные системы подсчёта, которые движок должен вызывать (стадирование KDIGO, 10-летний риск ASCVD, критерии EULAR/ACR 2019 для СКВ соответственно).
Второе обновление V11 — 100 000 синтетических случаев по 127 страновым меткам
Второе обновление заменяет исходный V11 жестко заданный Python-литерал из 15 случаев на более крупный синтетический набор случаев, генерируемый программно. Набор случаев загружается в начале каждого запуска, а конфигурация логируется для прозрачности. Распределение когорты по областям содержания показано ниже.
Синтетическое распределение страновых меток — топ-10 меток
100 000 синтетических случаев несут 127 страновых меток (ISO 3166-1 alpha-2), чтобы проверить обработку локали. Назначение меток: Европа 57,7%, Америки 25,4%, Азиатско-Тихоокеанский регион 6,2%, названные метки Ближний Восток/Африка 3,4% и длинный хвост из 97 дополнительных меток примерно 7,3% в сумме. Десять самых частых меток по числу случаев: Соединенные Штаты (10 500), Бразилия (9 500), Испания (9 000), Италия (8 000), Германия (7 800), Франция (7 400), Португалия (5 800), Türkiye (3 400), Соединенное Королевство (2 900) и Мексика (2 500). Составные баллы по каждой метке варьировались от 0,9971 до 0,9985. Эти количества меток являются свойствами сгенерированных случаев, используемых для проверки обработки локали — это не реальные пользователи и не реальное географическое покрытие.
Предварительно зарегистрированная рубрика — объяснение
Предрегистрация — это единственный самый важный методологический выбор в этом бенчмарке. Каждая ожидаемая диагностика, каждая клиническая система скоринга и каждый раздел отчёта были зафиксированы в исходном коде до того, как был вызван движок. Поэтому постфактум «настройка» рубрики, чтобы льстить движку, невозможна.
Три компонента составляют итоговый составной балл. структурный компонент даёт 35 процентов и измеряет, вернул ли движок семь обязательных разделов отчёта (заголовок, сводка, ключевые находки, дифференциал, системы скоринга, рекомендации, последующее наблюдение) и шестнадцать обязательных подразделов внутри них. Наличие раздела оценивается в 40 процентов, а наличие подраздела — в 60 процентов в рамках структурного расчёта.
The клинический компонент даёт 55 процентов и объединяет три вещи: воспроизведение (recall) диагностических ключевых слов (70 процентов клинического подбалла), воспроизведение (recall) системы скоринга (20 процентов — вычисляет ли движок Mentzer, FIB-4, HOMA-IR, риск ASCVD, стадирование KDIGO, критерии EULAR/ACR там, где это уместно), и проверку валидности суммы вероятностей (10 процентов — вероятности в дифференциале должны суммироваться в пределах интервала [90, 110]). Для кейсов-ловушек из результата вычитается явный штраф за гипердиагностику до 0.30, рассчитываемый как 0.10 за каждый сфабрикованный флаг патологии, с ограничением максимум тремя флагами.
The компонент задержки даёт 10 процентов. Ответ менее чем за 20 секунд получает полные 0.10, ответ менее чем за 40 секунд — 0.05, а всё, что медленнее, — ноль. Цель в 20 секунд отражает производственную основную SLA-цель для первичного патентного сервиса; потолок в 40 секунд отражает резерв бюджета для сценария «fallback» на Фазе 2 при тяжёлых вызовах движка.
Что предотвращает предрегистрация
Первичные бенчмарки печально известны тем, что раздувают собственные цифры за счёт постфактум настройки рубрики. Шаблон почти всегда один и тот же: команда запускает движок, видит, где он недотягивает, а затем тихо корректирует рубрику так, чтобы недотягивающие области учитывались меньше. Зафиксировав рубрику в исходном коде до первого вызова движка и опубликовав стенд под лицензией MIT, эта корректировка становится видимой в системе контроля версий. Любой может клонировать репозиторий, проверить даты авторства рубрики и убедиться, что результаты движка не использовались для формирования скоринга.
Сценарии ловушки гипердиагностики — почему реальный режим отказа — чрезмерные вызовы
Агрессивное «перекрикивание» патологии на нормальных экранах — задокументированный режим отказа у медицинских ассистентов для потребителей. Его последующие издержки включают ненужные обследования, тревожность пациента и ятрогенную диагностическую проработку. Два кейса-ловушки в этом бенчмарке разработаны так, чтобы сделать этот режим отказа видимым и поддающимся оценке.
🟡 Ловушка 1 — BT-014-GILBERT
Проявление. Мужчина 24 лет с общим билирубином 2.4 мг/дл. Прямая фракция нормальная, трансаминазы и щелочная фосфатаза находятся в пределах своих референсных диапазонов, ретикулоциты без особенностей, а гаптоглобин и ЛДГ исключают гемолиз.
Правильная интерпретация. Синдром Жильбера — доброкачественный полиморфизм UGT1A1. Интерпретация не должна вызывать гепатит, цирроз, гемолитическую анемию или билиарную обструкцию.
Результат V11. Составной 1.000. Ни один из шести отслеживаемых флагов гипердиагностики не появился как активная диагностика.
🟡 Ловушка 2 — BT-015-HEALTHY
Проявление. Женщина 35 лет с рутинной скрининговой панелью из пятнадцати параметров. Каждый аналит находится вполне комфортно в пределах своего референсного диапазона.
Правильная интерпретация. Успокоение и поддержание здорового образа жизни. Интерпретация не должна «придумывать» пограничную патологию, чтобы звучать клинически полезно.
Результат V11. Композитный показатель 1.000. Ни один из семи отслеживаемых флагов гипердиагностики — диабет, анемия, гипотиреоз, дислипидемия, гепатит, заболевание почек, дефицит — не проявился как активный диагноз.
В обоих «ловушках» были проверены тринадцать отслеживаемых флагов гипердиагностики. Ни один не сработал. Это результат, который важнее всего для любого клинициста, рассматривающего использование ИИ-двигателя как инструмента триажа или предварительной консультации: система не выдумала заболевание там, где его не было.
Индекс Ментцера: разграничение дефицита железа и носительства талассемии
Второе высокозначимое наблюдение касается сочетания случая BT-001 (железодефицитная анемия) с случаем BT-007 (бета-талассемия малая). Оба состояния проявляются микроцитозом и являются хорошо известной «подводной камнем» для наивных классификаторов. Индекс Ментцера, рассчитываемый как MCV, делённый на количество RBC, превышает 13 при железодефиците и опускается ниже 13 при талассемийном признаке.
В BT-001 пациентке было 34 года; гемоглобин 10,4 г/дл, MCV 72,4 фл, RBC 4,1 × 10¹²/л, ферритин 6 нг/мл и повышенный TIBC. Индекс Ментцера примерно 17,7 поддерживает абсолютный железодефицит. В BT-007 пациент — мужчина 28 лет — имел микроцитоз (MCV 65,8 фл), но высокое число RBC 6,2, нормальный RDW, нормальный ферритин и HbA2 5,6 процента. Индекс Ментцера примерно 10,6 указывает на талассемийный признак, а повышенный HbA2 подтверждает бета-талассемию малую.
Оба случая набрали 1.000. Двигатель явно использовал индекс Ментцера в обоих интерпретациях и вернул правильный диагноз в каждом случае. Это самый клинически обнадёживающий результат во всём бенчмарке, потому что ошибочная классификация признака талассемии как железодефицита приводит к неуместной терапии препаратами железа и упущенным возможностям обследования членов семьи, а ошибочная классификация железодефицита как талассемии задерживает простую заместительную терапию. Наш руководство по диапазонам ферритина объясняет более широкий дифференциальный контекст.
Результаты по каждому кейсу из первоначенного референсного прогона V11 (23 апреля 2026)
Исходный референсный прогон V11 на 15-кейсовой когорте proof-of-concept служит в качестве методологической основы для Second Update: каждая деталь по каждому кейсу ниже показывает, как рубрика обрабатывает реальный ответ движка. Двенадцать из пятнадцати кейсов достигли потолка композитного балла 1.000 по основному пути; три кейса были обслужены через резервный вариант Phase 2, потеряв бонус к задержке 0.05 при сохранении всего клинического и структурного содержания. В одном кейсе отсутствовал один обязательный подраздел; один вернул сумму вероятностного распределения, уменьшенную незначительно.
Дело о СПКЯ (BT-008) потеряло одну обязательную подпосекцию в структуре ответа — пятнадцать из шестнадцати вместо шестнадцати из шестнадцати — из-за чего структурный балл снизился с 1,000 до 0,963. Дело о СКВ (BT-011) вернуло лишь незначительно уменьшенную сумму вероятностного распределения, что снизило клинический балл до 0,965 при сохранении каждого диагностического ключевого слова и системы оценивания. Ни одно из двух случаев с несовершенством не пропустило правильный диагноз.
Агрегированный результат V11 Second Update — 100,000 кейсов
На уровне популяции отдельные строки случаев не читаемы человеком, поэтому Второе обновление сообщает агрегированные метрики, а не таблицу из 100 000 строк. Основной агрегат показан ниже; разбивки по специальностям и по страновым меткам опубликованы в техническом отчете и в депозите Figshare. Стратифицированная случайная выборка из n = 201 сырых ответов движка (детерминированное зерно 20260426) опубликована в репозитории GitHub results/ для проверки.
Что не говорит нам итоговый балл
Составной балл 99,80 процента по этой конкретной предварительно зарегистрированной рубрике для синтетической когорты из 100 000 случаев, охватывающей 127 страновых меток, соответствует почти потолочной производительности — но это требует аккуратной формулировки. Результат описывает поведение движка относительно рубрики, которую мы зафиксировали в исходном коде в V11; это не универсальное утверждение о корректности движка для каждого существующего в реальном мире панели анализа крови.
Показатель говорит о том, что движок корректно обрабатывал диагностические паттерны, выбранные для этой оценки, на когорте в масштабе популяции, по методологии, которая опубликована и воспроизводима. Он не говорит о том, что движок корректен для каждой панели анализа крови, которая существует в реальном мире. Он не говорит о том, что движок должен заменить врачебное суждение. И он не говорит о том, что движок превосходит альтернативные системы ИИ — сравнительные анализы с другими движками были намеренно не включены в рамки этого отчёта.
Что этот показатель действительно устанавливает — это базовый уровень. Поскольку рубрика и стенд публичны, будущие версии движка можно будет оценивать по той же рубрике — применяя её к первичным 15 случаям V11, к когорте из 100 000 случаев Второго обновления или к любому последующему расширению — а разрыв между опубликованным показателем и любым последующим запуском сам по себе поддаётся измерению. В этом ценность предварительной регистрации: она превращает заявления о производительности в проверяемые утверждения.
Как воспроизвести этот бенчмарк за 10 минут
Для воспроизведения достаточно пары учётных данных API Kantesti и среды Python 3.10 или более поздней с requests и reportlab библиотеками, установленными. Полный «стенд» — это один самодостаточный модуль Python, выпущенный под лицензией MIT.
Четыре шага для нового запуска
Один. Клонируйте репозиторий: git clone https://github.com/emirhanai/kantesti-blood-test-benchmark.git. Два. Установите зависимости с помощью pip install -r requirements.txt (Второе обновление добавляет mysql-connector-python ≥ 8.0 для загрузчика SQL case). Три. Задайте KANTESTI_USERNAME и KANTESTI_PASSWORD как переменные окружения для API движка. Для загрузчика SQL case во Втором обновлении также задайте KANTESTI_DB_HOST, KANTESTI_DB_PORT, KANTESTI_DB_NAME, KANTESTI_DB_USER, и KANTESTI_DB_PASSWORD — загрузчик подключается через роль только для чтения (bench_reader), у которой нет прав на идентификацию таблиц. Четыре. Запустите python benchmark_bloodtest.py --limit 100000 для полного запуска Second-Update или python benchmark_bloodtest.py --limit 1000 для быстрой итерации. Результаты сохраняются в ./benchmark_results/: CSV-карточка оценок с колонками по каждой стране/метке и по каждой специальности, JSON-агрегат, стратифицированно-случайная выборка исходных ответов и отчет в Markdown.
Сохраняются эталонные запуски от 23 апреля 2026 года (V11 initial, 15 случаев) и от 26 апреля 2026 года (V11 Second Update, 100,000 случаев) в results/ каталоге репозитория. Новый запуск сформирует новую scorecard с временной меткой, не затрагивая эталонные запуски. Если ваш запуск даёт существенно иной результат, пожалуйста, откройте issue на GitHub с временной меткой запуска и версией движка, указанной в метаданных ответа.
Ограничения и дальнейшая работа
Даже при 100 000 случаев для 127 страновых меток, четыре ограничения требуют явного признания: недостаточная выборка меток с длинным хвостом, оценка в один проход, ограничение одним движком и происхождение данных из одного источника. Каждое из них рассматривается в активных последующих работах.
Покрытие меток с длинным хвостом. Второе обновление охватывает 127 страновых меток, но распределение несбалансировано — на топ-10 меток приходится ≈66,4% случаев, а длинный хвост из 97 дополнительных меток в сумме дает ≈7,3% (примерно 7 300 случаев вместе, ~75 случаев на метку в среднем). Поэтому композиты по меткам в этом длинном хвосте более шумные, чем предполагают заголовочные цифры. В будущих запусках будет выполнена перенастройка назначения меток для уточнения оценок по каждой метке.
Оценка за один прогон. Каждый случай в когорте оценивался один раз. Большие языковые модели демонстрируют заметную вариативность выходных данных даже при низкой температуре выборки, поэтому следующим естественным шагом является протокол с несколькими запусками: пять оценок на каждый случай с сообщением дисперсии — особенно на подмножестве trap-case, где согласованность при «дрожании» выборки является частью заявлений о безопасности.
Охват одним движком. Этот отчёт описывает работу одного движка. Сравнительные анализы с альтернативными ИИ-системами здесь не рассматриваются; мы можем заняться ими как отдельным независимым исследованием с соответствующей методологией, на том же каркасе (harness), лицензированном MIT.
Синтетические данные. 100 000 случаев сгенерированы синтетически, а не являются «синтетическими случаями», и результаты не переносятся на реальные показатели клинической эффективности. Оценка на реальных, полученных с согласия и извне данных потребовала бы соответствующего этического надзора и выходит за рамки этого синтетического бенчмарка.
Помимо этих четырёх, наиболее значимое планируемое расширение — паритет по языкам для каждой юрисдикции. Kantesti AI Engine обслуживает пользователей на 75+ языках, и запуск стратифицированных по языку подвыборок Second-Update (турецкий, немецкий, испанский, французский, итальянский, португальский, арабский, мандарин) позволит количественно оценить качество выходных данных на поддерживаемых движком языках. Каждая стратифицированная по языку аналитика будет опубликована со своим DOI и веткой harness.