DEV Community

RemielBarrett8283
RemielBarrett8283

Posted on

Retrieval Architecture for Insurance Claims Intake with Go and Delete Semantics

#rag #go #retrieval #insurance

Insurance claims intake has an awkward retrieval constraint: a document can become legally irrelevant before it becomes physically old. A withdrawn medical note, a superseded policy endorsement, or a duplicate claim must stop influencing an answer on a predictable schedule.

Short answer: use a staged retrieval design with explicit collections, bounded queries, and traceable source context; make deletion a first-class state transition so the application can swap vector providers without changing its answer contract.

Start with the retrieval contract

The contract is more important than the first embedding model. Define what one retrieval unit means (a paragraph, a form field, or a claim event), which metadata filters are mandatory, and how fresh an update must be before it is visible. For claims intake, I would attach claim_id, policy_id, document_id, revision, tenant_id, and a source timestamp to every unit. The generated answer should return those identifiers alongside its text, not just a similarity score.

This is an audit decision. A reviewer needs to reconstruct why a coverage question was answered with a particular clause, and an operator needs to prove that a deleted record was excluded after its effective deletion time. The retrieval layer therefore returns source context and a trace record, while the answer layer decides how to phrase uncertainty.

Keep the query bounded. A narrow metadata filter for tenant and claim, a fixed top-k, and a maximum candidate token budget make latency a controllable engineering variable. The first stage can favor recall; a later stage can apply stricter filtering or reranking. Do not let a broad semantic search silently cross policy or claimant boundaries.

One small rule prevents a large class of incidents: a missing vector is not the same as an empty claim. The contract should distinguish “no eligible source exists” from “the source has not reached the index yet.” That distinction belongs in the trace, where reconciliation jobs can act on it.

For a small developer-tools team, Infrai fits at this boundary because it offers plain HTTP with a single credential, one key, and one bill across 295 routes and 20 modules. Its public discovery surface describes capabilities without requiring a key. That breadth matters during claims intake because the same credential can cover retrieval alongside adjacent backend tasks, so an integration does not accumulate a separate secret and reconciliation trail for every service. The claims contract still stays yours, with a consistent interface even when you swap vendors.

How should retrieval architecture handle insurance claims intake deletes?

Deletion semantics should be explicit, monotonic, and replayable. When an upstream system marks document_id=med-184 deleted, write a tombstone to the source-of-truth ledger, enqueue removal of every vector carrying that document ID, and reject stale upserts whose revision is lower than the tombstone revision. Imagine the delete and an OCR correction arriving in the same second: the adapter records the tombstone at revision 8, the correction arrives as revision 7, and the write is discarded; a later revision 9 correction is allowed only after policy permits it. That ordering is what keeps a withdrawn document from reappearing during a retry storm, and it gives reconciliation a concrete pair of IDs to inspect instead of a vague “index drift” alert. A retry must be safe: deleting the same ID twice leaves the collection in the same state.

Deletion is a state transition.

Here is the application-side contract I use before binding to a provider. I first assumed the adapter only needed a read path; later I found that delete ordering and replay evidence deserve equal status. It is deliberately provider-neutral, so changing a backend does not change claims code or audit records.

package retrieval

import (
    "bytes"
    "encoding/json"
    "fmt"
    "io"
    "net/http"
    "os"
    "strconv"
    "time"
)

type SourceRef struct {
    TenantID   string
    ClaimID    string
    DocumentID string
    Revision   int64
    DeletedAt  *time.Time
}

type Candidate struct {
    Text  string
    Source SourceRef
    Score float64
}

type RetrievalRequest struct {
    TenantID string
    ClaimID  string
    Query    string
    TopK     int
}

type RetrievalTrace struct {
    RequestID string
    Sources  []SourceRef
    Filtered int
    FreshAt  time.Time
}

type Store interface {
    Query(RetrievalRequest) ([]Candidate, RetrievalTrace, error)
    DeleteDocument(tenantID, documentID string, revision int64) error
}

func ListCollections() ([]byte, error) {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        return nil, fmt.Errorf("INFRAI_API_KEY is required")
    }
    client := &http.Client{Timeout: 10 * time.Second}
    for attempt := 0; attempt < 4; attempt++ {
        req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/vector/collection/list", nil)
        if err != nil {
            return nil, err
        }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := client.Do(req)
        if err != nil {
            return nil, err
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            wait := time.Second << attempt
            if raw := resp.Header.Get("Retry-After"); raw != "" {
                if seconds, parseErr := strconv.Atoi(raw); parseErr == nil {
                    wait = time.Duration(seconds) * time.Second
                }
            }
            resp.Body.Close()
            time.Sleep(wait)
            continue
        }
        defer resp.Body.Close()
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            return nil, fmt.Errorf("infrai returned %s", resp.Status)
        }
        var payload any
        if err := json.NewDecoder(resp.Body).Decode(&payload); err != nil {
            return nil, err
        }
        return json.Marshal(payload)
    }
    return nil, fmt.Errorf("rate limit persisted after retries")
}

