Біологічні наукові дані не мають машинного інтерфейсу; додавання шару інструментів може значно підвищити точність ШІ.
Автор статті, джерело: NewZeal
[Вступ] Найкращі AI-кодери розвиваються стрімко, але в біології постійно помиляються — не тому, що моделі недостатньо розумні, а тому, що наукові бази даних до цього часу створювалися лише для людських кліків.
Найпотужніша модель впала там, де не мала: у лічбі?
Недавно Anthropic опублікувала науковий блог під назвою «Paving the way for agents in biology», у якому одна група цифр викликає холод у спині.
https://www.anthropic.com/research/agents-in-biology
Дослідники запропонували кількома найпотужнішими науковими агентами (Claude, GPT, Biomni, Edison Analysis) виконати завдання, яке здається абсолютно простим: точно порахувати кількість вірусних послідовностей у базі даних NCBI Virus, що відповідають певним критеріям.
В результаті жоден з них не зміг стабільно відповісти правильно.
Ще більш дивно, що та сама задача, та сама модель, той самий запит — при трьох запитаннях відповіді можуть відрізнятися в десятки разів.
Claude Sonnet 4 виконує запит на пошук послідовності вірусу Ебола: перший раз повертає 106 результатів, другий — 15, третій — 5. Правильна відповідь — 266.
Чи дійсно штучний інтелект не може займатися біологією?
За цим криється болісна правда: у науковій сфері справжнім слабким місцем агентів є не міркування, а те, що вони зовсім не мають стабільного, відтворюваного, машинно-здійсненного шляху для точного отримання даних.
Без окремого шару пошуку середня точність різних систем варіюється від 16,9% до 91,3%, і хоча нові моделі показують покращення, залишкові помилки залишаються критичними: бо межа проходження для таких завдань насправді становить 100%.
Одна відсутня запис може зробити діагностичний реагент, який, здається, охоплює всі поширені штами, або змістити початок епідемії на кілька тижнів.
Тоді в чому ж справа?
Місто, побудоване для возів, не підходить для автомобілів
Anthropic надав дуже наочний метафору: використання агентів для запуску біологічних баз даних — це наче їхати на автомобілі через старе місто, побудоване до появи автомобілів.
Вулиці можуть бути елегантними й уважно продуманими, але всі вони — вузькі вулички й гострі повороти, створені для кінних екіпажів. Розрізнені бази даних, дивні формати файлів, одноразові скрипти пошуку — це всі частина цього старого міста. Ви можете додати дорожні знаки, відвести кілька паркінгів, розширити одну-дві вулиці, але базова міська структура спочатку не була призначена для автомобілів.
Світ програмного забезпечення — це навпаки. Це нове місто, побудоване для автомобілів: рівні асфальтовані дороги, чіткі смуги руху, стандартизовані світлофори. Системи контролю версій, добре документовані API, менеджери пакетів — цілий комплекс систем, які з самого початку прокладають швидкий шлях від початку до кінця для «автомобілів» (тобто агентів).
Тож кодові агенти розвиваються стрімко, а біологічні агенти залишаються на місці.
У сфері програмного забезпечення надаються структуровані цифрові робочі процеси та надійні інтерфейси: GitHub issue, генерація патчу, запуск тестів, миттєва перевірка. У біологічній сфері надаються вразливі, гетерогенні, залежні від конкретних процесів інфраструктури, майже без простих, перевіряємих та значущих сигналів нагороди.
Щодо NCBI Virus, будь ласка, зробіть це більш наочним. Це суттєво веб-портал. Ви вибираєте умови на веб-сторінці: хазяїн — людина, місце збору — Африка, довжина послідовності більше певного значення, виключити лабораторні пасажі, і лише тоді фонові системи сайту перетворюють ці умови на запити до кількох баз даних (GenBank, RefSeq, INSDC), а потім фільтрують результати для вас.
Головна сторінка порталу NCBI Virus: для пошуку вірусних послідовностей спочатку потрібно вибрати опції на веб-сторінці, ввести ключові слова та натиснути фільтр — вся ця інтеракція розроблена для людей, а не для машин.
Його велика логіка фільтрації написана на рівні веб-сторінки і не надана у вигляді чіткого програмного інтерфейсу.
Для людських вірусологів це просто кілька кліків у браузері. Для машин (агентів) це справжня катастрофа. Агенти можуть безпосередньо викликати лише кілька базових API (REST, Datasets, E-utilities), а ці API не відображають таку саму фільтраційну семантику, як веб-сторінка.
Наведемо конкретний приклад:
На веб-сторінці «Місце відбору в Африці» — це позначка, за якою може приховуватися синхронізація метаданих десятків країн, а також обробка записів із неоднорідними формулюваннями цих полів; умову «містить поверхневий глікопротеїн» неможливо визначити лише за послідовністю — потрібно отримати та порівняти анотації генів/білків для кожного запису з GenBank.
Ці приховані кроки виконує за вас веб-сайт, але початковий API — ні.
Тож агент змушений сам «відгадувати» і знову збирати цю логіку. Якщо щось пропустить — менше обчислень (пропускає послідовність якоїсь африканської країни), якщо помилиться — більше обчислень (неправильно розуміє умови фільтрації).
Саме це є корінною причиною того, що Sonnet 4 у відповідях 106, 15, 5 кожного разу відновлює логіку фільтрації по-різному.
gget virus має вирішити саме це: повторно реалізувати приховану фільтрацію в інтерфейсі веб-сторінки як стабільну, відтворювану та програмно доступну систему, щоб агентам не доводилося кожен раз знову вгадувати.
Помилка в одній послідовності, початок пандемії зміщений на кілька тижнів
Якщо ви вважаєте, що «перерахувати кілька послідовностей» — це не важливо, цей прямий ефір змінить вашу думку.
У травні 2026 року в Конго (Білорусь) виникла вибухова епідемія еболи бандібу-джо. 14 травня INRB у Кіншасі проаналізував 13 зразків крові, а наступного дня підтверджено 8 випадків. До 29 травня ВООЗ повідомила, що кількість підтверджених та підозрюваних випадків перевищила 1000, а кількість смертей перевищила 200.
Перед дослідниками стоять три життєво важливі питання: наскільки цей вірус відрізняється від попередніх? Чи все ще можна виявити його за допомогою існуючих діагностичних засобів? Чи залишаються ефективними існуючі методи лікування?
Відповіді на ці питання вимагають поетапного порівняння нового геному з історичними геномами Еболи з NCBI Virus. Першим кроком цієї аналітичної процедури є ручне клікання на веб-сторінці та ручне відтворення довгого списку складних умов фільтрації, після чого треба сподіватися, що отриманий набір даних є повним і правильним.
Дослідники використали попередній запит про Еболу, щоб Sonnet 4 отримав дані та побудував філогенетичне дерево для оцінки «часу найближчого спільного предка (TMRCA)». Це ключовий показник для визначення початку епідемії.
Дані, вручну перевірені експертами, вказують на TMRCA 2014 рік, січень, що збігається з попередніми повідомленнями.
Три набори даних, отриманих Sonnet 4, містять дві очевидно неповні версії. Один з них переніс розраховану дату походження з 2014 року назад на 1922 рік, додавши випадково дев’яносто років. Інший виглядав правдоподібно, але пропустив серію для Гвінеї та тихо змістив дату походження на квітень 2014 року, переписавши таким чином хронологію.
Філогенетичне дерево зайрського еболи: у верхньому лівому куті — ручна корекція даних, Run 1–3 — результати пошуку Sonnet 4. Червона пунктирна лінія позначає TMRCA, сірий колір — відсутня або неправильна інформація про країну.
Те саме стосується аналізу антитільної терапії. Дослідники хотіли перевірити, чи раніше з’являлися мутації в місцях, на які спрямовані дві ебола-антитільні терапії — мафтивімаб і MBP134, щоб визначити, чи зможуть ці терапії наздогнати еволюцію вірусу. В результаті Sonnet 4 тричі вивів три абсолютно різні картини мутацій.
Розподіл мутацій глікопротеїну Еболи заїрського типу: чим глибший червоний колір, тим вища частота; сфери позначають сайти зв’язування антитіл maftivimab та MBP134. Найлівіше — штучно відкориговані дані, результати трьох пошуків Sonnet 4 (запуск 1–3) відрізняються.
Моделі невдачі очевидні: якщо зупинитися під час отримання великої вибірки, ви пропустите деякі записи; якщо неправильно використовувати умови фільтрації, ви отримаєте надлишок. Записи про грип A, ВІЛ-1 та інші віруси з величезною кількістю даних мають найбільший зсув. Як тільки кількість паралельних умов фільтрації перевищує три-чотири, продуктивність різко падає.
Помилка, яку виправдовують, — це найстрашніший вид помилки в науці.
Прокопати тунель для машин у старому місті
Як це виправити?
Дослідники Anthropic та NCBI спільно створили річ під назвою gget virus.
Це не ще один нудний «AI-плагін», а визначальний шар пошуку. За суттю, він перетворює механізми фільтрації з веб-інтерфейсу NCBI Virus у повторюваний програмний системний підхід.
Технічно він координує кілька нижчих систем — REST, Datasets, E-utilities, автоматично визначаючи, які фільтри можна застосувати через API, а які треба перевіряти локально. Він обробляє пакетне отримання даних, забезпечуючи повне завантаження великих наборів результатів, а не їх переривання посеред процесу.
Він завантажує вірусні нуклеотидні послідовності та пов’язані метадані з системи INSDC (NCBI, ENA, DDBJ), виводячи дані у форматах, зрозумілих для людей і машин: FASTA, CSV, JSONL, а також надає детальні журнали, які пояснюють, як саме було отримано цей результат. Для частих запитів він зменшує обсяг передаваних даних більше ніж на 98%.
Ефект відразу помітний.
Після підключення gget virus, точність усіх тестованих систем зросла до понад 90,0%, GPT-5.5 досяг 99,7%. Випадкові коливання між запусками майже зникли, стабільність підвищилася до 0,92–1,00.
Найкраще те, що різниця між моделями також значно зменшилася.
Точність пошуку агентів на базі VirBench: після підключення gget virus (темний) усі показники перевищили 90%, найправіший — gget virus у власному виконанні.
Після додавання шару інструментів з визначеністю, яку модель ви використовуєте, стає менш важливим.
Це саме те, на що варто звернути увагу.
Побудова надійного набору даних не повинна залежати від того, чи можете ви дозволити собі найновішу та найдорожчу модель, чи випадково знаєте, яка модель найкраще підходить для певної бази даних. Дешева модель у поєднанні з правильними інструментами працює не гірше.
Ще один цікавий деталь: за 360 запусків GPT-5.5 самостійно знайшов і використав gget virus, не отримавши жодних підказок — і саме цей раз був єдиним, коли він правильно відповів на це завдання.
Цінність інструменту сама по собі була підтверджена моделлю.
Справжній ключ до перемоги — перехід від моделі до фундаменту
Застосуйте ширший погляд — це стосується не лише вірусу.
Те саме тертя виникає в кожному середовищі, створеному «для людей, а не для агентів».
Кілька місяців тому Карпаті розповідав про програмне забезпечення в епоху ШІ, засміючись над тим, як він робив малий веб-застосунок за допомогою vibe coding, але на реальне запускання (авторизація, оплата, розгортання) витратив цілий тиждень, клікаючи по браузері. Його висновок: «Написання коду — це найпростіша частина».
Слайди промови Карпатського «Docs for people»: документація з налаштування сервісів, таких як Vercel, Clerk тощо, повністю розроблена для людей — «натисніть тут, заповніть там» — і не може бути викликана безпосередньо LLM.
Біологи, прослухавши скарги Карпаті, можуть добре зрозуміти цю боль: вони, можливо, вже багато років терпіли таке.
gget virus — це не виняток; до таких «контекстних двигунів» належать також ToolUniverse, Robin, Biomni та інші біомедичні агенти.
Проблема полягає в тому, де саме слід розмістити визначеність і як її правильно побудувати.
Звичайно, хтось може запитати: якщо модель розвивається настільки швидко, що колись агенти стануть настільки потужними, що зможуть самостійно перетинати хаотичні ворота, вирівнювати ID, правильно переключати сторінки та самовідновлюватися при помилках, чи не зникнуть такі «скелети», як gget virus, миттєво?
Можливо. Але відповідь Anthropic: навіть якщо агент здатний це зробити, це не означає, що йому варто кожного разу винайти все знову.
Модель, яка здатна самостійно пройти цей хаотичний процес отримання даних, може бути занадто дорогою, занадто повільною, занадто складною для аудиту та занадто важкою для довіри, щоб підтримувати щоденні наукові дослідження.
Тим більше, навіть якщо скелети колись застаріють, уроки біологічних баз даних залишаються в силі: з цього моменту слід сприймати агентів як масових користувачів і будувати їх із розрахунком на масштабне використання з самого початку.
На поверхні цей конкурс — хто з моделей розумніша. Глибше — йдеться про те, хто має кращу основу для бігу машин.
Ми хочемо, щоб модель була вільною у генерації гіпотез та проектуванні експериментів. Але той нижній шар: ідентифікатори генів, схема даних, логіка пошуку, система координат, домовленості щодо метаданих — має бути абсолютно надійним і «втомлюючо» точним.
Крива моделі все ще піднімається.
Але справжнім ключем цієї гри, можливо, є не хмарні великі моделі, а той нижній шар інфраструктури даних, який ніхто не хоче виправляти, але від якого залежить успіх або невдача.