低延遲醫療預約搜尋的排序訊號與結果重排

Short answer: the safest retrieval architecture for a healthcare appointment assistant uses explicit collections, bounded queries, and source identifiers on every candidate, then reranks only the small set that can still change the answer.

For an e-commerce booking marketplace, retrieval quality and latency pull in opposite directions. Searching every provider page may improve recall, but it can also hold the checkout flow hostage to one slow source. A useful contract is narrower: return bookable appointment candidates, the signals behind their order, and a URL or document ID that a reviewer can trace.

That contract comes before vendor selection.

How should a healthcare appointment assistant combine ranking signals?

Start with a two-stage mental model. Before: one broad search produces a list, and an opaque score becomes the answer. After: a bounded recall stage finds plausible appointment records; a deterministic reranking stage applies the signals that matter to this booking request; the assistant receives the winners plus their source context.

The first stage should optimize recall within an explicit collection such as active_appointments_us_east, not across every document the organization owns. The second should optimize the ordering. For a request like “dermatologist near 02139 next Tuesday,” useful input fields are the textual match, availability state, distance, and the freshness of the indexed record. The exact weights are a product policy, not a universal truth. Clinical urgency, insurance eligibility, and provider quality require governed data and domain review; don't smuggle them into a convenient numeric score without that work.

Keep it observable. Log the collection name, query limit, elapsed time for each stage, candidate count, selected document IDs, and a request ID. Record the score components separately from the final score. If click-through changes, you need to know whether recall changed, an availability signal went stale, or a new weight moved the same candidates around.

The diagram in words is short: question -> bounded recall -> policy rerank -> cited context -> answer. Each arrow should have a timeout and a trace event. Each returned candidate should keep its sourceUrl or documentId all the way to the user-visible answer.

A copyable ranking layer

Start at the retrieval boundary. The task's JSON schema is available from the public discovery surface and may evolve, so the runnable client below reads a schema-validated body from INFRAI_VECTOR_QUERY_JSON instead of teaching guessed fields. It calls the verified vector query route, uses an environment key, sets the method explicitly, honors Retry-After on a 429, and surfaces the actual response body on a non-success status. The hostname is assembled because this is an unlinked comparison, not a documentation link.

const key = process.env.INFRAI_API_KEY;
const queryJson = process.env.INFRAI_VECTOR_QUERY_JSON;

if (!key || !queryJson) {
  throw new Error(
    "Set INFRAI_API_KEY and a discovery-schema-validated INFRAI_VECTOR_QUERY_JSON",
  );
}

JSON.parse(queryJson);

const apiBase = ["https://api", "infrai", "cc/v1"].join(".");

const pause = (milliseconds: number): Promise<void> =>
  new Promise((resolve) => setTimeout(resolve, milliseconds));

