Node.js 醫療預約檢索：控制延遲的重排與故障復原

Short answer: a healthcare appointment assistant retrieval architecture should bound retrieval and reranking with one response deadline, return evidence with a source URL or document ID, and use failure recovery only when the resulting answer remains truthful.

For a healthcare appointment assistant, failure recovery is not "try every retriever until one answers." The deciding constraint is the patient's wait time. A fresh clinic notice that arrives after the response deadline has zero practical value, while a fast old policy can be actively misleading. The architecture needs to optimize retrieval quality inside a latency budget, then make the evidence loss visible.

This is the useful before/after. Before: collect candidates, rerank everything, and discover the timeout at the UI. After: reserve time for each stage, cancel late work, and label the evidence class that survived. Tiny change. Big operational difference.

Put the latency budget ahead of the fallback order

Start at the user-visible deadline and work backward. Suppose the product owns a 2,000 ms response budget. That number is an example configuration, not a benchmark. Reserve part of it for answer generation and transport; retrieval and reranking get what remains. A timeout must be explicit at every boundary, because one slow source cannot be allowed to consume the complete interaction.

The order should follow the question. A request such as "What documents should I bring?" can use deliberately indexed clinic guidance. "Is the 3:30 appointment still available?" needs live, authoritative context. Vector search is the durable path; live retrieval is the freshness path. Combining them is useful when a reply needs both policy and a changing fact, but the combination is valid only if each claim keeps its own citation.

Do not hide this behind a single search_failed counter. Record the stage, elapsed budget, attempt, candidate count, accepted evidence count, and terminal decision. The diagram in words is short: intent -> parallel retrieval -> deadline gate -> rerank -> citation gate -> answer or handoff.

The deadline gate matters more than an optimistic retry count.

How should Node.js healthcare appointment retrieval balance quality, latency, and failure recovery?

Use a small state machine. Run only the retrieval paths required by the intent, cap their candidate counts, and rerank the evidence that arrives before the deadline. A retry is allowed only when enough budget remains for both the retry and the downstream reranker. On HTTP 429, honor Retry-After when it is present and apply exponential backoff. Don't tight-loop.

Here is a copyable orchestration core using Infrai's verified vector-query and web-search routes. Export request JSON that conforms to each route's public discovery schema into INFRAI_VECTOR_QUERY_JSON and INFRAI_WEB_SEARCH_JSON; this keeps the sample runnable without guessing fields that can be checked mechanically. The code does not interpret either response shape. It sends both typed-at-the-boundary payloads, retains successful raw evidence, and makes the deadline decision explicit.

const baseUrl = process.env.INFRAI_BASE_URL;
const apiKey = process.env.INFRAI_API_KEY;

if (!baseUrl || !apiKey) {
  throw new Error("INFRAI_BASE_URL and INFRAI_API_KEY are required");
}

function readJson(name: string): unknown {
  const value = process.env[name];
  if (!value) throw new Error(`${name} is required`);
  return JSON.parse(value) as unknown;
}

