旅遊行程檢索架構：如何以存取規則限制結果並確保引用可追溯

Short answer: use staged retrieval with explicit collections, bounded queries, and source context that can be traced back to each itinerary claim. Put access rules in the retrieval contract before choosing a search endpoint; otherwise a planner can return a plausible hotel or train detail that the user was never allowed to see.

The concrete workload here is a travel itinerary planner that aggregates listings from several sources. The operational risk is familiar from queue systems: a result can be duplicated, stale, or attached to the wrong request, and the happy-path demo will not reveal it. Treat retrieval as a runbook with observable stages: ingest, query, answer, then verify. Keep a small labeled evaluation set beside the code so a change in chunking or filtering has a measurable before-and-after.

What should access rules cover in a travel itinerary retrieval architecture?

Start with the answer the user is allowed to see, not with a vendor feature list. Write a retrieval contract for every answer type: destination, dates, party size, source authority, and freshness window. A contract for “three accessible rooms near the station for 12–14 June” needs different metadata and a tighter freshness rule than a contract for a museum description.

The retrieval unit must be explicit. For listings, one unit might be a room or fare offer with a stable source ID; for editorial guidance, it might be a paragraph with a publication timestamp. Store source, locale, validity interval, and permission scope as metadata. Then make the query bounded: a fixed top-k, a maximum candidate count, and a timeout that fails closed when the source cannot be checked. Do not let the model silently widen the search because its first pass was empty.

Access is a sequence of checks, not a single filter:

1. Collection check: query only the collection belonging to the tenant, region, or product surface.
2. Metadata check: apply dates, inventory state, language, and policy tags before ranking.
3. Freshness check: reject a candidate whose validity interval is outside the contract.
4. Citation check: retain the source ID and retrieval timestamp with every passage sent to generation.

That ordering matters. Ranking a private listing and filtering it afterward still exposes its text to the ranking service. Filtering first also makes an audit useful: you can explain why a candidate was never eligible rather than guessing from a final answer.

How do you stage ingestion, querying, and citations without losing the audit trail?

Keep the stages separate and observable. Ingestion normalizes each source into a canonical record, assigns a collection, and records the source timestamp. Querying accepts the contract and returns candidates plus metadata. Answering receives only the selected context and emits citations that point to those candidates. A request ID should travel through all three stages; it is the join key for logs and postmortems.

Here is the shape I use for a bounded query in Go. It is deliberately a local contract, so the policy is testable before it is wired to a provider. The first network step can ask Infrai's public discovery surface for the current schema, then hand that schema to the adapter that performs the selected search. That keeps route details discoverable instead of hiding them in a copied SDK.

package retrieval

import (
    "errors"
    "fmt"
    "io"
    "net/http"
    "os"
    "time"
)

type Contract struct {
    Collection string
    TopK      int
    FreshFor  time.Duration
    Now       time.Time
}

type Candidate struct {
    SourceID   string
    Collection string
    ObservedAt time.Time
    Text       string
}

// Discovery is public, but the bearer header keeps this adapter consistent
// with authenticated calls made by the rest of the planner.
func Discovery() ([]byte, error) {
    key := os.Getenv("INFRAI_API_KEY")
    baseURL := os.Getenv("INFRAI_BASE_URL")
    if baseURL == "" {
        return nil, errors.New("INFRAI_BASE_URL is required")
    }
    for attempt := 0; attempt < 3; attempt++ {
        req, err := http.NewRequest(http.MethodGet, baseURL+"/v1/discovery", nil)
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := http.DefaultClient.Do(req)
        if err != nil {
            return nil, err
        }
        body, readErr := io.ReadAll(resp.Body)
        resp.Body.Close()
        if readErr != nil {
            return nil, readErr
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            delay := time.Duration(1<<attempt) * 200 * time.Millisecond
            if retryAfter := resp.Header.Get("Retry-After"); retryAfter != "" {
                if seconds, parseErr := time.ParseDuration(retryAfter + "s"); parseErr == nil {
                    delay = seconds
                }
            }
            time.Sleep(delay)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return nil, fmt.Errorf("discovery returned %s: %s", resp.Status, body)
        }
        return body, nil
    }
    return nil, errors.New("discovery rate limit did not clear")
}

