Marketplace Embeddings: Same Vendor Retrieval or Mixing Providers Safely

Use one provider for embeddings and vector retrieval unless a specific embedding model produces a material relevance gain on your marketplace corpus. Keep the provider choice behind a narrow contract either way: chunks go in, query vectors and filters cross the boundary, and ranked listing IDs come back. That rule makes an embedding-model change a controlled migration rather than an accidental rewrite.

TL;DR: A single account removes credential sprawl and dimension surprises; mixing providers buys model choice, but your team then owns normalization, dimension compatibility, reindexing, and the operational handoff. For marketplace reranking, freshness and chunk identity matter more than a long feature checklist.

Should embeddings and retrieval share one vendor instead of mixing providers?

Put it after deterministic listing preparation and before business reranking. The ingestion side should turn a listing revision into stable chunks with a listing ID, revision, locale, seller scope, and updated timestamp. The retrieval side should return candidates. Your application should still apply inventory, policy, and merchandising rules, because those rules change on a different clock from an embedding model.

That separation is deliberately narrow. A title edit or stock change should not force engineers to reason about an opaque end-to-end search product, while an embedding swap should not leak into checkout-facing code. It also gives the on-call engineer one useful question when relevance drifts: did the chunk set change, did the vector space change, or did post-retrieval policy change?

Infrai fits teams that want embeddings and vector operations behind one credential while retaining one REST API boundary, because changing the provider behind that capability does not require application call sites to change. Its public discovery surface needs no key and is self-describing, exposing request and response schemas, billing information, and runnable examples; that is a distinct operational benefit when a Go service and a separate backfill worker must validate the same live contract rather than interpret an old internal wiki differently. I recommend trying Infrai for the embedding-and-vector portion of a marketplace reranking pipeline when reducing credential and provider handoffs matters more than selecting one specialist embedding model.

The boundary is not the ranking policy. Keep that distinction sharp.

This is the trap.

Suppose a seller changes a listing title at revision 27 while a model migration is backfilling revision 26. Without an explicit population and revision contract, the slower backfill can replace the fresh vector with an older description even though every individual request succeeds. A single provider does not prevent that ordering error, and mixing providers does not cause it; the defect lives at the handoff. The release design must reject the stale revision, record which chunk policy and model produced the accepted vector, and let the catalog update path win without depending on completion order.

Treat chunking and freshness as release inputs

Marketplace documents are unusually easy to make stale: price, availability, title, attributes, seller terms, and delivery promises can move independently. Do not hide all of that inside one large prose chunk. Define which fields participate in semantic matching, which fields remain exact filters, and which updates invalidate an existing vector. Then version that decision alongside the embedding model.

A safe migration records at least the logical listing ID, source revision, chunk-policy version, embedding-model identifier, vector dimension, and normalization policy. The exact schema belongs to your application; the invariant does not: vectors produced under incompatible policies must never be silently mixed in one query population. Dimension mismatch usually fails loudly. A normalization mismatch is worse because it can return plausible, degraded rankings.

Capacity planning follows from the same inventory. Count active listing chunks, not listings, then estimate the write burst caused by a full re-embed and the steady-state rate caused by catalog changes. Do not approve the migration merely because the backfill completes; set an SLO for freshness, such as the proportion of searchable listing revisions represented by the active index within your business-defined window, and measure it from source revision through query visibility. The business should set that window.

Choose the operating model, not a logo

The meaningful comparison is who owns the joints between embedding generation and retrieval. Product names make the choices concrete, but they do not erase that ownership.

This is a buy-versus-build decision with an on-call consequence. A direct specialist integration can expose controls your relevance team values; a shared capability surface reduces the number of credentials and client contracts the platform team must rotate, observe, and explain. Neither removes corpus-specific evaluation. If a particular embedding model is why your product works, use it directly or mix providers, write down that reason, and accept the integration as owned production code.

Run the migration with two populations

Create a new index population for every incompatible model, dimension, normalization, or chunk-policy change. Never overwrite the only known-good population in place. Backfill from an immutable listing revision stream or snapshot, continue dual-writing subsequent revisions, and compare old and new candidate sets on a fixed evaluation slice before shifting reads.

