Quartz 4

Health-claims как facts: structured substrate для generation (patient/doctor/...)

active
Not verified

Created · Updated 3 min read

Variant D)

Контекст pipeline — biomarker-analysis-pipeline. Расположение в общей архитектуре — recognition-enrichment-hourglass (split внутри нижнего конуса песочных часов). Текущий audience-split — doctor-patient-prompts-not-fork. Этот decision — апгрейд Generator-шага: разделить reasoning (substrate-builder) и rendering (writer per audience) на 2 шага.

Рассматривали

A. 1 generator-prompt per audience (предыдущее состояние, doctor-patient-prompts-not-fork)

Один pipeline, два промпта (patient / doctor). Внутри каждого generator-промпта LLM делает И reasoning И rendering. Audience определяется промптом.

B. extract facts → N renderers (выбрано)

FHIR data + interpretation context
    │
    ▼
[1] Health-claim extractor (LLM): bullets / structured facts
    Например: { claim: "холестерин выше нормы на 15%",
                evidence: [Observation/glucose-1],
                severity: "borderline",
                category: "lipid_panel" }
    │
    ▼
[2] Renderer per audience (LLM):
    - patient: упрощённый язык
    - doctor: медицинская терминология
    - relative / другой врач / страховая — добавляются как renderer

Внутри B рассматривали два sub-варианта:

  • Sequential translator. Сначала doctor-версия, затем дистилляция в patient-версию вторым LLM-вызовом.
  • Parallel writers (выбрано). Patient и doctor writer работают одновременно поверх identical substrate.

Аргумент против sequential — приоритизация фактов застревает в первом вызове, второй только переформулирует, теряя возможность audience-specific акцентов на substrate-уровне. Аргумент за parallel — акценты задаются в substrate (детерминированно, проверяемо кодом), writer’ы занимаются только стилем и языком.

За

  • Consistency claims между аудиториями — все основаны на одном set’e facts.
  • Add new audience = новый renderer, не новый risky prompt со своей generation logic.
  • Tracing: каждый текстовый блок → какой claim → какой evidence (FHIR resource). Хорошо для review / explainability / regulatory.
  • Renderer per model: Pro для сложного doctor-rendering, Flash для patient (см. gemini-flash-vs-pro-allocation).
  • Концептуальная параллель с fact-based-recognition: «extract structured → render» на разных слоях pipeline.

Следствия

  • doctor-patient-prompts-not-fork становится частным случаем (2 audience) более общего pattern. Active паттерн остаётся, но теперь явно — 2 writer-промпта поверх общего substrate, не 2 независимых generator-промпта.
  • 2-фазный Generator: extractor + renderer (writer per audience).
  • Расширяет 3-agent pipeline до 4-step: Diagnostic → Retriever → Substrate-builder → Writer.
  • Цензура и контроль качества — на уровне substrate (часть проверок кодом), не финальных текстов. Substrate-уровневая фильтрация по diagnoses/conditions/medications для пациентской версии отвергнута (patient-content-filter) — разница реализуется через prompt-level инструкции, обе версии работают поверх identical input. Финальная защита от leakage — post-hoc на текстах.
  • TTL биомаркеров фильтрует substrate на retrieval-уровне: out-of-date параметры не передаются в context (см. biomarker-actuality-thresholds).
  • Версионирование health-status: при появлении новых данных substrate обновляется, writer-промпты могут перегенерировать выходы без переоценки фактов.

Открытые вопросы

  • Renderer всё равно LLM, добавляет latency и cost к pipeline.
  • Schema для facts (severity / category / evidence references) — нужно подобрать.
  • Schema размещения в FHIR (Observation.note[] aggregation / ClinicalImpression.summary / новое расширение) — пересекается с foundcontext-fhir-mapping.
  • Naming для extractor / renderer ролей не закреплён.
  • Связь с health-report-vision — substrate можно переиспользовать для перегенерации новых версий snapshot’а без повторного reasoning.

Связано

Источники

Источники: 1 2 3 4 5.

Сноски

  1. 2026-04-27 Daily + Sprint Planning, accessed 2026-05-17, https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/2026/04/2026-04-27T08%3A00%3A00.000Z_Daily_%2B_Sprint_Review%26Planning_01KPX39F5EMF092HA0PGKSX1FV.md. ↩

  2. 2026-04-27 Health status-centric юзер флоу, accessed 2026-05-17, https://github.com/Realai-plus/meeting-digests/blob/main/data/digest/2026/04/2026-04-27T17%3A00%3A00.000Z_Health_status-centric_%D1%8E%D0%B7%D0%B5%D1%80_%D1%84%D0%BB%D0%BE%D1%83_01KQ7WPNNMNBT3K8NDZQXM2321.md. ↩

  3. Сессия ildar/34e93701, 2026-04-24 — ` — Ильдар развивал идею. ↩

  4. Сессия ildar/0dfd285d, 2026-03-17 — `. ↩

  5. 2026-04-24 Slack thread (Ильдар, #ai-engineering), accessed 2026-05-17, https://realaicorp.slack.com/archives/C094GRT3CBY/p1777040691399849?thread_ts=1776356279.568619 — Carry-over: schema substrate (как именно выглядит «сухая инструкция»), куда сохранять в FHIR — TBD.. ↩

Graph View

Backlinks