Защо съществува този бенчмарк и какво тества
AI подпомогнатото кръвни изследвания тълкуване все по-често се използва в потребителски и клинични процеси, но възпроизводими рамки за оценка, пригодени за лабораторна медицина, остават сравнително редки. Въпросите, които имат най-голямо значение в тази среда, не са тези, обхванати от общи бенчмаркове за медицинско въпрос-отговор: може ли един двигател да отдели желязодефицит от таласемична черта, когато средният обем на еритроцитите е идентичен; наддиагностицира ли синдрома на Гилбърт като хепатит; и създава ли „патология“ в напълно нормален скринингов панел?
Единен панел от кръвни изследвания обикновено съдържа достатъчно информация, за да подкрепи няколко конкуриращи се интерпретации, а задачата на лекаря, който интерпретира, е да претегли тези интерпретации една спрямо друга, вместо да извлече „правилен“ отговор от учебник. Двигател, който се справя добре с казуси от учебников тип, може все пак да се провали именно в най-важните случаи: капаните при диференциалната диагноза, доброкачествените варианти, които изглеждат тревожни, когато се разглеждат изолирано, и напълно нормалните панели, които изкушават уверени асистенти да „произвеждат“ патология.
Този бенчмарк е създаден точно около тези механизми на провал. Всеки от петнадесетте случая е подбран за конкретна диагностична особеност: микроцитоза при дефицит на желязо, която трябва да се различава от носителство на бета-таласемия с идентичен среден обем на еритроцитите, клинична картина при синдром на Гилбърт, при която единствената аномалия е изолирана индиректна хипербилирубинемия, и скринингов панел с петнадесет параметъра, в който всяка анализирана величина се намира в референтния си диапазон. Критерият възнаграждава двигатели, които четат всеки случай според собствените му условия, и наказва двигатели, които стигат до уверена диагноза, когато такава диагноза не е оправдана.
Като д-р Томас Клайн избрах панелите от случаи, защото това са моделите, които асистентите по лабораторна медицина най-често разбират погрешно. Скъпият механизъм на провал не е "пропускане на рядко заболяване" — а измисляне на рутинна патология при пациенти, които нямат такава. Нашите Медицинско валидиране hub описва по-широката рамка; тази страница описва първоначалното proof-of-concept на V11 и V11 Второто обновление, което го мащабира до 100,000 синтетични случая, извлечени от синтетичен набор от случаи, обхващащ 127 етикета за държави — използвайки същата система за оценяване, идентична по байтове, без разрешено „post-hoc“ настройване.
Най-ново референтно изпълнение — V11 Second Update (26 април 2026)
Референтното изпълнение на V11 Second Update от 26 април 2026 генерира композитен резултат от 99.80% по същата предварително регистрирана рубрика, използвана в първоначалното издание V11, оценена на 100,000 синтетични случая извлечени от Kantesti синтетичния набор от случаи и обхващащи 127 етикета за държави и 75+ езици. Всеки случай завърши по основния път на двигателя; активациите на флага за хипердиагностичен „trap-case“ останаха на 0 / 87,412. Първоначалното изпълнение V11 от 23 април 2026 обхвана 15 ръчно подбрани случая (композит 99.12%) и валидира рубриката; Second Update запазва тази рубрика идентична по байтове и разширява оценката до кохорта с мащаб на популация.
Композитната формула комбинира три компонента: структурно съответствие с седемте задължителни раздела на отчета и шестнадесет задължителни подраздела, точност на съдържанието измерена като припомняне на ключови думи плюс припомняне на резултатната система плюс проверка за валидност на вероятностното разпределение, и латентност на отговора спрямо целта за ниво на услугата по основния път. Точното разлагане е показано във формулата на рубриката по-долу — нито тези тегла, нито под-рубрики са променяни за Second Update.
Останалите 0.20 процентни пункта „резерв“ се разлагат почти изцяло в клиничния подрезултат — малка част от случаите (предимно в Хепатология и Ревматология) имаха една очаквана ключова дума от системата за оценяване, която липсваше в интерпретацията на двигателя, въпреки че диагностичното съдържание беше правилно. Нито един случай в кохортата от 100 000 случая за Second Update не пропусна самата диагноза. Латентността се подобри от средна стойност 20.17 s в първоначалното издание V11 до 13.26 s в Second Update, отразявайки оптимизации на производствения двигател между двете изпълнения; рубриката, кодът за оценяване и API endpoint са без промяна.
Композитните резултати по етикет варираха от 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 обхващаше седем специалности — хематология, ендокринология, метаболитна медицина, хепатология, нефрология, кардиология, ревматология — плюс два специално предназначени „hyperdiagnosis trap“ случая, като всеки случай е синтетично генериран панел за кръвни изследвания. Второто обновление на V11 разширява оценяването до 100,000 синтетични случая в 127 етикета за държави, разпределени в осем специалности (оригиналните седем плюс специална „вътрешни болести“ категория, която поема trap подмножеството). Същата рубрика за оценяване се прилага идентично по байтове и в двете изпълнения.
Тъй като всички случаи са синтетично генерирани, няма реални идентификатори за премахване и не се включват лични данни. Всеки синтетичен случай носи вътрешен за бенчмарка код на случая (BT-NNN-LABEL в първоначалния набор на V11, стабилен case_uid във Второто обновление). Никакви лични данни не се появяват никъде в публикуваната среда за оценяване, техническия доклад или пуснатите набори от данни.
първоначалното издание V11 — 15 ръчно подбрани случая
Оригиналният панел за случаи V11 е подбран ръчно от д-р Томас Клайн, за да упражнява диагностичните модели, които най-често се допускат от асистенти в лабораторната медицина. Всеки от петнадесетте случая е подбран за конкретна диагностична характеристика, изброена по-долу.
Защо точно това разпределение
Хематология получава три случая, защото микрoцитните диференциални диагнози и макроцитните диференциални диагнози са най-обемните „капани“ в реалната лабораторна практика. Ендокринологията получава три, защото проявите при Хашимото, PCOS и дефицит на витамин D имат различни диагностични „форми“ (задвижвани от автоантитела, задвижвани от хормонални съотношения, задвижвани от единичен маркер). Специалностите с по един случай остават значими, защото при всеки от CKD, риска от ASCVD и SLE има собствена система за оценяване, която двигателят трябва да извика (съответно стадиране по KDIGO, 10-годишен риск по ASCVD, критерии за SLE от 2019 EULAR/ACR).
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. Тези бройки етикети са свойства на генерираните случаи, използвани за упражняване на обработката на локализация — те не са реални потребители и не представляват реално географско покритие.
Предварително регистрираната рубрика, обяснена
Регистрацията преди започване (pre-registration) е най-важният методологичен избор в този бенчмарк. Всяка очаквана диагноза, всяка клинична система за оценяване и всяка секция в отчета са ангажирани към изходния код преди да бъде извикан двигателят. Следователно пост-хок настройване на рубриката, за да „погали“ двигателят, е невъзможно.
Три компонента формират композитния резултат. структурният компонент допринася 35 процента и измерва дали двигателят е върнал седемте задължителни секции на отчета (заглавна част, обобщение, ключови находки, диференциал, системи за оценяване, препоръки, проследяване) и шестнадесетте задължителни под-секции в рамките на тях. Наличието на секции тежи 40 процента, а наличието на под-секции тежи 60 процента в структурното изчисление.
The клиничният компонент допринася 55 процента и комбинира три неща: припомняне на диагностични ключови думи (70 процента от клиничния под-резултат), припомняне на системи за оценяване (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 секунди отразява производствената цел за ниво на обслужване за първичната услуга; таванът от 40 секунди отразява резервния бюджет за „fallback“ във Фаза 2 при тежки извиквания на двигател.
Какво предотвратява pre-registration
Първо-лицевите (first-party) бенчмаркове са известни с това, че надуват собствените си резултати чрез пост-хок настройване на рубриката. Моделът почти винаги е същият: екипът пуска двигателят, вижда къде се представя зле, а след това тихо настройва рубриката така, че зоните с недостатъчно представяне да „тежат“ по-малко. Като ангажира рубриката към изходния код преди първото извикване на двигател и публикува хранилището под лиценз MIT, тази настройка става видима в системата за контрол на версиите. Всеки може да клонира репозитория, да провери датите на авторство на рубриката и да потвърди, че резултатите от двигателят не са били използвани за оформяне на оценяването.
Казуси за хипердиагностика — защо прекаленото „обаждане“ е истинският режим на провал
Агресивното прекомерно „обаждане“ на патология при нормални екрани е документиран режим на отказ при медицински асистенти, насочени към потребители. Последващите разходи включват ненужно изследване, тревожност на пациента и ятрогенна обработка. Двата „капанови“ случая в този бенчмарк са проектирани да направят този режим на отказ видим и подлежащ на оценяване.
🟡 Капан 1 — BT-014-GILBERT
Проява. Мъж на 24 години с общ билирубин 2.4 mg/dL. Директната фракция е нормална, трансаминазите и алкалната фосфатаза са в рамките на референтните им стойности, ретикулоцитите са без особености, а хаптоглобинът и LDH изключват хемолиза.
Правилно тълкуване. Синдром на Гилбърт — доброкачествен полиморфизъм на UGT1A1. Тълкуването не трябва да извиква хепатит, цироза, хемолитична анемия или билиарна обструкция.
Резултат v11. Композитен 1.000. Нито един от шестте наблюдавани флага за свръхдиагностика не се появи като активна диагноза.
🟡 Капан 2 — BT-015-HEALTHY
Проява. Жена на 35 години с рутинен скринингов панел с петнадесет параметъра. Всяка аналитична стойност се намира удобно в рамките на референтния си диапазон.
Правилно тълкуване. Успокоение и поддържане на начина на живот. Тълкуването не трябва да „измисля“ гранична патология, за да звучи клинично полезно.
Резултат v11. Композит 1.000. Нито една от седемте наблюдавани аларми за свръхдиагностициране — диабет, анемия, хипотиреоидизъм, дислипидемия, хепатит, бъбречно заболяване, дефицит — не се появи като активна диагноза.
И в двата „капака“ бяха проверени тринадесет наблюдавани аларми за свръхдиагностициране. Нито една не се задейства. Това е резултатът, който има най-голямо значение за всеки клиницист, който обмисля използването на AI двигател като инструмент за триаж или предконсултационна оценка: системата не е измислила заболяване, когато такова не е съществувало.
Индекс на Mentzer: разграничаване на дефицит на желязо от носителство на таласемия
Второто високостойностно откритие се отнася до съчетаването на случай BT-001 (желязодефицитна анемия) с случай BT-007 (бета-таласемия минор). И двата случая се представят с микроцитоза и са добре известна спънка за наивни класификатори. Индексът на Mentzer, изчислен като MCV, разделено на броя на RBC, е над 13 при желязодефицит и пада под 13 при таласемичен признак.
В BT-001 пациентът е 34-годишна жена с хемоглобин 10.4 g/dL, MCV 72.4 fL, RBC 4.1 × 10¹²/L, феритин 6 ng/mL и повишен TIBC. Индексът на Mentzer, приблизително 17.7, подкрепя абсолютен железен дефицит. В BT-007 пациентът е 28-годишен мъж с микроцитоза (MCV 65.8 fL), но с висок брой RBC 6.2, нормален RDW, нормален феритин и HbA2 5.6 процента. Индексът на Mentzer, приблизително 10.6, насочва към таласемичен признак, а повишеният HbA2 потвърждава бета-таласемия минор.
И двата случая са получили 1.000. Двигателят е използвал изрично индекса на Mentzer и в двете интерпретации и е върнал правилната диагноза във всеки отделен случай. Това е най-еднозначно успокояващият клинично резултат в целия бенчмарк, защото грешното класифициране на таласемичен признак като желязодефицит води до неподходяща добавка с желязо и пропуснати възможности за скрининг на фамилията, а грешното класифициране на желязодефицит като таласемия забавя лесната заместителна терапия. Нашият диапазон за феритин обяснява по-широкия диференциален контекст.
Резултати по случай от първоначалното референтно изпълнение на V11 (23 април 2026)
Оригиналното референтно изпълнение на V11 върху кохортата за proof-of-concept от 15 случая служи като методологична основа на Second Update: всеки детайл по случай по-долу показва как рубриката обработва реален отговор на двигател. Дванадесет от петнадесетте случая постигнаха таванния композитен резултат 1.000 по основния път; три случая бяха обслужени чрез fallback на Phase 2, като загубиха бонуса за латентност 0.05, но запазиха цялото клинично и структурно съдържание. Един случай липсваше една единствена задължителна подсекция; един върна леко намалена сума на вероятностното разпределение.
Случаят с PCOS (BT-008) загуби една задължителна подрубрика в структурата на отговора — петнадесет от шестнадесет вместо шестнадесет от шестнадесет — което свали структурния резултат от 1,000 до 0,963. Случаят със SLE (BT-011) върна гранично намалена сума на вероятностното разпределение, която понижи клиничния резултат до 0,965, като запази всяка диагностична ключова дума и система за оценяване. Нито един от двата случая с резултат под перфектния не пропусна правилна диагноза.
Агрегат V11 Second Update — 100,000 случая
На ниво популация отделните редове на случаите не са четими от хора, затова Второто обновление отчита агрегирани показатели вместо таблица с 100 000 реда. Основният агрегат е показан по-долу; разбивките по специалност и по етикет за държава са публикувани в техническия доклад и в депозита Figshare. Стратифицирана случайна извадка от n = 201 сурови отговори на двигателя (детерминирана seed 20260426) се публикува в директорията на GitHub results/ за преглед.
Какво не ни казва водещият (headline) резултат
Композитен резултат от 99.80 процента по тази конкретна предварително регистрирана рубрика, върху синтетичен кохорт от 100,000 случая, обхващащ 127 етикета за държави, представлява почти „таванно“ представяне — но заслужава внимателно рамкиране. Резултатът описва поведението на двигателя спрямо рубриката, на която се ангажирахме в изходния код в V11; това не е универсално твърдение за коректността на двигателя върху всяка съществуваща в реалния свят панел за кръвни изследвания.
Резултатът казва, че двигателят е обработил правилно диагностичните модели, избрани за това оценяване, в кохорт в мащаб на популацията, по методология, която е публикувана и възпроизводима. Той не казва, че двигателят е коректен за всеки кръвен изследователен панел, който съществува в реалния свят. Не казва и че двигателят трябва да замества клиничната преценка. И не казва, че двигателят превъзхожда алтернативни AI системи — сравнителните анализи спрямо други двигатели умишлено бяха извън обхвата на този доклад.
Това, което резултатът установява, е базова линия. С рубриката и средата (harness) публични, бъдещите версии на двигателя могат да бъдат оценявани спрямо същата рубрика — приложена към първоначалните 15 случая на V11, кохорта от 100,000 случая от Второто обновяване или всяко последващо разширение — а разликата между публикувания резултат и всяко последващо изпълнение е сама по себе си измерима. Това е стойността на предварителната регистрация: тя превръща твърденията за представяне в проверими твърдения.
Как да възпроизведете този бенчмарк за 10 минути
Възпроизводимостта изисква само двойка идентификационни данни за Kantesti API и среда с 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 loader). Три. Задайте KANTESTI_USERNAME и KANTESTI_PASSWORD като променливи на средата за API на двигателя. За SQL case loader-а при Второто обновяване също задайте KANTESTI_DB_HOST, KANTESTI_DB_PORT, KANTESTI_DB_NAME, KANTESTI_DB_USER, и KANTESTI_DB_PASSWORD — loader-ът се свързва чрез роля само за четене (bench_reader) която няма привилегии за идентифициране на таблици. Четири. Стартирайте python benchmark_bloodtest.py --limit 100000 за пълното изпълнение Second-Update, или python benchmark_bloodtest.py --limit 1000 за бърза итерация. Резултатите се записват в ./benchmark_results/: CSV табло с колони за етикетите за държави и специалностите, JSON агрегат, стратифицирана случайна извадка от сурови отговори и Markdown доклад.
Референтните изпълнения от 23 април 2026 г. (V11 първоначално, 15 случая) и 26 април 2026 г. (V11 Second Update, 100,000 случая) са запазени в results/ директорията на репозитория. Ново изпълнение ще генерира нов scorecard с нов времеви печат, като остави референтните изпълнения незасегнати. Ако вашето изпълнение даде съществено различен резултат, моля, отворете GitHub issue с времевия печат на изпълнението и версията на engine-а, върната в метаданните на отговора.
Ограничения и бъдеща работа
Дори при 100 000 случая и 127 етикета за държави, четири ограничения заслужават изрично признаване: недостатъчно представяне на етикетите от дългата опашка, оценка „еднократен изстрел“, обхват само на един двигател и произход само от един източник на данни. Всяко от тях се адресира в активна последваща работа.
Покритие на етикетите от дългата опашка. Второто обновление обхваща 127 етикета за държави, но разпределението е небалансирано — топ 10 етикета представляват ≈66.4% от случаите, а дългата опашка от 97 допълнителни етикета заедно допринася ≈7.3% (приблизително 7 300 случая общо, ~75 случая на етикет средно). Следователно композитите по етикет в тази дълга опашка са по-шумни, отколкото подсказват основните (headline) стойности. Бъдещи изпълнения ще ребалансират присвояването на етикетите, за да се затвърдят оценките по етикет.
Еднократно оценяване. Всеки случай в кохортата беше оценен веднъж. Големите езикови модели показват съществена вариативност на изхода дори при ниска температура на семплиране, така че протокол с множество изпълнения с пет оценки на случай и отчетена вариативност е естествена следваща стъпка — особено върху подмножеството с „trap cases“, където последователността при „jitter“ от семплирането е част от твърдението за безопасност.
Обхват само на един двигател. Този отчет описва един engine. Сравнителни анализи спрямо алтернативни AI системи са извън обхвата тук; можем да ги разгледаме като отделно независимo изследване с подходяща методология, спрямо същия MIT-лицензиран harness.
Синтетични данни. 100,000-те случая са синтетично генерирани, а не „синтетични случаи“, и резултатите не се прехвърлят към реално клинично представяне. Оценяване върху реални, дадени с информирано съгласие, външно набавени данни би изисквало подходящ етичен надзор и е извън обхвата на този синтетичен бенчмарк.
Освен тези четири, най-възддействащото планирано разширение е равнопоставеност по езици за всяка юрисдикция. Kantesti AI Engine обслужва потребители на 75+ езика, а изпълнението на стратифицирани по език под-кохорти за Second Update (турски, немски, испански, френски, италиански, португалски, арабски, мандарин) ще измери качеството на изхода в поддържаните от engine-а езици. Всяка езикова стратифицирана оценка ще бъде публикувана със собствен DOI и branch на harness-а.