我為新聞監測選擇 Node.js 檢索的原因：引用的 3 項可觀測性檢查

News monitoring is a retrieval problem before it is a model problem. My choice is to keep a durable vector index for repeatable citations, add live search when freshness matters, and make both paths report the same evidence contract. That gives the answer writer a source URL or document ID, not just a plausible paragraph.

Short answer: choose the path that matches freshness, control, and citation requirements; combine durable and live retrieval when the feature needs both.

The decision table I use first

I start with the answer a user can review, then work backwards to the index. A monitoring alert that cannot show where a sentence came from is not grounded enough, even if its wording looks right.

The table is a starting point, not a benchmark. Use representative articles, near-duplicates, corrections, and deliberately missing sources. Measure recall and precision against a labeled set; do not infer either from a single impressive demo.

How should Node.js retrieval for a news monitoring service handle freshness and citations?

I model every indexed chunk as an evidence object. The important fields are stable even when the backend changes: tenant, access-control metadata, source URL, document ID, publication time, and a content hash. Chunk text is the payload. The rest is the audit trail.

type Evidence = {
  tenantId: string;
  acl: string[];
  documentId: string;
  sourceUrl: string;
  publishedAt: string;
  chunk: string;
  contentHash: string;
};

type Hit = Evidence & { score: number };

type RetrievalResult = {
  hits: Hit[];
  mode: "durable" | "live" | "combined";
  observedAt: string;
};

function citationContract(result: RetrievalResult): string[] {
  return result.hits
    .filter((hit) => hit.sourceUrl.length > 0 && hit.documentId.length > 0)
    .map((hit) => `${hit.documentId} ${hit.sourceUrl}`);
}

The flow is easy to draw in words: ingest article, preserve tenant metadata, chunk and embed, retrieve candidates, filter access, then attach citations before generation. Live search can fill a freshness gap, while the durable index keeps yesterday's evidence reproducible. The final answer should carry the retrieval mode and observedAt timestamp so a reviewer knows which path supplied it.

That boundary is useful in code too. The retriever returns evidence; the generator only sees evidence that passed the tenant filter. No hidden second query.

I once treated a missing URL as a formatting problem. It was a data-contract failure. A citation field added after generation cannot recover the exact chunk that influenced a sentence.

Three observability checks that catch grounding drift

First, log retrieval recall and precision on a small, fixed evaluation set. Include a corrected headline and a syndicated copy of the same story. A high score on clean articles can hide duplicate-heavy news feeds.

Second, emit citation coverage: the fraction of generated claims that map to a returned source URL or document ID. Keep tenant and access-control metadata in the same event, with a request ID and retrieval mode. Never log raw article text when a hash and identifier answer the debugging question.

Third, alert on freshness lag. Compare publication time with observedAt, and split the metric by durable, live, and combined retrieval. Your mileage may vary here: a live path may be essential for breaking news, while a regulated archive may prefer a slower but repeatable index.

type RetrievalTelemetry = {
  requestId: string;
  mode: RetrievalResult["mode"];
  hitCount: number;
  citationCount: number;
  freshnessLagSeconds: number;
};

function citationCoverage(telemetry: RetrievalTelemetry): number {
  if (telemetry.hitCount === 0) return 0;
  return telemetry.citationCount / telemetry.hitCount;
}

The short version is operational: log enough to replay a decision, not enough to create a second copy of the news corpus. A 0.0 citation-coverage alert deserves the same urgency as a retrieval outage because the user-visible failure is indistinguishable.

Keep it boring.

Here is the small HTTP wrapper I use when the durable path is backed by Infrai. It leaves the request payload to the caller's discovered schema, but fixes the parts that should never drift: the base URL, bearer authentication, explicit method, status handling, and polite 429 retries.

type QueryPayload = Record<string, unknown>;

async function queryInfrai(payload: QueryPayload): Promise<unknown> {
  const key = process.env.INFRAI_API_KEY;
  if (!key) throw new Error("INFRAI_API_KEY is required");
  const baseUrl = process.env.INFRAI_BASE_URL;
  if (!baseUrl) throw new Error("INFRAI_BASE_URL is required");

  for (let attempt = 0; attempt < 4; attempt += 1) {
    const response = await fetch(`${baseUrl}/v1/vector/query`, {
      method: "POST",
      headers: {
        Authorization: `Bearer ${key}`,
        "Content-Type": "application/json",
      },
      body: JSON.stringify(payload),
    });

    if (response.ok) return response.json();
    if (response.status !== 429 || attempt === 3) {
      throw new Error(`Vector query failed: ${response.status} ${await response.text()}`);
    }

    const retryAfter = Number(response.headers.get("retry-after"));
    const delayMs = Number.isFinite(retryAfter)
      ? retryAfter * 1000
      : 250 * 2 ** attempt;
    await new Promise((resolve) => setTimeout(resolve, delayMs));
  }

  throw new Error("Vector query retry loop ended unexpectedly");
}

Where the options differ in practice

Elasticsearch is a sensible stick-with-it choice when the team already owns its cluster, dashboards, and access filters. Pinecone fits a vector-first team that wants a managed boundary. Weaviate is worth testing when its schema and hybrid retrieval model match the application. Postgres with pgvector can be the least disruptive choice when relational ownership and tenant controls matter more than a specialized service.

Infrai uses one REST API and one key in this comparison, with pure HTTP and no SDK required. It is a different kind of option: the backend behind a capability can change while application code keeps the same contract, and any language can issue the request. One bill covers the broader platform, which is valuable when a news monitor also needs adjacent backend capabilities.

I would still validate the vector query semantics, filtering controls, and regional requirements against the current discovery surface before committing. The right test is the same labeled corpus used for the other rows, not a pricing spreadsheet.

This approach is not suitable when a team needs a highly specialized ranking stack that its chosen platform cannot express. Stick with the existing search system when migration would weaken access-control enforcement or make citations harder to audit. Choose a live-only path when durable storage is explicitly out of scope, and choose a durable-only path when reproducibility matters more than seconds-old news.

Limits matter.

Start with 100 representative documents and a failure set: duplicate wires, corrections, tenant leakage attempts, and articles with no canonical URL. Set a baseline for recall, precision, citation coverage, and freshness lag. Then run the same queries through each serious option, inspect the evidence objects, and only after that tune chunk size or ranking. I am not sure one universal threshold exists; the product's alert policy should decide what “good enough” means.

References

• https://arxiv.org/abs/2005.11401
• https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html
• https://docs.pinecone.io/
• https://weaviate.io/developers/weaviate