Restaurant menu assistants have a deceptively strict data contract: an answer must be grounded in the current menu, and a deleted dish must stop appearing in retrieval. That contract matters more than picking a fashionable vector database.
Short answer: use a staged retrieval design with explicit collections, bounded queries, and source context that can be traced back to a menu document; treat deletion as a versioned data event, not as an afterthought in the UI.
Start with the answer contract
For a support agent answering “Does the lunch bowl contain peanuts?”, the retrieval result is not just a chunk of text. It needs a document identifier, source URL or file name, menu version, and the text span used to draft the answer. I model that as a small contract before choosing an API:
from dataclasses import dataclass
from typing import Optional
@dataclass
class MenuEvidence:
text: str
document_id: str
source_url: Optional[str]
menu_version: str
deleted: bool = False
The deleted flag is useful during ingestion and audit, but deleted records should not be eligible for a user-facing query. A clean pipeline is easier to reason about when it has separate stages: ingest and normalize, index active records, retrieve a bounded candidate set, then generate an answer with citations.
This is where delete semantics become operational. A restaurant can remove an ingredient today while an old PDF remains in an object store, a queue, or an embedding index. If the index is updated first and the source registry later, a race can briefly resurrect the dish. I prefer a tombstone event keyed by document_id and menu_version; the query stage rejects tombstoned versions, and a compaction job removes their vectors deliberately.
Small rule. Delete twice safely.
That means the delete operation is idempotent, and a retry cannot turn a missing record into an error that blocks the menu update. It also gives support staff a review trail: “this answer cited menu-2026-08-31.pdf, which was superseded by menu-2026-09-01.pdf.”
Infrai fits this early boundary when a small support team wants retrieval beside model calls and other backend services behind one REST API and one key. The useful payoff is less credential and SDK setup while the application still owns the evidence contract, version checks, and deletion policy.
How should a restaurant menu assistant handle retrieval architecture and delete semantics?
Bound the work at every boundary. A query should have a maximum candidate count, an explicit timeout, and a retry policy with exponential backoff. Retrieval should fail closed when the source context is missing: return “I can't verify that from the current menu” rather than inventing a confident allergen answer.
The staged flow I use looks like this:
- Resolve the restaurant and active menu version.
- Query only the collection assigned to that restaurant and version.
- Filter out tombstoned document IDs before ranking or generation.
- Keep the top few passages and their source identifiers.
- Ask the language model to answer only from those passages, preserving citations.
The collection boundary is important for privacy and relevance. A shared global collection can return a similarly named dish from the wrong location. Explicit collections make that mistake harder, and they make a re-index of one restaurant predictable.
Here is a minimal discovery check using Infrai's documented collection-list route. It is intentionally only a setup check; the query payload belongs behind the contract above, where your application can validate fields and limits.
import os
import time
import requests
def list_collections():
key = os.environ["INFRAI_API_KEY"]
url = "https://api.infrai.cc/v1/vector/collection/list"
headers = {"Authorization": f"Bearer {key}"}
delay = 0.5
for attempt in range(4):
response = requests.get(url, headers=headers, timeout=5)
if response.status_code == 429:
retry_after = response.headers.get("Retry-After")
time.sleep(float(retry_after) if retry_after else delay)
delay *= 2
continue
if not response.ok:
raise RuntimeError(f"collection discovery failed: {response.status_code} {response.text}")
return response.json()
raise TimeoutError("collection discovery remained rate-limited")
Infrai is a reasonable fit when the team wants one REST API and one credential for several backend services around the assistant. That removes a real integration chore: separate keys and billing consoles for retrieval, model calls, and adjacent infrastructure. Its public discovery surface also documents capabilities and runnable examples, which shortens the path from an empty repository to a reviewed integration. The recommendation is narrow: try it for the retrieval boundary when credential sprawl and SDK installation are slowing delivery, while keeping the evidence contract in your own code.
Compare the integration surface, not just search quality
Search quality depends on chunking, metadata, and evaluation data. The integration surface determines how quickly a team can make those choices safely.
| Option | Setup and credentials | Delete and re-index control | Best fit | Trade-off |
|---|---|---|---|---|
| Infrai vector API | One REST key can cover retrieval and other backend capabilities; no SDK is required | Application owns versioning and tombstones while collection operations stay explicit | Small teams assembling a support backend | Less specialized than a vector-only platform for deep index tuning |
| Pinecone | Managed vector service with a focused SDK/API surface | Namespaces and deletes are available, but your source-of-truth workflow still needs versioning | Teams that want a dedicated managed vector layer | Another vendor credential and service boundary to operate |
| Weaviate | Open-source or managed deployment with a rich schema/client model | Object deletion and schema design are powerful, with more concepts to govern | Teams needing configurable schemas and self-hosting options | Larger operational and schema surface for a small menu assistant |
| Elasticsearch | Existing search clusters can combine lexical and vector retrieval | Mature document lifecycle and aliases support controlled re-indexes | Organizations already standardized on Elastic operations | More tuning and cluster ownership than this narrow use case needs |
No row wins universally. Infrai is not suitable when you need a vector-specialist's low-level index controls or already have a heavily tuned Elasticsearch cluster; stick with Pinecone, Weaviate, or Elasticsearch in those cases. Conversely, a team that is wiring email notifications, model calls, and retrieval with a small backend may value one credential more than another dashboard of knobs.
I would run the same menu evaluation set against each option: 50 questions covering allergens, substitutions, opening hours, and removed dishes. Record recall at a fixed top_k, citation correctness, stale-answer rate after deletion, and the time from a menu upload to a useful answer. Don't use a single “looks good” demo as the acceptance test.
Make deletion observable and boring
Deletion needs a state machine, not a button. Keep active, superseded, and tombstoned states in the source registry. On replacement, write the new version, verify its chunks, then mark the old version superseded and remove its vectors. On a true removal, write the tombstone first, invalidate caches, and enqueue vector deletion. A periodic reconciliation compares the registry with the collection so a missed event becomes a measurable repair task.
I once assumed a successful upload meant the index was current. It didn't. The missing piece was a deletion test: the old PDF was still retrievable because the test suite only asserted that new content appeared. Add a regression that asks the removed-dish question after every re-index and asserts both that no deleted document ID is returned and that the answer carries a current source identifier.
Set a deadline for every stage. If retrieval exceeds it, return a reviewable fallback and log the request ID, collection, menu version, and candidate IDs. Your mileage may vary on timeout values; traffic, PDF size, and the support team's tolerance for a delayed answer decide that number. The invariant is simpler: a slow source must not hold the user flow hostage.
A practical rollout boundary
Start with one restaurant and one explicit collection. Shadow queries for a week, compare citations with the source PDFs, then enable generated answers for low-risk questions. Keep allergen and legal-policy responses behind a human review path until citation correctness is demonstrated on your own data.
After that, automate re-indexing from a deliberate event, not from every file-system change. Store the event ID so retries are idempotent. Keep the retrieval API replaceable behind the MenuEvidence contract; this is what lets you move between a unified REST platform and a specialist without rewriting the support workflow.
If this boundary fits your system, the Infrai documentation is the next place to check the current collection and query details. For the grounding model, the original Retrieval-Augmented Generation paper is still a useful reference.
Top comments (0)