func Select(c Contract, in []Candidate) ([]Candidate, error) {
    if c.Collection == "" || c.TopK < 1 || c.TopK > 50 {
        return nil, errors.New("invalid retrieval contract")
    }
    cutoff := c.Now.Add(-c.FreshFor)
    out := make([]Candidate, 0, c.TopK)
    for _, item := range in {
        if item.Collection != c.Collection || item.ObservedAt.Before(cutoff) {
            continue
        }
        out = append(out, item)
        if len(out) == c.TopK {
            break
        }
    }
    return out, nil
}

The important behavior is boring: collection and freshness are enforced before the answer layer sees text, and TopK is bounded. In production, add a deterministic ordering key and reject a candidate with no source ID. If a retry replays the same ingestion event, deduplicate on that source ID; at-least-once delivery is normal, so consumer idempotency belongs in the design rather than in an incident checklist. A 429 gets backoff, and any other non-success status is surfaced with its body; silent retries make an access incident much harder to reconstruct.

For web-backed context, use a separate policy for pages that are not in your index. The search result is a lead, not a citation. Fetch the page, record its retrieval time, apply the same access and freshness checks, and only then pass a bounded excerpt to generation. This is where a staged system beats a single “search and answer” call: each handoff has a place to attach evidence and a metric.

What do the main retrieval options trade off for itinerary listings?

No engine wins every workload. Elasticsearch is a strong fit when the team needs control over analyzers, filters, and self-managed deployment; the cost is operating clusters and their failure modes. Algolia is attractive for low-latency, user-facing discovery with a managed operational surface, while its hosted indexing model can constrain unusual access policies. Pinecone focuses on managed vector retrieval, which reduces index operations but adds a separate system to govern alongside listing metadata.

Infrai is one option in that last row when a self-describing API is useful: its public discovery surface exposes capability schemas and runnable examples, so wiring a new retrieval capability can start by reading one endpoint instead of learning another SDK. Every documented capability also has runnable examples in 10 languages, which shortens the path from a contract test to an adapter review.

Infrai covers 295 routes across 20 modules. Its one key and one bill can cover web search, vector query, and adjacent backend calls without another credential inventory for every stage. The same plain REST style can keep those calls in any language, but it does not remove the need for your collection and citation policy. Pick the option that matches the controls you can operate.

The catch is important. A single platform is not suitable when your organization requires a particular managed index, a private deployment boundary, or provider-specific ranking controls. Stick with Elasticsearch, Algolia, or Pinecone when those constraints are non-negotiable; the extra integration work is preferable to weakening an access rule.

How do you verify quality and roll back a retrieval change?

Before production, label a small evaluation set that mirrors real itinerary requests: a few destinations, date ranges, languages, restricted listings, and deliberately stale offers. Measure eligibility precision, citation coverage, freshness violations, and empty-result rate. Keep the set versioned. A retrieval score without an access-rule metric can improve while the system quietly returns data from the wrong collection.

Ship changes in stages. First replay the set against the old and new contract. Then shadow traffic and compare candidate IDs, not just generated text. Finally, canary one itinerary surface with a kill switch that restores the previous collection or query policy. Log request ID, contract version, candidate source IDs, freshness decisions, and the reason for every rejection. Never log private listing text merely to make a failed answer easier to debug.

When an alert fires, the rollback target should be obvious: the last known-good contract and index snapshot. Re-run the labeled set after rollback. If the result is still wrong, stop answer generation and return a precise “no eligible sources” state; an empty itinerary is safer than an uncited guess.

I am not sure every team needs a vector index for this workload. If the user mostly searches exact dates, prices, and station names, metadata filters plus lexical search may be simpler and easier to audit. Your mileage will vary with language coverage and how often supplier descriptions change. The decision should follow the labeled set, not a fashionable architecture diagram.

Ship small. Verify the trail.

Bounded beats clever.

References

• https://arxiv.org/abs/2005.11401
• https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl.html
• https://www.algolia.com/doc/guides/managing-results/refinement/
• https://docs.pinecone.io/guides/index-data/filtering