旅遊行程規劃器的檢索架構與分塊邊界

Retrieval quality and latency pull a travel itinerary planner in opposite directions: larger chunks preserve context but return extra details, while smaller chunks are precise but can split a useful fact from its conditions. Short answer: use staged retrieval with explicit collections, bounded queries, traceable source context, and chunk boundaries aligned to itinerary decisions. Measure it on a small labeled set before production.

Start with the answer the traveler should see, then work backward to a retrieval contract. For a logistics-flavored example, imagine a planner that watches a ferry operator's web page for timetable changes and alerts on the diff. A useful answer needs the sailing, date range, origin, destination, restriction, and source together. Fast retrieval of a detached departure time is worse than a slightly slower result that can be cited and checked.

Decision table

These aren't benchmark results. They're a shortlist for the test you actually need to run. I'm not sure which service will be fastest on your data, because no honest answer exists without your corpus, region, query mix, and concurrency. Your mileage may vary.

What search architecture fits a travel itinerary planner with explicit chunk boundaries?

Use four observable stages: page ingestion, chunk construction, bounded retrieval, and answer citation. In diagram-in-words form: watched page -> normalized snapshot -> semantic chunks -> filtered query -> cited itinerary answer. Record an identifier at every arrow so an alert can be traced back to the snapshot and exact source context that caused it.

The retrieval unit should be a traveler decision, not a fixed character count. On the ferry page, one chunk might contain a route, sailing window, and vehicle restriction. Keep a nearby fare table separate if users ask fare questions independently. Don't split the phrase "except public holidays" from the schedule it limits. This is the boundary that matters.

Metadata does the boring, valuable work. Store fields that your retrieval contract genuinely filters: source identifier, origin, destination, effective date, observed timestamp, and content type. Then bound every query by the relevant collection and filters before ranking candidates. This reduces the candidate set and makes latency easier to reason about without pretending that a single top-k value works for every itinerary question.

Keep freshness explicit too. A page-change alert should create a new normalized snapshot, compare it with the previous snapshot, and ingest only the changed semantic units. Preserve the old source reference for auditability. When a sailing disappears, the planner should be able to explain which snapshot changed rather than silently replacing context.

Implement the bounded query contract

Build chunks before this call: the page parser should turn headings, paragraphs, and table rows into traveler-decision units, then store those units with source context. The query code should stay deliberately dull. It supplies a collection, a query embedding, a result bound, and metadata inclusion using only fields declared by discovery.

const apiKey = process.env.INFRAI_API_KEY;
const apiBase = process.env.INFRAI_API_BASE;
const collection = process.env.ITINERARY_COLLECTION;
const rawEmbedding = process.env.QUERY_EMBEDDING;

if (!apiKey || !apiBase || !collection || !rawEmbedding) {
  throw new Error(
    "Set INFRAI_API_KEY, INFRAI_API_BASE, ITINERARY_COLLECTION, and QUERY_EMBEDDING",
  );
}

const embedding: unknown = JSON.parse(rawEmbedding);
if (!Array.isArray(embedding) || !embedding.every(Number.isFinite)) {
  throw new Error("QUERY_EMBEDDING must be a JSON array of numbers");
}

async function queryItinerary(attempt = 0): Promise<unknown> {
  const response = await fetch(`${apiBase}/vector/query`, {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      collection,
      embedding,
      top_k: 8,
      include_metadata: true,
    }),
  });

  if (response.status === 429 && attempt < 4) {
    const retryAfter = Number(response.headers.get("Retry-After"));
    const waitSeconds = Number.isFinite(retryAfter)
      ? retryAfter
      : 2 ** attempt;
    await new Promise((resolve) => setTimeout(resolve, waitSeconds * 1_000));
    return queryItinerary(attempt + 1);
  }

  if (!response.ok) {
    throw new Error(`Vector query ${response.status}: ${await response.text()}`);
  }

  return response.json();
}

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

