Node.js 如何為發票文字摘要 API 選擇模型，以及作者的選擇理由

Node.js Model Selection for Text Summarization APIs in Invoices (and Why I Chose One)

To select a model for text summarization API work in Node.js, start with the logistics invoice fields you must recover, not a leaderboard. The least complex option is a provider-neutral adapter around one typed extraction contract. Keep the provider call behind that adapter, validate the result, and store the original document beside the normalized fields. In 2026, I would choose the model path with the best performance on a small, representative invoice set, then keep a second compatible path ready for outages and policy changes.

The answer is a boundary, not a brand.

Short answer: what should the Node.js runtime optimize first?

Optimize for recoverable correctness, not an impressive demo. A supplier invoice is a poor place to accept a fluent paragraph as success. The useful output is a bounded object: invoice number, supplier, issue date, currency, subtotal, tax, total, and line items, each with a clear missing-value policy.

Decision criterion	What to measure	Practical default
Portability	How much business code changes when the provider changes	One internal TypeScript interface and provider adapters
Extraction quality	Field-level precision, recall, and invalid-value rate on held-out invoices	Reject or review uncertain fields
Operational fit	Timeout behavior, retries, quotas, logging, and data controls	Queue work and make jobs idempotent
Output discipline	Schema adherence and preservation of source evidence	Validate JSON before persistence

There is no universal “best model” for this job. The right choice is the one that passes your invoice corpus and operating constraints while leaving the rest of the system intact.

How do I select a model for text summarization APIs in Node.js?

Why does an invoice need a different contract than a summary?

A summary can be useful while being incomplete. An invoice extraction result cannot silently turn “tax included” into a numeric tax amount, or mistake a purchase-order number for the invoice number. Logistics teams also see scans, rotated pages, multiple currencies, freight surcharges, and vendors whose templates change without notice.

I would separate document understanding into two stages. First, extract the fields and line items with source references where the runtime supports them. Second, run deterministic checks in Node.js: totals, currency format, date parsing, required fields, and allowed tax behavior. A model may propose a value. It does not get to define whether that value is acceptable.

My first draft of this kind of system would have been a single summarize() function returning text. That looks fast. Later, the boundary becomes expensive: every downstream consumer must parse prose, provider-specific options leak into business logic, and a migration becomes a rewrite. The adapter is less exciting. It is also the part that protects revenue per engineering hour.

The interface should describe the work, not the vendor. Keep provider-specific request shapes inside an adapter and return a result that carries status, normalized data, and enough metadata to debug a rejected document without storing sensitive prompt content in ordinary logs.

export type InvoiceField<T> = {
  value: T | null;
  confidence?: number;
  sourcePage?: number;
};

export type Invoice = {
  invoiceNumber: InvoiceField<string>;
  supplierName: InvoiceField<string>;
  issueDate: InvoiceField<string>;
  currency: InvoiceField<string>;
  total: InvoiceField<number>;
  lineItems: Array<{
    description: string;
    quantity: number | null;
    unitPrice: number | null;
    amount: number | null;
  }>;
};

export type ExtractionResult = {
  status: "accepted" | "review" | "failed";
  invoice: Invoice | null;
  provider: string;
  requestId?: string;
};

export interface InvoiceExtractor {
  extract(input: {
    documentUrl: string;
    mimeType: "application/pdf" | "image/jpeg" | "image/png";
  }): Promise<ExtractionResult>;
}

The interface is deliberately boring. That is a feature. The application can swap an adapter without changing queue code, review screens, or accounting exports. It can also test the business rules with fixtures and a fake extractor instead of making a network request for every test. The trade-off is extra adapter code and a little more configuration; that is a reasonable cost for a one-person SaaS that ships weekly and needs to outsource undifferentiated provider plumbing.

Do not put secrets or raw invoice text in the interface by accident. Pass a reference to controlled storage, fetch it inside the adapter, and define retention separately from model-request logging. The exact boundary depends on your data policy, but the principle is stable: minimize what crosses each boundary.

How I would test the choice before shipping weekly

Build a small evaluation set from real document shapes, with sensitive values handled according to your retention policy. Include clean digital PDFs, scans, totals with freight, missing tax fields, unusual currencies, and at least one multi-page invoice. Label the expected fields. Then compare each candidate on field-level results, not on a single “looks good” score. I first thought a clean PDF would tell me enough about extraction quality. It would not: layout changes and missing fields are where the decision earns its keep.

For every field, record four outcomes: correct, missing, incorrect, or malformed. An incorrect total deserves a much higher review weight than a missing optional line description. Keep the test runner outside the provider adapter so the same cases exercise every candidate.

The runtime needs failure tests too. Simulate timeouts, rate-limit responses, invalid JSON, partial output, duplicate queue delivery, and a provider response that passes JSON parsing but fails the invoice schema. Retry only failures that are safe to retry. Use an idempotency key derived from the document identity and extraction version; otherwise a duplicate delivery can create two accounting records.

Here is the shape of a validation gate. The real schema library is an implementation detail; the important behavior is to classify bad output instead of coercing it into a successful record.

async function runExtraction(
  extractor: InvoiceExtractor,
  input: { documentUrl: string; mimeType: "application/pdf" | "image/jpeg" | "image/png" }
): Promise<ExtractionResult> {
  const result = await extractor.extract(input);

  if (result.status === "failed" || result.invoice === null) {
    return result;
  }

  const totalsArePlausible = result.invoice.total.value !== null;
  const hasSupplier = result.invoice.supplierName.value !== null;

  if (!totalsArePlausible || !hasSupplier) {
    return { ...result, status: "review" };
  }

  return result;
}

The check above is intentionally incomplete. Production validation should cover your accounting rules. A short function is not a substitute for a domain schema.

What changes when the provider changes?

Three common API families illustrate why the adapter matters. OpenAI’s JavaScript/TypeScript SDK exposes its own request and response conventions. Anthropic’s Messages API has a different message model and tool-oriented shape. Google’s Gemini API uses another set of content and generation controls. These are real engineering differences, not reasons to rank one universally.

The portable layer should map those differences into the same internal result. Keep model identifiers, token limits, safety settings, structured-output options, and request headers in configuration owned by the adapter. Keep queue semantics, validation, review routing, and persistence outside it. The limitation is real: a shared contract cannot erase differences in document support, regional controls, latency, or output behavior. It only keeps those differences from spreading through the application.

The runner-up is better in some situations. If a provider has the document input or regional data controls your compliance review requires, its adapter may be the practical choice even when another candidate scores better on a narrow sample. If a provider cannot meet your required latency or context window, a higher extraction score does not rescue the workflow. A text-only model is also not suitable when the invoice must be interpreted from an image or scanned PDF. Record the reason in the decision log. Re-run the evaluation when invoice templates or requirements change.

I would also keep a plain-text fallback for a narrow failure mode: a human review queue with the original document and the fields that failed validation. A fallback that invents values is worse than a visible pause.

The decision rule for a one-person SaaS

Pick the smallest architecture that gives you an auditable result: object storage for the source, a queue for asynchronous work, one typed adapter, deterministic validation, and a review state. Instrument latency, retry count, schema failures, accepted fields, and review rate. Do not log the whole invoice merely because logs are convenient.

Then use a two-part gate. First, reject candidates that fail data handling, availability, or integration requirements. Second, choose among the survivors using field-level accuracy and operational burden on your labeled set. This makes the model choice a reversible engineering decision instead of a permanent brand commitment.

That is the choice I would defend in a small SaaS: keep the provider replaceable, keep accounting rules local, and spend human review only where the evidence is weak.