Методология «врач-в-цикле» для разработки клинических LLM-фич BloodGPT. Корневое наблюдение: врачи могут разметить конкретный случай быстро и точно, но не могут эффективно ревьюить код или абстрактные гипотезы. Стартовая форма вопроса — не «оцени наш output», а «вот пациент — что здесь важно и почему?». Сначала эксперт смотрит на вход (профиль пациента и его биомаркеры — частый пример; может быть и другой контекст: симптом-описание, документ, конкретная ситуация), отвечает по существу — а мы потом передаём этот ответ Клоду и просим вывести по аналогии правило / инструкцию / связь в графе.
Сегодня в команде один medical advisor — Катя. Эта страница про процесс, который растёт от «один эксперт, ad-hoc» к чему-то масштабируемому.
Зачем
Несколько подзадач BloodGPT упираются в expert input:
- Содержимое graph — какие биомаркеры с какими связаны, rationale, цитаты из guideline’ов. Сегодня правит Артур + Катя в JSON руками; coverage не измерен.
- Сроки жизни / актуальности биомаркеров (biomarker-actuality-service) — какой horizon валиден для какого аналита, при каких контекстных условиях он сокращается или продлевается.
- Калибровка interpretation-боттомов — что для пациента в категории X с диагнозом Y является клинически значимым отклонением, а что — статистическим шумом.
- Golden datasets для eval’ов — какие тест-пациенты, какой expected-вывод, что считается «правильно».
Без врача любая такая задача либо встаёт, либо разработчик галлюцинирует медицину.
Конкретный кейс — а не абстрактный вопрос
Ильдар формулирует подход через аналогию с классическими expert-systems / knowledge-graphs (Prolog, Dental — 80-е). Та же проблема была у них и есть у нас:
Как из эксперта вытащить неявные знания, если он сам не знает, что у него в голове, пока не увидит конкретный случай.
Поэтому место для исследования и вдохновения — литература по тем системам: там 30+ лет накапливали практики knowledge-elicitation, multi-expert agreement, ontology-bootstrapping. Прямого переноса нет, но идея «вместо абстрактного вопроса дать конкретный кейс» — устойчивая.
Эмпирическое правило:
- Не работает: «Катя, опиши всю свою методологию интерпретации лабов».
- Работает: «Катя, вот сгенерированный summary для пациента 42 — что главное, что нет, и почему?»
«С Клодом намного сложнее найти гипотезы, когда ты не знаешь на чём фокусировать его внимание… а у Кати на базе пациентов интуитивно это получается практически всегда».1
Цикл — это data-annotation, не code-review
Главный артефакт цикла — разметка от эксперта. И важное уточнение: это разметка не для обучения ML-модели, а для доработки правил и промптов. Эксперт не «делает train-set», эксперт даёт обоснованные клинические суждения по конкретным случаям, из которых мы выводим формализованные правила.
Так выглядит цикл по сути:
1. Берём конкретный тест-пациент (профиль с биомаркерами + active conditions/medications)
2. Спрашиваем эксперта: «что здесь важно смотреть, почему, что игнорировать?»
(например: время жизни биомаркеров — какие пересдавать первыми, какие нет; и почему)
3. Эксперт отвечает по существу — это и есть его разметка
4. Отдаём разметку Клоду + просим: «выведи по аналогии правило / связь / инструкцию»
5. Полученный артефакт ложится в:
- graph (`biomarker_graph.json`) — новые связи / правки rationale / цитаты
- промпт (если это методологическое правило)
- eval-фикстуры (expected-поле для теста)
По форме это аннотационный pipeline: input → expert-аннотация → LLM выводит автоматизацию. Та же логика что у Tolok-style разметки, только эксперт — врач, а input — клинический профиль.
Стандартные каналы коммуникации хватает
Отдельной системы / UI для этого процесса не нужно изобретать — стандартные бытовые инструменты (мессенджер, голосовое сообщение, общий док) обычно покрывают потребность. Сегодня цикл с Катей работает через Telegram + voice, но это пример, а не требование архитектуры:
- Один тест-пациент + сгенерированный summary → Telegram-сообщение
- Голосовое сообщение с разбором обратно
- Транскрипция + извлечение правок Клодом → структурированные изменения
Для другого эксперта / другой роли подойдут другие каналы (web-форма, аннотация PDF, общий Notion). Главное — у эксперта нативный способ выразить мнение, а конвертацию делает LLM.
Куда это может масштабироваться
Один эксперт = bottleneck. Если методология тест-пациентов работает — её можно масштабировать:
- Студенты-медики на условной Toloka — оплачиваемая разметка тест-пациентов; за умеренное вознаграждение можно собрать большой dataset.
- Пул сотрудничающих врачей — несколько Кать на разных доменах (эндокринология, гематология, кардиология).
- Аннотатор-агенты — LLM сначала размечает, врач только верифицирует/корректирует. Снижает per-task время эксперта.
Если методология «тест-пациенты как форма общения с врачом» подтвердится — открывается путь к масштабированию через внешние ресурсы аннотации.
Этическая сторона: «работник обучает свою замену» — реальная проблема, фабричные параллели (Pakistan-workers с камерой на лбу) показывают как это выглядит в крайнем случае. Не игнорировать в долгом плане.
Открытые вопросы
- Автоматизировать voice→graph-patch. Сегодня Катин фидбэк в voice → Артур + Клод как структуризатор → правка JSON. Нужен tool / лёгкий UI чтобы цикл сжимался до минут. Кандидат на implementation — Артур (любит и умеет такие инструменты собирать).
- Coverage-map graph’а. Чтобы знать кого спрашивать о чём первым — нужен view: какие биомаркеры в biomarker-graph уже размечены Катей, где «белые пятна», какие связи без rationale. Как это построить — открыто; кандидаты: статический отчёт раз в N дней, runtime-метрика на retriever-вызове, отдельный admin-page. Это станет input’ом для priority queue Катиных задач.
- Eval-фикстуры как общий тест-сет. Артур планирует расширять
eval/validity/fixtures/*.json— добавить поля под другие пайплайны (Reasoner, Writer), чтобы те же тест-пациенты переиспользовались как fixture для всех LLM-агентов, не только validity classifier. См. biomarker-actuality-service. - Метрики качества expert input. Если врачей будет несколько — нужна inter-rater agreement; если LLM-аннотатор + врач-верификатор — нужны precision/recall LLM-разметки.
Связано
- biomarker-graph — главный артефакт (
biomarker_graph.json) куда «упаковывается» Катин фидбэк - biomarker-graph — domain-сторона того же графа (медицинские entity / relations)
- biomarker-graph-storage — как этот граф физически хранится / редактируется / версионируется
- biomarker-actuality-service — пример пайплайна, который застрял на гипотезах из общих знаний, и сдвинулся когда Артур начал получать фидбэк от Кати через тест-пациентов
- diagnostician / retriever — потребители graph-content’а Кати
Метод Интроспекции (отладочная техника Артура, когда LLM-ответ расходится с golden dataset — переспросить LLM о собственных решениях) живёт не здесь; это про debugging LLM-пайплайна, не про expert-loop. Описана отдельно — TBD оформить страницу.
Сноски
-
Командный созвон «Сервис валидности / репрезентативности / релевантности биомаркеров», 2026-05-12, https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/2026/05/2026-05-12T11%3A45%3A00.000Z_%D0%A1%D0%B5%D1%80%D0%B2%D0%B8%D1%81_%D0%B2%D0%B0%D0%BB%D0%B8%D0%B4%D0%BD%D0%BE%D1%81%D1%82%D0%B8-%D1%80%D0%B5%D0%BF%D1%80%D0%B5%D0%B7%D0%B5%D0%BD%D1%82%D0%B0%D1%82%D0%B8%D0%B2%D0%BD%D0%BE%D1%81%D1%82%D0%B8-%D1%80%D0%B5%D0%BB%D0%B5%D0%B2%D0%B0%D0%BD%D1%82%D0%BD%D0%BE%D1%81%D1%82%D0%B8_%D0%B1%D0%B8%D0%BE%D0%BC%D0%B0%D1%80%D0%BA%D0%B5%D1%80%D0%BE%D0%B2_01KRE02872CTM2V6CEERAQ8EVD.md — разделы про «методологию тест-пациентов», Telegram-workflow, Toloka-масштабирование, параллель с expert-systems. ↩