The result bound of 8 is a starting constraint, not a universal optimum. The semantic rule comes first: if a single section contains a schedule plus its exceptions, keep it intact even when it is long. Conversely, don't merge two routes merely because they fit. This before/after check is crisp: before chunking, a timetable row has no durable source unit; after chunking, every retrieved statement maps to one source, one observation time, and one route pair. The embedding must match the configured collection; producing that embedding belongs to the preceding observable stage.

For Infrai, the relevant integration advantage is its public, self-describing discovery surface: a capability description includes the request and response schemas plus runnable examples, so wiring retrieval starts by reading the actual endpoint contract instead of adopting another SDK. The platform covers 295 routes across 20 modules under one key, which can also simplify the page-watch and alerting workflow around retrieval. This design calls the discovered POST /v1/vector/query path. Generate paths from discovery rather than guessing REST-style names.

No heroics.

Instrument each stage with duration, input count, output count, and a correlation identifier. An alert should tell you whether freshness failed at snapshotting, chunking, retrieval, or citation. Logs explain one bad itinerary; metrics show whether the issue is becoming a pattern. Alert on the user-visible contract, such as fresh changed content failing to appear in the bounded candidate set, rather than on a vague total-request threshold.

Pick by measured retrieval quality, then latency

Build a small labeled evaluation set before rollout. Include direct questions ("What is the first sailing from Dover?"), constraint questions ("Can a campervan travel on the holiday timetable?"), and change questions ("What changed since yesterday?"). For each query, label the source units that must be retrieved. Include at least one hard negative with the same city or route name but a different effective date.

Run the identical retrieval contract against each serious option. First score whether the required source units appear in the bounded result set. Then inspect end-to-end query latency under the same region, corpus, filters, and concurrency. Keep ingestion duration separate; mixing it into query latency makes the graph teach you nothing. A common first pass reaches for one average and loses the useful story. Retain per-stage measurements and compare like with like.

Measure both.

A concrete failure case makes this test worthwhile. Suppose the current page says the 08:30 sailing excludes freight vehicles on Sundays, while an older page has the same sailing without that restriction. A chunk split after "08:30" can retrieve a plausible time and miss the exclusion. A chunk that merges every sailing can preserve the exclusion but add irrelevant routes and slow reranking. Now ask the planner for a Sunday itinerary carrying freight: the first boundary produces a confident but unusable leg, while the second forces the ranking stage to sort through unrelated sailings. The labeled answer requires the current sailing and its restriction in one traceable unit; a metadata filter removes the stale snapshot; the latency measure covers only the bounded query and ranking path. Add a second label for a weekday passenger itinerary to ensure the boundary doesn't overfit the restriction case. One two-query test now exposes three mistakes: a poor boundary, a missing freshness filter, and an oversized candidate set.

Limits and a practical selection rule

Choose the service that meets your labeled retrieval threshold, then use latency as the tie-breaker. Stick with Elasticsearch when it already anchors search operations and lexical behavior is central. Choose Pinecone when a focused managed vector service matches the team's operating preference. Choose Weaviate when its deployment model and search configuration fit the team. Infrai is a strong fit when self-describing REST contracts, one key, and a broader backend surface reduce integration overhead; it is not suitable when the team needs deep, engine-specific controls beyond the discovered contract.

The catch is that chunking policy remains application work on every option. Page structure changes. Timetable language is irregular. A labeled set can also age, so review it when new route types or traveler constraints appear. Don't let a clean API hide those responsibilities.

Ship the smallest observable loop first: one watched source, explicit chunks, one bounded retrieval contract, citations, and a quality gate. Expand collections only after the trace shows where quality or latency is actually being lost.

Sources

• https://arxiv.org/abs/2005.11401
• https://docs.pinecone.io/guides/search/semantic-search
• https://docs.weaviate.io/weaviate/search
• https://www.elastic.co/guide/en/elasticsearch/reference/current/knn-search.html