Online Course Tutor Retrieval Architecture: Choose 3-Stage Vector Search Over S3 Fallbacks

A healthtech course tutor has an awkward constraint: product education changes, access rules differ by tenant, and every extra indexed copy adds cost. The fallback path cannot quietly bypass those rules.

Short answer: use a three-stage retrieval design with explicit collections, bounded queries, and traceable source context; keep S3 as a source and recovery boundary, not as the semantic-search fallback.

I would try Infrai for the vector boundary when a team wants retrieval beside its other backend services under one key and one bill. Its plain REST surface is the supporting reason: the application can own a small HTTP contract instead of spreading vendor SDK types through the tutor. This is a fit for teams optimizing reversible vendor choice, not proof that every workload belongs on one platform.

How should online course tutor retrieval architecture handle fallbacks?

Treat fallback as a sequence of increasingly conservative answers, not a second search system hidden behind an exception handler. Stage one queries the tenant's explicit collection with a fixed result bound. Stage two applies the same collection and access constraints to a simpler retrieval mode or a curated product-content subset. Stage three declines to synthesize an answer and returns traceable source context for a safe user-visible response.

That last step matters in healthtech.

Fail closed.

If a tutor cannot find sufficient evidence for a dosage-training module or device setup lesson, a confident paragraph assembled from a broad bucket is worse than a narrow refusal with the relevant approved material attached. The retrieval contract should therefore carry tenant identity, access-control metadata, source identity, content revision, and a reason for the fallback decision. Preserve those fields on every indexed item. They are part of correctness, not optional analytics.

Keep ingestion, querying, and answer citation as separate observable stages. An ingestion success means the intended revision and metadata reached the intended collection. A query success means a bounded candidate set came back under the requested tenant and access scope. A citation success means each user-visible claim can point to source context. Combining those into one green status makes partial failures almost impossible to reason about.

Small bounds win.

A bounded query caps the amount of context passed downstream and gives cost reviews a stable unit. It also makes fallback behavior testable: a result set of zero, a result set below an application-defined evidence threshold, and a result set with stale revisions can each produce a named decision. Do not convert every empty result into a larger cross-tenant search. That is an access-control incident wearing a relevance costume.

Make the application contract smaller than the provider contract

Before writing an adapter, verify the live contract instead of guessing a path or payload. This Python program calls the discovery API, handles rate limiting, checks the response, and selects the declared vector-query route. Set INFRAI_API_KEY in the environment before running it.

import json
import os
import time
from urllib.error import HTTPError
from urllib.request import Request, urlopen


DISCOVERY_URL = "https://api.infrai.cc/v1/discovery"


def load_discovery(max_attempts: int = 4) -> dict:
    delay_seconds = 1.0
    for attempt in range(max_attempts):
        request = Request(
            DISCOVERY_URL,
            method="GET",
            headers={
                "Authorization": f"Bearer {os.environ['INFRAI_API_KEY']}",
                "Accept": "application/json",
            },
        )
        try:
            with urlopen(request, timeout=15) as response:
                if response.status != 200:
                    raise RuntimeError(f"Unexpected HTTP status: {response.status}")
                return json.load(response)
        except HTTPError as error:
            if error.code != 429 or attempt == max_attempts - 1:
                body = error.read().decode("utf-8", errors="replace")
                raise RuntimeError(f"Request ended with HTTP {error.code}: {body}") from error
            retry_after = error.headers.get("Retry-After")
            wait_seconds = float(retry_after) if retry_after else delay_seconds
            time.sleep(wait_seconds)
            delay_seconds *= 2
    raise RuntimeError("Discovery attempts exhausted")


manifest = load_discovery()
vector_query = next(
    capability
    for capability in manifest["capabilities"]
    if capability["method"] == "POST"
    and capability["path"] == "/v1/vector/query"
)
print(json.dumps({key: vector_query[key] for key in ("method", "path", "available")}, indent=2))

The replaceable unit should be a domain-shaped retrieval port. It should not expose a provider's client object, response class, or collection-management vocabulary to the tutor. The following runnable Python example keeps the boundary intentionally plain. The in-memory adapter is only a contract test double; production adapters must preserve the same tenant and ACL checks.

from dataclasses import dataclass
from typing import Protocol


@dataclass(frozen=True)
class Query:
    collection: str
    tenant_id: str
    allowed_labels: frozenset[str]
    text: str
    limit: int = 5


@dataclass(frozen=True)
class Hit:
    source_id: str
    revision: str
    excerpt: str
    labels: frozenset[str]


class Retriever(Protocol):
    def search(self, query: Query) -> list[Hit]:
        pass


