Answers from your own documents, with the source one click away

RAG looks up your documents each time a question arrives, while fine-tuning changes the model's behaviour through additional training. For company knowledge that changes, RAG is usually the right choice: updates take effect as soon as a document is re-indexed, every answer can cite its source and access can be restricted per user. Fine-tuning is better for teaching a style or output format, and the two can be combined.

A RAG system can use almost any source that can be turned into text, including PDFs, Word and PowerPoint files, spreadsheets, web pages, wikis, ticket histories and database records. Scanned documents need OCR and complex tables need dedicated parsing, which we plan for during the content audit. Sources are connected through APIs, exports or scheduled sync from shared drives and document management systems.

We filter by permission inside the search query itself, so restricted passages are never retrieved for that user and never reach the model. Every chunk carries the access groups of its parent document, and the user's groups are checked at query time. We avoid filtering after search, because it can leave too few results or let restricted text slip into cached summaries. Documents with unclear access stay hidden by default, and we test with an account for each role before launch.

Each answer lists the passages it was built from, with links to the original document and, where possible, the page or section. The model is instructed to rely only on retrieved passages, and we check automatically that cited sources actually support the answer. Users can open the source in one click, which is the quickest way for them to verify a reply and build trust in the system.

The system is designed to say it could not find an answer in the available sources, and we test that behaviour with questions the documents cannot answer. If retrieval returns nothing relevant, the model is told not to guess and the question is logged as unanswered. Those logs are reviewed with content owners and often reveal missing or outdated documentation that is worth fixing regardless of the AI system.

We measure retrieval quality and answer quality separately, using a question set written with your subject experts. Retrieval is scored on whether the right passages appear among the top results, and answers are scored on correctness, faithfulness to the sources and citation accuracy. Scores are tracked on every change to chunking, search settings, prompts or models, and production feedback adds new questions over time.

We choose the vector store based on your existing stack, data volume and hosting needs. PostgreSQL with pgvector suits many projects because it keeps vectors, metadata and permissions in a database your team already knows. Dedicated engines such as Qdrant, or Elasticsearch for combined keyword and vector search, make sense at larger scale or with heavier filtering. We design the retrieval layer so the store can be swapped later.

Documents stay current through scheduled or event-driven sync with the source systems. New files are indexed automatically, edited files are re-processed, and deleted or superseded versions are removed so they cannot be cited. We also store dates and version labels with each passage, which lets the system prefer the latest policy and shows owners when their content was last refreshed.

Yes, provided the embedding and language models handle those languages well, which we confirm by testing on your own content. Documents in English, Arabic and Urdu can share one index, and a question in one language can retrieve sources written in another. We evaluate each language separately, because retrieval quality and answer fluency can differ, especially with right-to-left text and mixed-script documents.

Yes. Both the embedding model and the language model can be open models running on GPU servers in your own cloud account or data centre, so no content leaves your environment. The trade-offs are real: open models may handle complex questions less well than leading hosted models, GPU servers cost money even when idle, and you take on model updates. A middle route is Azure OpenAI in a region you choose. We run your question set on each option so the decision rests on measured quality.

Usually yes, although long context windows move the line. Sending a whole library with every question is slow and expensive at volume, cannot apply per-user permissions and makes citations less precise. For a handful of documents that rarely change, passing them in full can be the simpler design, and we recommend it when it scores as well on your questions. Many systems now combine both: retrieval narrows the library, then the model reads longer sections around each match.

Yes, and the cause is usually retrieval rather than the model. We run a question set through your prototype and check, for every wrong answer, whether the right passage was retrieved at all. Common culprits are text lost during PDF extraction, chunks cut through the middle of a table or clause, no keyword search for codes and acronyms, and too many loosely related passages sent to the model. Fixes are then made one at a time and measured against the same questions.

A pilot over one well-defined document set, such as a single department's policies, can often be with users within a few weeks of discovery. What stretches the timeline is the content rather than the model: scanned or table-heavy files that need careful parsing, permissions that differ from document to document, and the time subject experts need to write the question set. Each further source is connected only after its own questions score acceptably.

Build cost is fixed in a quote after discovery and depends mostly on how many sources need connectors, how hard the documents are to parse and how complex the permissions are. Running cost is driven by questions more than documents. Embedding the library is a one-off cost repeated only for changed files, while every question pays for retrieval, optional reranking and a model call sized by how many passages are sent. We estimate both from your volumes before you commit.