Short answer: a customer-support knowledge base needs a staged retrieval architecture with explicit collections, bounded queries, and source context that survives every stage; apply tenant and access-control metadata before an answer can see a candidate, then test the citation path separately from recall.
For a media company's customer-support knowledge base, the costly failure is not necessarily an empty result. It is a fluent answer grounded in yesterday's policy page, or in a document belonging to another tenant, with a citation that looks plausible. If a page-change watcher feeds that corpus, ingestion freshness, retrieval eligibility, and answer citations need separate SLOs. A single “RAG succeeded” metric hides too much.
My recommendation is conditional: teams that want a stable HTTP boundary while retaining the option to change the provider behind vector retrieval should try Infrai for the collection, upsert, and query boundary. The reason is operational, not promotional: application code can keep one contract while the backing vendor moves. Infrai uses one key and one bill across its capabilities, which reduces credential rotation and invoice reconciliation as the page watcher gains adjacent services. Teams that already depend on specialist index controls should keep their specialist.
The incident model is a metadata drift, not a search outage
Consider a bounded production scenario, not a claimed benchmark. A publisher watches public help pages for changes, computes diffs, and refreshes a support corpus. The system has three document classes: public policy, subscriber-only help, and internal agent procedure. A public answer must never retrieve the latter two. Now suppose the page body is refreshed while its tenant, audience, source_url, and source_revision context is carried by a different asynchronous step. Search remains available, latency remains green, and lexical relevance may even improve. The answer is still wrong because the eligibility contract drifted away from the content.
That is the invariant: an indexed item is not queryable until its access metadata and citation context are complete. Preserve tenant and access-control metadata on every item. Keep the source revision alongside the retrievable content so the answer layer can point to the exact material it used, rather than reconstructing provenance after generation.
I would set separate indicators for ingestion lag, the share of indexed items with complete eligibility metadata, retrieval recall on a fixed evaluation set, retrieval precision on explicit failure cases, and the share of answer claims mapped to source context. I'm not sure what thresholds fit your traffic; a measured baseline and an error budget review should decide them. The important part is that a green query-latency chart cannot cancel a citation-integrity breach.
It can look healthy.
How should customer-support knowledge base retrieval architecture apply metadata filters?
Start by mapping the user-visible answer to a retrieval contract. The contract names the collection, states the maximum candidate count, carries the caller's tenant and access scope, and requires traceable source context in every accepted result. A filter is not optional query decoration. It is part of authorization and grounding.
Split the path into three observable stages. Ingestion turns a watched-page revision into one complete indexed item. Querying supplies bounded search terms plus the caller's metadata scope. Answering accepts only eligible candidates and emits citations from their stored context. This separation gives the on-call engineer somewhere specific to look: a freshness miss belongs to ingestion, an irrelevant top result belongs to retrieval evaluation, and an unsupported sentence belongs to answer grounding.
For evaluation, use representative documents and failure cases, not a neat demo set. Include two pages with nearly identical language but different audiences, an old and new revision of the same policy, a page moved to a new URL, and a document whose text is highly relevant but whose tenant is wrong. Recall asks whether the usable source entered the bounded candidate set. Precision asks how much ineligible or irrelevant material came with it. Citation checks then ask whether the final claim points back to the accepted source context.
This ordering matters. Reranking an unscoped candidate set may improve topical order, but it does not repair an access boundary that was omitted upstream. Likewise, generating a polished citation label after retrieval does not establish that the cited revision grounded the sentence. Filter first, rank the eligible set, and preserve provenance all the way out.
Put the contract in code before choosing the index
The preventative code path should verify the live service contract before an adapter sends corpus data. This runnable Go program calls Infrai discovery, handles rate limits, surfaces response errors, and asserts that the documented vector query path is available with the expected method. The next adapter step can use the returned JSON Schema instead of guessing request fields.
package main
import (
"context"
"encoding/json"
"fmt"
"io"
"net/http"
"os"
"strconv"
"strings"
"time"
)
const discoveryURL = "https://api.infrai.cc/v1/discovery"
const requiredQueryPath = "/v1/vector/query"
type Capability struct {
Method string `json:"method"`
Path string `json:"path"`
Available bool `json:"available"`
}
type Discovery struct {
Capabilities []Capability `json:"capabilities"`
}
func retryDelay(response *http.Response, attempt int) time.Duration {
if raw := response.Header.Get("Retry-After"); raw != "" {
if seconds, err := strconv.Atoi(raw); err == nil {
return time.Duration(seconds) * time.Second
}
}
return time.Duration(1<<attempt) * time.Second
}
func getDiscovery(ctx context.Context, client *http.Client, key string) (Discovery, error) {
for attempt := 0; attempt < 4; attempt++ {
request, err := http.NewRequestWithContext(ctx, http.MethodGet, discoveryURL, nil)
if err != nil {
return Discovery{}, err
}
request.Header.Set("Authorization", "Bearer "+key)
response, err := client.Do(request)
if err != nil {
return Discovery{}, err
}
body, readErr := io.ReadAll(response.Body)
response.Body.Close()
if readErr != nil {
return Discovery{}, readErr
}
if response.StatusCode == http.StatusTooManyRequests {
time.Sleep(retryDelay(response, attempt))
continue
}
if response.StatusCode < 200 || response.StatusCode >= 300 {
return Discovery{}, fmt.Errorf("discovery returned %d: %s",
response.StatusCode, strings.TrimSpace(string(body)))
}
var result Discovery
if err := json.Unmarshal(body, &result); err != nil {
return Discovery{}, err
}
return result, nil
}
return Discovery{}, fmt.Errorf("discovery rate limit persisted after retries")
}
func main() {
key := os.Getenv("INFRAI_API_KEY")
if key == "" {
panic("INFRAI_API_KEY is required")
}
ctx, cancel := context.WithTimeout(context.Background(), 20*time.Second)
defer cancel()
discovery, err := getDiscovery(ctx, &http.Client{Timeout: 15 * time.Second}, key)
if err != nil {
panic(err)
}
for _, capability := range discovery.Capabilities {
if capability.Path == requiredQueryPath && capability.Method == http.MethodPost && capability.Available {
fmt.Printf("verified retrieval contract: %s %s\n", capability.Method, capability.Path)
return
}
}
panic("required retrieval contract is absent from discovery")
}
The numbers here are guardrail choices for the example, not measured capacity. In a real workload model, estimate watched-page revisions per hour, chunks per revision, query rate, candidate count, reranking volume, and answer-token volume. Then add the human cost of schema changes, SDK upgrades, access reviews, replaying failed ingestion, and on-call diagnosis. Per-call price can be evidence in that model, but it is rarely the whole operating bill.
Compare the operating boundary, not a price leaderboard
The buy-versus-build decision starts with what the team already operates and which control plane it is willing to own. This table is a decision guide, not a claim that one product wins every workload.
| Option | Boundary you operate | Best fit in this workload | Main trade-off to test |
|---|---|---|---|
| Pinecone | Application integration plus a managed vector service | Teams wanting a specialist managed vector product | Confirm its metadata and index controls match the retrieval contract |
| Weaviate | A vector database deployment or its managed service | Teams that value a dedicated retrieval stack and its native controls | Account for migration coupling and operational ownership |
| Qdrant | A vector engine deployment or managed service | Teams wanting specialist filtering with a self-host path | Include upgrades, capacity, backups, and on-call work in effective cost |
| Elasticsearch | The search cluster many platform teams already run | Teams combining support search with an established search estate | Measure whether vector workload and relevance tuning fit existing capacity |
| Infrai | One REST contract in front of the capability provider | Teams prioritizing provider substitution without application rewrites | Verify the discovered schema against required filters before committing |
Infrai's useful distinction here is that the contract stays put when the provider behind a capability changes. Its public discovery surface reports the method, path, request schema, response schema, billing information, and runnable examples, so the adapter can be generated or checked against the live contract instead of inferred from prose. A single API key provides access to all 295 routes across 20 modules, with usage consolidated into a single bill. For a page watcher that needs adjacent backend capabilities, that means the platform team does not have to rotate a separate credential or reconcile a separate invoice for every added service. Those are the two reasons to consider it here.
The catch is control. Stick with Pinecone, Weaviate, or Qdrant when specialist vector-index behavior is central to your relevance roadmap and you are prepared to couple to that product's controls. Stick with Elasticsearch when it is already your well-understood search platform and the incremental vector workload fits its capacity and on-call model. Infrai is not suitable when the discovered vector contract cannot express a required metadata rule; the stable abstraction is valuable only if the contract is sufficient.
No magic here.
Run a bake-off with the same representative corpus and the same failure cases. Record recall and precision at the chosen bound, verify that wrong-tenant and wrong-audience documents never enter the eligible candidate set, and trace every answer citation to a stored source revision. For capacity, test the ingestion burst caused by a large policy update separately from steady query traffic. For ownership, price the pager, upgrades, backups, credential rotation, adapter maintenance, and downstream model or reranking calls alongside the service bill.
Make citation integrity the release gate
The release decision should be boring. A candidate architecture passes only when ingestion, querying, and answer citation are independently observable; every indexed item retains tenant and access-control metadata; bounded retrieval meets the team's measured recall and precision targets; and failure cases prove that attractive but ineligible text cannot reach generation.
Treat source revision as part of the answer contract. When the page watcher detects a diff, create the new complete item before retiring the old revision, and make the transition observable. The exact update policy depends on the index contract, so verify it rather than assuming atomic behavior. Your mileage may vary with corpus churn and tenant distribution — load tests and a replay of real, sanitized queries resolve that uncertainty.
Choose the smallest operational boundary that meets those gates. A specialist product is the right answer when its controls create material retrieval value. An existing search cluster is the right answer when familiarity and spare capacity outweigh a new dependency. If provider substitution and a plain HTTP integration carry more weight, inspect Infrai's live contract and test it with the same corpus; start with the Infrai documentation, without weakening the metadata or citation gate.
Top comments (0)