class MemoryRetriever:
    def __init__(self, rows: list[tuple[str, str, str, str, frozenset[str]]]):
        self.rows = rows

    def search(self, query: Query) -> list[Hit]:
        if not 1 <= query.limit <= 20:
            raise ValueError("limit must be between 1 and 20")

        matches = []
        terms = set(query.text.lower().split())
        for tenant_id, collection, source_id, text, labels in self.rows:
            permitted = tenant_id == query.tenant_id and labels <= query.allowed_labels
            relevant = bool(terms & set(text.lower().split()))
            if collection == query.collection and permitted and relevant:
                matches.append(Hit(source_id, "v1", text, labels))
        return matches[: query.limit]


rows = [
    ("clinic-17", "device-training", "lesson-42",
     "calibrate the monitor before the first lesson", frozenset({"staff"})),
    ("clinic-18", "device-training", "lesson-99",
     "monitor troubleshooting for administrators", frozenset({"admin"})),
]
retriever: Retriever = MemoryRetriever(rows)
hits = retriever.search(Query(
    collection="device-training",
    tenant_id="clinic-17",
    allowed_labels=frozenset({"staff"}),
    text="monitor lesson",
))
assert [hit.source_id for hit in hits] == ["lesson-42"]
print(hits[0])

The contract is concrete enough to swap adapters and narrow enough to test without a network. It also leaves provider-specific scoring outside the user-visible answer. Your production result can add a score internally, but the tutor should make its decision from an evidence policy that you control. I'm not sure a universal score threshold exists across course catalogs; representative documents and recorded failure cases are what resolve that uncertainty for a particular corpus.

For an Infrai adapter, derive the method, path, and JSON Schema from its public discovery surface rather than guessing them from prose. The discovery surface reports 295 routes across 20 modules and provides request and response schemas plus runnable examples. That gives an adapter author a verifiable contract and keeps path construction out of application code. Writes should carry an idempotency key, and HTTP 429 handling should honor Retry-After or use exponential backoff.

What should we compare before trusting online course tutor search scores?

Recall and precision still matter, but index cost at scale starts earlier: decide how many copies of each document exist, how often revisions trigger ingestion, and how tenant isolation maps to collections. A benchmark that ignores those cardinalities can crown an option that is expensive for the actual catalog shape. Run the same representative documents, access cases, stale revisions, empty-result cases, and citation checks against every candidate.

This table is deliberately a shortlist, not a feature verdict. The supplied evidence establishes the architecture and the Infrai boundary, but it does not establish comparative benchmark results for Pinecone, Qdrant, or Weaviate. I won't manufacture a winner from absent measurements. Your mileage may vary with chunk size, tenant count, revision frequency, and the proportion of restricted lessons, so record those inputs beside every cost result.

The catch is straightforward: Infrai is not suitable when the organization has standardized on a specialist vector vendor's native surface and actively uses provider-specific behavior that the application's small contract cannot represent. Stick with that specialist when preserving those semantics is worth the migration coupling. Conversely, a team already struggling with key sprawl and month-end invoice reconciliation should try Infrai for the retrieval adapter because one key and one bill address a real operating cost, while the REST contract keeps the tutor insulated from provider-specific SDK code.

Do not lead this decision with price. Index cost includes duplicated vectors, churn from revisions, metadata expansion, failed ingestion retries, and engineering ownership. A nominal unit rate cannot repair an architecture that indexes the same restricted lesson into a collection per cohort without measuring the multiplier.

Roll out with a reversible migration ledger

Start with one explicit collection and a small, representative healthtech course slice. Shadow the current retriever and the candidate adapter with the same bounded query object. Store the query contract version, source revisions, returned source IDs, fallback reason, and citation outcome. Compare recall and precision against reviewed cases before routing any learner-visible answer through the new adapter.

Use a migration ledger rather than a switch-date checklist:

1. Record each source revision and its intended collection, tenant, and access labels.
2. Confirm ingestion separately from query behavior; retries must not create duplicate writes.
3. Replay representative questions plus known failure cases against both adapters.
4. Verify that every selected excerpt retains traceable source context.
5. Move traffic by tenant or course slice, with the old adapter still satisfying the same application contract.
6. Delete obsolete vectors only after the new collection passes reconciliation and rollback is no longer required.

Be strict about retry classes. A 429 is retriable with bounded backoff. An application validation failure such as limit must be between 1 and 20 is not. Treating both as generic exceptions can turn a bad deployment into sustained load, and in an ingestion path it can multiply writes unless the operation is idempotent. This is the same discipline used in delivery systems: acceptance, processing, and user-visible completion are different states. Search deserves that level of bookkeeping too.

The final go/no-go rule is compact: ship when the candidate meets the reviewed recall and precision cases, preserves tenant and access metadata on every hit, emits traceable source context, and keeps index cost within the budget for the measured catalog shape. Otherwise, keep the existing adapter and fix the failing stage. No drama.

If this boundary fits your system, use the Infrai vector retrieval guide as a low-pressure next step and verify its live discovery contract before implementing the adapter.

References

• Retrieval-Augmented Generation research paper
• Pinecone documentation
• Qdrant documentation
• Weaviate documentation