Python 醫療預約助手的語義檢索故障隔離與高負載回退設計

Short answer: keep semantic retrieval off the appointment system's authority path, enforce one end-to-end latency budget, and fall back to deterministic filters or clarification before the assistant can present a slot.

That decision separates two questions that are often collapsed into one: which clinicians might satisfy a request such as "a Mandarin-speaking dermatologist near Northside," and which appointments can actually be booked. Retrieval can answer the first question imperfectly. Only the scheduling source of record can answer the second. A fallback is therefore a controlled loss of recall, not permission to relax insurance, location, specialty, or availability constraints.

This is an architecture decision record for a healthcare appointment assistant whose retrieval quality competes with response latency. The numbers below are example policy values, not benchmark claims; measure them against your own traffic, corpus, and booking workflow.

Decision record and non-negotiable invariants

Use semantic retrieval to produce candidate provider IDs, then re-read current structured data before showing any appointment. Give the retrieval stage a bounded share of the request deadline. If it times out, returns too few usable candidates, or produces results that fail hard filters, step down to lexical and structured retrieval. If those paths still cannot support the user's constraints, ask one focused clarification question.

Stop there.

The core invariant is simple: a retrieved passage may explain why a provider looks relevant, but it cannot certify that a slot exists. The assistant must never transform an old biography, cached schedule fragment, or generated sentence into bookable inventory. A second invariant is monotonic constraint handling: each fallback may broaden soft preferences, such as distance or preferred time of day, only when policy permits; it must not silently remove hard constraints. A third is traceability. Every presented result should retain the query, retrieval path, candidate ID, applied filters, source version, and final availability check so an operator can reconstruct why it appeared without storing more patient text than the audit purpose requires.

Retrieval-augmented generation is useful here because it conditions generation on retrieved non-parametric memory rather than expecting the language model alone to carry all domain knowledge. The original RAG paper demonstrates that general pattern with a dense vector index. It does not make a healthcare scheduling index authoritative, current, or safe by itself. Those are application-level properties.

The failure boundaries deserve names because "search failed" is too vague to operate:

• Deadline exhaustion: the semantic path has not completed inside its allocated budget.
• Empty or thin recall: the path returns no candidates, or too few after hard filters.
• Stale evidence: descriptive content and scheduling records have different versions or refresh times.
• Constraint loss: a paraphrase improves semantic similarity while dropping a required specialty, location, language, or coverage condition.
• Ambiguous intent: "heart doctor next week" lacks enough information to choose the correct specialty or location policy.

Notice what isn't on that list: a low similarity score isn't automatically a system failure. Score scales depend on the model, index, corpus, and query distribution. I'm not sure a universal threshold would even be meaningful here; a labeled local evaluation set and observed score distributions are what resolve that uncertainty.

How should a healthcare appointment assistant handle semantic retrieval fallbacks?

Treat the fallback ladder as a state machine with explicit entry conditions, rather than a catch-all exception handler. This comparison is intentionally about failure behavior, not vendor selection.

This ladder should share one deadline. Three independent one-second timeouts can turn into roughly three seconds of serial waiting, so the policy should pass a shrinking deadline to every stage and decline to start work that cannot finish usefully. The exact budget varies by channel and deployment; for an illustrative 900 ms application budget, a team might reserve 250 ms for semantic retrieval and keep the rest for deterministic retrieval, availability validation, response construction, and network variance. Those values are design inputs. They aren't performance promises.

Quality also needs a definition more precise than "the result looked relevant." Build test cases from de-identified or synthetic appointment intents, label acceptable provider candidates, and evaluate the entire ladder. Track recall after hard filters, the share of requests reaching each fallback, clarification rate, empty-result rate, and latency by stage and percentile. Then slice by specialty, language, location, and query form. An aggregate score can hide a path that works for common primary-care language while consistently losing less frequent specialty terms.

Don't optimize the semantic top result in isolation. The useful outcome is a small set of valid candidates reaching the live availability check before the deadline.

The critical path in Python