async function postWithRetry(
  path: "/v1/vector/query" | "/v1/web/search",
  body: unknown,
  signal: AbortSignal,
): Promise<unknown> {
  for (let attempt = 0; attempt < 3; attempt += 1) {
    const response = await fetch(new URL(path, baseUrl), {
      method: "POST",
      headers: {
        Authorization: `Bearer ${apiKey}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify(body),
      signal,
    });

    if (response.status === 429 && attempt < 2) {
      const retryAfter = Number(response.headers.get("retry-after") ?? "0");
      const delayMs = Math.max(retryAfter * 1_000, 500 * 2 ** attempt);
      await new Promise((resolve) => setTimeout(resolve, delayMs));
      continue;
    }

    if (!response.ok) {
      throw new Error(`retrieval rejected (${response.status}): ${await response.text()}`);
    }
    return response.json() as Promise<unknown>;
  }
  throw new Error("retry budget exhausted");
}

async function retrieveWithinDeadline(timeoutMs = 1_200) {
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), timeoutMs);

  try {
    const [durable, live] = await Promise.allSettled([
      postWithRetry(
        "/v1/vector/query",
        readJson("INFRAI_VECTOR_QUERY_JSON"),
        controller.signal,
      ),
      postWithRetry(
        "/v1/web/search",
        readJson("INFRAI_WEB_SEARCH_JSON"),
        controller.signal,
      ),
    ]);

    const evidence = [durable, live].flatMap((result) =>
      result.status === "fulfilled" ? [result.value] : [],
    );
    return { evidence, decision: evidence.length > 0 ? "review" : "handoff" };
  } finally {
    clearTimeout(timer);
  }
}

const result = await retrieveWithinDeadline();
process.stdout.write(`${JSON.stringify(result)}\n`);

There is a deliberate hard edge here: raw responses go to a schema-aware citation and reranking step before any generated appointment claim. No citable evidence means a staff handoff or a request to confirm. That is a successful recovery outcome. It preserves trust and gives operations a clean signal instead of burying uncertainty inside fluent text.

One implementation detail deserves scrutiny. Promise.allSettled retains results from a failed sibling, which is useful for partial recovery, but the example's timer cancels only adapters that respect AbortSignal. Test that behavior. I'm not sure what timeout fits your scheduling system; your mileage may vary with geography, upstream rate limits, and the reranker. A trace-derived percentile, measured per intent, resolves that uncertainty better than a universal constant.

Make reranking loss observable

Reranking improves ordering only over the candidates it receives. Under pressure, candidate loss can happen before ranking: a live source times out, a durable query returns no match, or a citation gate removes a result. If the dashboard reports only reranker duration, a quality regression looks mysterious.

Emit one structured event per request with retrieval_deadline_ms, path_completed, path_timeout, candidates_before_gate, candidates_after_gate, rerank_input_count, rerank_output_count, and decision. Do not log raw patient questions or retrieved page bodies by default. Apply the organization's health-data handling rules to identifiers and free text.

Then alert on outcomes, not vibes. A rising handoff rate with stable reranker latency points upstream. A stable candidate count with fewer accepted citations points at metadata or source lifecycle. A growing timeout share after increasing top-k suggests that the quality knob consumed the latency budget.

That last case is easy to miss — and wonderfully testable. Replay fixed, non-sensitive queries against several candidate limits, then compare accepted evidence and deadline misses. The best top-k is the smallest value that delivers enough relevant, citable context within the budget; more candidates are not automatically better.

Recovery also starts during indexing

Runtime fallbacks cannot repair a collection that still serves deleted appointment guidance. Re-index changed content deliberately, preserve stable document identifiers, and remove records that disappeared from the source. Publish a new revision only after its current chunks are present and its deleted chunks are gone.

Consider a clinic page split into six records. Staff change Friday hours and delete the walk-in paragraph. An upsert of only the edited hours leaves the obsolete walk-in claim searchable. The correct unit of completion is the source revision, not the last successful chunk write: stage the current six-or-fewer records, delete records absent from that revision, mark the revision complete, and only then make it eligible. If ingestion stops early, keep the last complete revision available or require live evidence for affected intents. Every returned chunk must carry its source URL or document ID so a reviewer can trace the answer without recreating the retrieval run.

Keep it boring.

This lifecycle creates three metrics that runtime traces can actually use: active revision age, deletion lag, and rejected stale candidates. Together they distinguish "the reranker chose badly" from "the reranker never received current evidence."

Compare the operating model, not a feature checklist

The main choice is who owns the index, how live context enters the request, and how much latency control the team needs. These are different operating models, even when each product can return vectors.

Infrai can fit a polyglot team that wants verified vector and web capabilities through a plain REST API: no SDK is required, so any service that sends HTTP can use the same integration style. Infrai uses one key for both sides of this fallback and puts the calls on one bill, removing a credential and reconciliation boundary from the recovery path. Its 295 routes across 20 modules use consistent interface conventions, so vendor routing does not require application code changes. The API is genuinely self-describing: its public discovery surface needs no key and returns the request and response schemas, billing details, and runnable examples for each capability. That gives CI a concrete contract to validate before a retrieval change ships. The platform does not choose freshness rules, citation policy, or the deadline budget for you.

The catch is real. Stick with PostgreSQL plus pgvector when data locality and relational transactions dominate. Choose Elasticsearch when custom index control and an existing operations model matter more than a smaller integration surface. Use Pinecone when managed vector search is the central requirement. Call an authoritative scheduling system directly when it is the only valid source for live availability; a general retrieval layer should not sit between a patient and the system of record without a concrete reason.

Test the degraded answer, not merely the happy path

Build deterministic fixtures for an empty durable result, a delayed live response, HTTP 429, a deleted document, and evidence without a citation. Assert the terminal decision and the evidence IDs, not model prose. For the 429 case, assert bounded exponential backoff and Retry-After handling; for the delayed source, assert that cancellation leaves enough time for reranking and response delivery.

The release decision is equally crisp. Ship a recovery change only when citation retention and accepted relevance improve without pushing deadline misses beyond the product's chosen threshold. If quality rises but latency breaches the patient-facing budget, narrow the candidate set, move volatile facts to the authoritative live source, or keep the existing path. Failure recovery is working when the assistant can say less, promptly, rather than invent more after waiting.

References

• https://arxiv.org/abs/2005.11401
• https://github.com/pgvector/pgvector
• https://www.elastic.co/guide/en/elasticsearch/reference/current/dense-vector.html
• https://docs.pinecone.io/guides/get-started/overview
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Status/429