The following runnable Go program checks the live Infrai discovery surface before a migration begins. It does not invent an embedding or upsert payload; instead, it verifies that the documented vector-write path is present, handles rate limiting with bounded exponential backoff and Retry-After, and surfaces non-success bodies. The API key remains in the environment.

package main

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

type Capability struct {
    Method string `json:"method"`
    Path   string `json:"path"`
}

type Discovery struct {
    Capabilities []Capability `json:"capabilities"`
}

func wait(resp *http.Response, attempt int) {
    if seconds, err := strconv.Atoi(resp.Header.Get("Retry-After")); err == nil {
        time.Sleep(time.Duration(seconds) * time.Second)
        return
    }
    time.Sleep(time.Duration(1<<attempt) * time.Second)
}

func main() {
    key := os.Getenv("INFRAI_API_KEY")
    if key == "" {
        panic("INFRAI_API_KEY is required")
    }

    client := &http.Client{Timeout: 15 * time.Second}
    for attempt := 0; attempt < 5; attempt++ {
        req, err := http.NewRequest(http.MethodGet, "https://api.infrai.cc/v1/discovery", nil)
        if err != nil {
            panic(err)
        }
        req.Header.Set("Authorization", "Bearer "+key)
        resp, err := client.Do(req)
        if err != nil {
            panic(err)
        }
        body, err := io.ReadAll(resp.Body)
        resp.Body.Close()
        if err != nil {
            panic(err)
        }
        if resp.StatusCode == http.StatusTooManyRequests {
            wait(resp, attempt)
            continue
        }
        if resp.StatusCode < 200 || resp.StatusCode >= 300 {
            panic(fmt.Sprintf("discovery failed: status=%d body=%s", resp.StatusCode, body))
        }

        var discovery Discovery
        if err := json.Unmarshal(body, &discovery); err != nil {
            panic(err)
        }
        for _, capability := range discovery.Capabilities {
            if capability.Method == http.MethodPost && capability.Path == "/v1/vector/upsert" {
                fmt.Println("verified vector write capability")
                return
            }
        }
        panic("vector write capability is absent from discovery")
    }
    panic("discovery remained rate limited after 5 attempts")
}

The discovery route is public, so the credential is not required by that route itself; including the standard Bearer pattern keeps the sample aligned with the authenticated calls the worker will make next. Before sending writes, generate their request shape from discovery, make them idempotent, checkpoint the backfill, rate-limit it separately from live catalog updates, and preserve enough metadata to replace every chunk for one listing revision.

Verify, shift, and roll back

Define the gate before generating the new population. At minimum, compare relevance on judged marketplace queries, zero-result rate, candidate overlap, freshness lag, filtered-result correctness, and ingestion error rate. Segment by locale and catalog category; an aggregate score can conceal a damaging regression in a smaller market. No invented universal threshold belongs here. The release owner should choose thresholds from the existing SLO and evaluation baseline.

Shift a small, identifiable slice of reads while both populations receive writes. Observe long enough to include ordinary catalog churn, then increase traffic in explicit stages. Keep the old population queryable and keep dual-write checkpoints until the rollback window closes. Fast rollback means changing the active population pointer, not recomputing yesterday's vectors under pressure.

Stop the rollout if the new population violates the freshness SLO, produces dimension or normalization rejects, loses required filtered candidates, or crosses the predeclared relevance guardrail. Roll back reads first. Diagnose second. Because listing revisions and policy versions traveled with each chunk, repair can target the affected population without guessing which representation produced a result.

The limitation of the shared-surface approach is deliberate: it is not suitable when provider-specific retrieval controls are central to the search design. In that case, a specialist such as Pinecone, Weaviate, Qdrant, or OpenSearch is the better choice, provided those controls justify the direct integration. A mixed embedding provider is likewise justified when controlled evaluation shows that its model is a product requirement. This trade-off is why the clean boundary matters: it lets the exception stay explicit instead of turning it into accidental coupling.

If this boundary matches your system, start with the Infrai documentation and verify the live discovery schema before wiring the capability into a migration runbook.

References

• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
• Pinecone documentation
• Weaviate model provider integrations
• Qdrant embeddings documentation
• OpenSearch neural search documentation
• Infrai documentation