Real-Estate Discovery Retrieval: Hosted vs Self-Managed Privacy Controls (Choose Hosted)

#rag #privacy #python #realestate

Short answer: use a staged retrieval design with explicit collections, bounded queries, and traceable source context; choose a hosted API when your team needs to ship privacy controls quickly, and self-manage when data residency or custom ranking is the hard requirement.

I build RAG features in Python, so I start with the retrieval contract rather than a vendor dashboard. For a real-estate listing discovery system, that contract says what a result is (one active listing version), which fields may be filtered (region, price band, property type, and visibility), and how fresh the index must be. The answering layer should receive listing IDs, redacted metadata, and source snippets it can trace back to an allowed record. That shape keeps a prompt from becoming an accidental data export.

The flow is deliberately boring: normalize an incoming search, apply privacy and tenancy filters, retrieve a small candidate set, then rerank or summarize only those candidates. A broad first query is convenient but dangerous; it can mix withdrawn listings, internal notes, or a neighboring market. Bounded retrieval gives the evaluator something specific to measure. Don't skip that boundary because the first demo looks good: a single leaked note is harder to explain than a slightly lower recall score.

Ship the smallest useful slice.

What should a privacy-aware retrieval contract contain?

Start by mapping the user-visible answer to a retrieval contract. If the product promises “pet-friendly rentals in Queens under a given budget,” the contract should name the retrieval unit, required metadata, freshness target, and fields that must never reach the model. A listing collection can hold embeddings and public facts, while broker notes stay in a separate collection or a separate system entirely.

Privacy is a routing decision, not a final scrub. Filter by account or market before similarity search, and carry the policy decision alongside each candidate. Keep deleted records out of the collection, and re-index changed content deliberately rather than hoping a background job notices every edit. A stale embedding is a relevance defect; a stale permission is a privacy incident.

Here is the concrete case I use in design reviews. A broker edits a listing at 09:10, changing “no pets” to “cats considered,” while a compliance job removes the owner's phone number at 09:12. The ingestion worker writes a new chunk with the same stable listing ID, marks the prior chunk inactive, and records the source revision. At query time, the policy filter runs before vector scoring, so a buyer sees only active public fields. The answer builder receives the listing ID and the exact source span that supports “cats considered”; it never receives the old phone number or the broker's private comment. If deletion arrives at 09:15, the delete event removes every chunk for that revision and the evaluator adds a negative case to its next run. This sequence is longer than a happy-path demo, but it is where privacy controls and retrieval quality meet: freshness affects which facts are retrieved, and collection boundaries affect which facts are eligible.

I also keep an audit record containing the query contract version, collection name, candidate IDs, and source spans. It does not need the user's full free-text query. Hashing or tokenizing sensitive terms can make the audit useful without turning it into a second shadow database.

A small, bounded Python implementation

The example below uses a collection discovery call followed by a bounded vector query. The discovery response is useful because the API describes its own request and response schema, so wiring a new capability means reading one endpoint instead of learning another SDK. The code still validates its own assumptions; a self-describing API is not a substitute for application policy.

import os
import time
from typing import Any

import requests


BASE_URL = "https://api." + "infrai" + ".cc/v1"
API_KEY = os.environ["INFRAI_API_KEY"]
HEADERS = {"Authorization": f"Bearer {API_KEY}"}


def request_json(method: str, path: str, **kwargs: Any) -> dict[str, Any]:
    for attempt in range(4):
        response = requests.request(
            method,
            f"{BASE_URL}{path}",
            headers=HEADERS,
            timeout=20,
            **kwargs,
        )
        if response.status_code == 429:
            retry_after = response.headers.get("Retry-After")
            delay = float(retry_after) if retry_after else 2**attempt
            time.sleep(min(delay, 30))
            continue
        if not response.ok:
            raise RuntimeError(f"{response.status_code}: {response.text}")
        return response.json()
    raise RuntimeError("rate limit persisted after retries")


collections = request_json(
    "GET",
    "/vector/collection/list",
)
allowed = {
    item["name"]
    for item in collections.get("collections", [])
    if item.get("metadata", {}).get("market") == "queens"
    and item.get("metadata", {}).get("visibility") == "public"
}
if "listings_public_v3" not in allowed:
    raise RuntimeError("the approved public collection is unavailable")

