Three enterprise platforms, and one we run ourselves

Answers are grounded in a corpus stored in PostgreSQL with pgvector, so retrieval and vector search live in the same database as the rest of the application rather than in a separate vector service. One datastore, one backup story, one set of credentials to protect.

The hard part was never the embedding call. It was deciding what belongs in the corpus, and keeping what the retriever can reach aligned with what the assistant is allowed to say.

Not every question should be answered from the corpus. InfoYog routes between retrieval-grounded answers and web-backed answers depending on whether the retrieved context actually supports the question being asked.

A retrieval system that answers confidently from weak context is worse than one that declines and goes elsewhere. Most of the engineering effort went into that judgment.

Authentication runs through Firebase Auth; credentials and API keys live in Secret Manager, never in configuration files or the container image.

The retrieval boundary is treated as a security boundary: what the model can reach is scoped deliberately, because an assistant with broad read access is an exfiltration path waiting to be found. This is the same review we sell as our LLM/RAG Integration Security Design Review.

The backend is covered by automated tests, and answer quality is checked through log-based QA: reviewing what the system actually did, rather than relying on spot checks.

Token consumption is treated as an engineering constraint, not an afterthought. Cost-aware refinements have reduced per-query token consumption.

InfoYog supports English, Hindi and Marathi, and ships to Android and the web from a single Flutter codebase, served by REST APIs on the Spring Boot backend.