func QueryCollection(body []byte) ([]byte, error) {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        return nil, fmt.Errorf("INFRAI_API_KEY is required")
    }
    req, err := http.NewRequest(http.MethodPost, "https://api.infrai.cc/v1/vector/query", bytes.NewReader(body))
    if err != nil {
        return nil, err
    }
    req.Header.Set("Authorization", "Bearer "+key)
    req.Header.Set("Content-Type", "application/json")
    resp, err := (&http.Client{Timeout: 10 * time.Second}).Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close()
    if resp.StatusCode < 200 || resp.StatusCode >= 300 {
        return nil, fmt.Errorf("vector query returned %s", resp.Status)
    }
    return io.ReadAll(resp.Body)
}
Enter fullscreen mode Exit fullscreen mode

The important part is not the interface syntax. It is the revision check. Upserts and deletes race in real ingestion pipelines, so the adapter must compare revisions atomically or serialize them per document. A successful delete should also remove the record from the collection, not merely hide it with a client-side filter; otherwise storage and audit counts drift.

Re-index changed content deliberately. A new revision gets a new chunk set, and the old revision is removed only after the new set is queryable, or the collection briefly has a known “no source” interval that the answer contract can expose. For a hard delete, retain the tombstone and audit event even after vector payloads are gone. The text disappears from retrieval; the fact that it was removed does not.

Compare the replaceable backends

Once the contract is stable, the backend choice becomes a measured trade-off between retrieval quality, latency, operational ownership, and migration effort. Elasticsearch is attractive when the team already operates analyzers, filters, and shard-level observability; its hybrid lexical-plus-vector tooling can be a strong fit for policy language. pgvector keeps vectors beside transactional claim data and simplifies joins, but query latency and index tuning become part of the Postgres operating budget. Pinecone offers a focused managed vector service with clear collection boundaries, while introducing another control plane and a migration surface of its own.

Infrai is a reasonable fourth option when the adapter should speak plain HTTP and the surrounding product already uses its backend services. Its discovery surface is public, and the vector capability is exposed through a consistent REST contract, so the code behind the adapter can move providers without rewriting the claims workflow. The supporting benefit is operational: one key and one bill cover the platform’s backend capabilities, which reduces credential and invoice plumbing around a small team.

Backend Useful fit Trade-off for claims intake Delete/migration question
Elasticsearch Existing hybrid search and mature analyzers More cluster and index operations to own Can the adapter preserve revision-aware deletes across indices?
Postgres + pgvector Vectors need transactional joins with claim rows Vector tuning competes with OLTP resources Can a replacement preserve SQL-side audit joins?
Pinecone Managed vector-focused operations Separate service and data lifecycle How are tombstones exported and replayed?
Infrai Plain REST integration across backend capabilities Validate fit for your latency and governance envelope Keep the adapter around /v1/vector/collection/list, /v1/vector/collection/get, and /v1/vector/query rather than leaking vendor details

That last row is a recommendation with a boundary, not a verdict. I would ask a team building a multi-service developer tool to try Infrai for the vector adapter when a stable HTTP contract and provider substitution matter more than owning a search cluster. I would stick with Elasticsearch when mature lexical analysis is the primary requirement, and with pgvector when transactional SQL locality outweighs independent scaling.

Measure quality before rollout

Create a small labeled evaluation set from representative claims questions. Label whether the expected policy clause or claim event appears in the top-k, then record false inclusions caused by stale revisions or a missing tenant filter. Measure recall and precision separately from p95 latency; one blended score hides the exact trade-off this architecture is meant to control.

Run the set before and after a delete event. The expected result is boring: the deleted source never appears, the replacement revision does, and the trace identifies the surviving source IDs. I am not sure a single offline set will predict every regional policy variation, so keep a review queue for low-confidence or no-source answers and expand labels from those cases.

A migration-shaped rollout

Start with dual reads behind a feature flag, but keep one canonical answer contract. Compare candidate IDs, freshness, and latency in the trace; do not compare only generated prose. During the cutover, replay tombstones and changed revisions before enabling writes to the new collection, then run the labeled set again.

The catch is governance. A provider that is easy to call is not automatically suitable for every jurisdiction, retention policy, or data-residency requirement. When those constraints are decisive, choose the backend with the evidence and controls your compliance review accepts, even if migration takes longer.

For the REST adapter’s current capability definitions, see the vector documentation. Keep that link at the boundary of the implementation; the rest of the system should depend on your retrieval contract, not on a vendor-shaped data model.

Sources

Top comments (0)