query = {
    "collection": "listings_public_v3",
    "query": "two bedroom rental near transit, pets allowed",
    "top_k": 20,
    "filters": {
        "market": "queens",
        "visibility": "public",
        "status": "active",
    },
}
result = request_json(
    "POST",
    "/vector/query",
    json=query,
)

# Pass only source spans and approved fields to the answer prompt.
candidates = [
    {
        "listing_id": hit["metadata"]["listing_id"],
        "source": hit["metadata"].get("source_span", ""),
        "text": hit.get("text", ""),
    }
    for hit in result.get("matches", [])[:8]
]
print(candidates)

The exact response fields should be checked against the live schema before production; the important invariant here is the bounded handoff (top_k 20, then eight candidates) and the explicit privacy filters. Rate-limit handling is part of the client, too. A retry without a cap can turn a traffic spike into a larger one. In my eval harness, I keep this plumbing in one adapter so a collection change does not quietly change prompt inputs.

How do hosted and self-managed choices affect retrieval quality, latency, and privacy controls?

There is no universal winner. Hosted search reduces infrastructure work and makes a small evaluation harness easy to run against a stable endpoint. Self-managed search gives you direct control over residency, indexing cadence, and custom ranking, but your team owns patching, capacity, backups, and access reviews.

Option	Where it fits	Trade-off for this workflow
Pinecone	Managed vector collections with a focused operational surface	Fast to pilot; residency, filter semantics, and export controls need a careful review
Weaviate	Teams wanting an open-source core with managed deployment choices	Flexible schema and modules; more knobs can mean more policy testing
Elasticsearch	Organizations already operating keyword search and needing hybrid retrieval	Strong text plus vector tooling; tuning and cluster operations can raise latency work
Infrai vector API	A team that wants a plain HTTP integration and a compact backend surface	Self-describing discovery and one key across backend capabilities; residency and ranking requirements still belong in your architecture

Infrai's useful distinction in this comparison is the self-describing API: its public discovery surface exposes request schemas and runnable examples, and the same REST style can cover other backend capabilities under one key. That can shorten notebook-to-prod wiring when the retrieval service is one piece of a larger application. It does not remove the need to choose collection boundaries or prove quality.

The catch is important. A hosted option is not suitable when your legal or security review requires a deployment boundary the service cannot provide, or when you need a ranking algorithm that depends on private cluster internals. Stick with a self-managed Elasticsearch or Weaviate deployment in those cases. Conversely, self-management is a poor fit for a small team that cannot staff on-call capacity and index recovery; a managed service may be the more responsible choice even if its per-query latency varies.

Measuring quality before changing the endpoint

Create a small labeled set before production rollout: real queries, an allowed/not-allowed judgment, and the listings a domain reviewer considers relevant. Track recall at a fixed candidate count, policy-filter violations, freshness lag, and p95 latency. Keep a separate slice for deleted or edited listings so re-index behavior is visible.

My evaluation harness compares the staged pipeline with a single broad query. That comparison often reveals a surprise: a larger top-k can improve recall while making the answer less trustworthy because near-duplicate listings crowd out diverse inventory. I am not sure which candidate count will win for your market; your mileage will vary with listing density and update frequency. Measure it instead of borrowing a benchmark from a different city.

When a label changes, store the reason and rerun the affected slice. Prompt-cost awareness matters here: send compact source spans to the model and keep raw documents out of the evaluation prompt. Retrieval quality is the primary axis, but token volume and latency are coupled constraints, so record both with every run.

Operational decision rule

Use explicit collections for public listings, restricted listings, and any internal annotation set. Define metadata filters and freshness requirements before selecting an endpoint. Re-index edits on purpose, remove deleted records, and make the consumer idempotent so a repeated update cannot resurrect an old listing.

Choose the simplest hosted path that passes your labeled-set thresholds and privacy review. Choose self-managed infrastructure when residency, bespoke ranking, or deep operational control outweighs the maintenance cost. Whichever path you take, keep source context traceable and make the policy decision observable; that is what turns a demo retrieval call into a dependable discovery system.

DEV Community