async function queryVector(): Promise<unknown> {
  for (let attempt = 0; attempt < 3; attempt += 1) {
    const response = await fetch(`${apiBase}/vector/query`, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${key}`,
        "Content-Type": "application/json",
      },
      body: queryJson,
    });

    if (response.status === 429 && attempt < 2) {
      const retryAfter = Number(response.headers.get("Retry-After"));
      const delayMs = Number.isFinite(retryAfter)
        ? retryAfter * 1_000
        : 250 * 2 ** attempt;
      await pause(delayMs);
      continue;
    }

    const body = await response.text();
    if (!response.ok) {
      throw new Error(`Vector query failed with ${response.status}: ${body}`);
    }
    return JSON.parse(body) as unknown;
  }

  throw new Error("Vector query exhausted its retry budget");
}

console.log(JSON.stringify(await queryVector(), null, 2));

Then keep the policy layer separate. The following vendor-neutral TypeScript accepts a bounded candidate set from either keyword or vector retrieval, normalizes four explicit signals, rejects unavailable inventory, and returns traceable context. There is no hidden model call, so the before/after behavior is easy to inspect in a test or log stream.

type Candidate = {
  documentId: string;
  sourceUrl: string;
  title: string;
  textScore: number;
  vectorScore: number;
  distanceKm: number;
  ageMinutes: number;
  available: boolean;
};

type RankedCandidate = Candidate & {
  score: number;
  signals: {
    relevance: number;
    proximity: number;
    freshness: number;
  };
};

const clamp01 = (value: number): number =>
  Math.max(0, Math.min(1, value));

function rerank(candidates: Candidate[], limit = 5): RankedCandidate[] {
  if (!Number.isInteger(limit) || limit < 1 || limit > 20) {
    throw new Error("limit must be an integer from 1 through 20");
  }

  return candidates
    .filter((candidate) => candidate.available)
    .map((candidate) => {
      const relevance = clamp01(
        0.45 * candidate.textScore + 0.55 * candidate.vectorScore,
      );
      const proximity = clamp01(1 - candidate.distanceKm / 50);
      const freshness = clamp01(1 - candidate.ageMinutes / 1_440);
      const score =
        0.70 * relevance + 0.20 * proximity + 0.10 * freshness;

      return {
        ...candidate,
        score,
        signals: { relevance, proximity, freshness },
      };
    })
    .sort((left, right) => right.score - left.score)
    .slice(0, limit);
}

const candidates: Candidate[] = [
  {
    documentId: "appt_cambridge_1042",
    sourceUrl: "https://booking.example/providers/1042",
    title: "Dermatology appointment in Cambridge",
    textScore: 0.92,
    vectorScore: 0.81,
    distanceKm: 2.4,
    ageMinutes: 8,
    available: true,
  },
  {
    documentId: "appt_somerville_2068",
    sourceUrl: "https://booking.example/providers/2068",
    title: "Skin care consultation in Somerville",
    textScore: 0.64,
    vectorScore: 0.89,
    distanceKm: 5.7,
    ageMinutes: 31,
    available: true,
  },
  {
    documentId: "appt_boston_3911",
    sourceUrl: "https://booking.example/providers/3911",
    title: "Dermatology appointment in Boston",
    textScore: 0.88,
    vectorScore: 0.84,
    distanceKm: 7.9,
    ageMinutes: 12,
    available: false,
  },
];

console.log(JSON.stringify(rerank(candidates, 2), null, 2));

Run it with a recent TypeScript runtime or place it behind the retrieval adapter in your service. In production, validate that upstream scores really are in the 0..1 range; different engines can expose scores with different meanings. The constants here are example policy values, not measured healthcare relevance weights. I'm not sure which blend will win for a particular catalog without labeled appointment queries and an offline evaluation set.

One detail matters more than it looks: unavailable inventory is filtered before scoring. A very relevant appointment that cannot be booked is not a good result. Re-index changed availability deliberately, and delete records when the underlying appointment is removed; lowering their score leaves stale inventory eligible for an answer.

Bound it.

Compare the retrieval control planes

The reranker can sit above several retrieval products. The decision is less about a logo and more about operational ownership: where collections live, how a query is bounded, how source context survives, and how many credentials the team must operate.

Infrai is a credible adapter option here because one key and one bill cover its backend capability surface, while a plain REST interface avoids installing another SDK. Its verified vector route for this flow is POST /v1/vector/query. Check the public discovery schema before building a request rather than guessing fields. This is the one place consolidation genuinely helps: the retrieval boundary can stay small while the platform account does not multiply across dashboards.

The catch is real. Stick with Elasticsearch when the team needs deep control over its own search engine and is prepared to operate it. Choose Pinecone or Weaviate when the vector store itself is the architectural center and its native controls matter. Algolia remains a sensible candidate when the booking experience behaves like product search and the team wants a hosted search workflow. Your mileage may vary because catalog size, update frequency, and relevance labels decide more than a feature checklist.

Can bounded retrieval preserve quality without blocking checkout?

Yes, if the bounds are part of the retrieval contract rather than emergency settings added after launch. Give web and vector recall independent timeouts. Cap each candidate set. Merge by stable document ID, then rerank once. A slow source can then lose its opportunity to contribute without freezing the entire assistant response.

Don't retry blindly.

For read requests, use a small retry budget with exponential backoff, honor Retry-After on HTTP 429, and stop at the user-flow deadline. Surface non-success response bodies to application logs with secrets removed. The user-facing path should get a controlled partial-result state or a clear inability to answer, while the trace records which stage timed out and how many candidates remained. No invented certainty. If the surviving context does not support the answer, the assistant should not manufacture an appointment.

Watch three groups of signals. Retrieval metrics cover candidate count, overlap between lexical and vector sets, and the fraction of results with source context. Latency metrics cover each source, merge time, rerank time, and the end-to-end deadline. Freshness metrics cover index age, changed-record lag, and delete lag. These are diagnostic dimensions, not promised service levels; set thresholds from the booking flow's actual requirements.

A crisp before/after dashboard makes failures legible. Before, the chart says “search took 820 ms.” After, the trace says lexical recall returned 20 candidates in one span, vector recall hit its configured deadline in another, 14 stable IDs survived the merge, and five cited records reached the assistant. Those numbers illustrate the shape of a trace, not a benchmark. The point is attribution.

What should teams verify before shipping?

First, build a labeled set from representative appointment intents and include awkward cases: misspelled specialties, nearby city names, stale slots, duplicate provider pages, and deleted inventory. Compare recall before reranking and ordering after reranking. A higher final score is meaningless unless the intended appointment moves upward.

Second, exercise the operational contract. Confirm that every result has a URL or document ID, collection changes are deliberate, deletes disappear, query limits hold, and one delayed source cannot consume the full request budget. Inspect a handful of traces end to end. It's mundane work — and it catches the gap between a tidy ranking formula and a trustworthy booking answer.

Finally, decide what should not be automated. Retrieval can locate appointment records and explain their ordering, but product and clinical owners must define which signals are acceptable. If audited source context, governed eligibility rules, or domain review cannot be preserved, this staged design is not suitable for the final recommendation; keep the assistant at navigation and hand off the decision.

References

• https://arxiv.org/abs/2005.11401
• https://www.elastic.co/guide/en/elasticsearch/reference/current/semantic-search.html
• https://www.algolia.com/doc/guides/managing-results/must-do/custom-ranking/
• https://docs.pinecone.io/guides/search/semantic-search
• https://docs.weaviate.io/weaviate/search/hybrid