The following code sketches the orchestration boundary. Its adapters are deliberately generic: retrieval implementations can change, while the constraint and authority rules stay in one place. The 250 and 900 millisecond values are sample policy settings that should be replaced by measured service objectives.

from dataclasses import dataclass
from time import monotonic
from typing import Protocol


@dataclass(frozen=True)
class Intent:
    specialty: str | None
    location: str | None
    language: str | None
    free_text: str


@dataclass(frozen=True)
class Candidate:
    provider_id: str
    evidence_version: str
    path: str


class Retrieval(Protocol):
    def semantic(self, intent: Intent, timeout_ms: int) -> list[Candidate]: ...
    def lexical(self, intent: Intent, timeout_ms: int) -> list[Candidate]: ...
    def structured(self, intent: Intent, timeout_ms: int) -> list[Candidate]: ...


class Schedule(Protocol):
    def validate(
        self, candidates: list[Candidate], intent: Intent, timeout_ms: int
    ) -> list[Candidate]: ...


def remaining_ms(deadline: float) -> int:
    return max(0, int((deadline - monotonic()) * 1000))


def retrieve_appointments(
    intent: Intent,
    retrieval: Retrieval,
    schedule: Schedule,
    request_budget_ms: int = 900,
) -> tuple[str, list[Candidate]]:
    deadline = monotonic() + request_budget_ms / 1000

    if not intent.specialty or not intent.location:
        return "clarify", []

    stages = (
        ("semantic", retrieval.semantic, 250),
        ("lexical", retrieval.lexical, 180),
        ("structured", retrieval.structured, 120),
    )

    for path, search, stage_cap_ms in stages:
        budget_ms = min(stage_cap_ms, remaining_ms(deadline))
        if budget_ms <= 0:
            break

        candidates = search(intent, timeout_ms=budget_ms)
        if not candidates:
            continue

        valid = schedule.validate(
            candidates,
            intent,
            timeout_ms=remaining_ms(deadline),
        )
        if valid:
            return path, valid

    return "clarify", []

In production, the adapters should classify expected outcomes rather than erase them into an empty list: deadline exceeded, no candidates, candidates rejected by hard filters, and availability changed are operationally different. The response layer still maps those internal states to a calm clarification or an empty-result message, while telemetry records the stage and reason. Avoid logging raw health descriptions by default. A query fingerprint, coarse intent fields, policy version, candidate IDs, and outcome are often enough to diagnose the retrieval path; retention and access rules remain part of the system design, not an afterthought.

The code also validates after every stage. That repeated call can look wasteful, but batching candidates and using the remaining deadline keeps the boundary honest: search proposes; the scheduling record disposes. If availability validation cannot complete in time, the assistant should not display an unverified slot as though it were current.

Rejected default and where it still belongs

The rejected option is "semantic search, then generate an answer, with keyword search only on exceptions." It is attractive because the happy path is short. The catch is that exceptions describe software behavior, while the dangerous cases here are often valid but unsuitable results: a stale candidate, a semantically close specialty, or a provider who no longer has matching availability. None must raise an exception to be wrong for the booking task.

A semantic-only path is suitable for low-stakes discovery, such as browsing educational descriptions where freshness is labeled and no appointment is offered. Stick with structured retrieval first when the user supplies exact fields, when an audit must reproduce ordering, or when hard constraints dominate free-text intent. Use human handoff when organizational policy, clinical ambiguity, or accessibility needs make automated scheduling unsuitable. These aren't inferior fallbacks. They are separate operating modes with clearer failure boundaries.

Deployment should follow the same skepticism. Shadow the new semantic stage without changing user-visible ordering, replay a fixed evaluation set on every embedding or corpus change, and canary the fallback policy separately from the model. Alert on shifts in fallback mix and validation rejection rate, not just request errors. A fast system that quietly routes more users to clarification has regressed, even if its latency chart improved.

The final decision rule remains narrow: spend latency on semantic retrieval only while it adds validated candidates, preserve hard constraints through every transition, and ask rather than guess when the remaining evidence cannot support a booking result.

References

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks: https://arxiv.org/abs/2005.11401