How does a custom RAG system compare to Zendesk AI or Intercom AI for a mid-market support team?+
A custom RAG system grounds every answer in your current product docs, release notes, and ticket history, cites each factual claim to its source, and refuses to answer when the retrieved context does not support the claim. Generic help-desk AI add-ons optimize for deflection metrics and will often invent plausible-sounding answers when retrieval is thin. For teams of 20 to 300 agents the custom path typically costs less than per-resolved-conversation pricing by month 18, and removes the hallucination risk legal teams flag on the generic platforms.
How do you stop the system from hallucinating?+
Three mechanisms work together. First, the prompt and orchestration layer explicitly instruct the LLM to answer only from retrieved context and to refuse otherwise. Second, every claim in the answer is linked to a source chunk, and answers without citations are suppressed. Third, a weekly evaluation harness scores the system on precision, recall, and refusal rate against 150 to 300 graded real tickets, so hallucination regressions are caught before they reach agents.
What happens when the system does not know the answer?+
It refuses. The system is designed to say "I do not have a source for that" rather than invent, and to route the ticket to a human agent with the exact query logged. The refusal rate is a tracked metric, not a bug: a healthy production RAG for support typically refuses between 5 and 15 percent of queries, and that number is reviewed every month against your real traffic.
How do you handle access control so internal runbooks do not surface in answers to end users?+
Access control is applied at the chunk level, not the document level, and mirrors your existing identity provider. Each chunk inherits the ACL of its source, and the retrieval step filters by the caller's identity before any context reaches the LLM. An agent-facing assistant and a customer-facing assistant draw from overlapping corpora with different permission boundaries, defined in writing before the first chunk is indexed.
Which embedding model and LLM do you use?+
We choose per engagement, based on quality, latency, cost, and data residency. For EU-region engagements we prefer open-source embedding models self-hosted in Frankfurt or hosted models with clean EU data-processing terms. For the generation step we use the model that scores best on your evaluation set among the options allowed by your DPA, typically from Anthropic, OpenAI, Mistral, or an open-weights model self-hosted. The choice is written into the scope and reviewed quarterly.
How often is the index refreshed when our docs change?+
The default refresh pipeline is nightly for product docs and release notes, with event-driven updates on major releases. Ticket-history corpora refresh weekly. The cadence is tied to your release and documentation rhythm, written into the operations runbook, and monitored so stale sources trigger alerts rather than silent drift.
What is the latency per answer?+
End-to-end response time is typically between 1 and 4 seconds depending on retrieval depth and generation model. The retrieval step itself usually sits under 300 milliseconds. Latency targets are written into the SLA when the assistant is customer-facing, and the full timing breakdown (retrieval, generation, post-processing) is logged for every answer.
Where will the knowledge base and vector index live?+
By default in the Frankfurt (EU) region of a hyperscale cloud under a signed data processing agreement, with the option to run it in your own cloud account instead. We do not use US-only services anywhere in the pipeline when EU-region hosting is in scope, and sub-processors are listed and reviewed quarterly.
How do you handle personally identifiable information in indexed ticket history?+
Before any ticket enters the index it passes through a redaction stage that removes direct identifiers (names, emails, phone numbers, account IDs) and tags sensitive fields. Redaction policy is written into the scope, reviewed by your DPO, and tested as part of the evaluation harness. The raw ticket store remains untouched; redaction happens on the way into the retrieval pipeline.
How does this comply with the EU AI Act and GDPR?+
A data processing agreement is signed before build begins and covers every system in the pipeline. The RAG system is inventoried against the EU AI Act risk tiers (typically limited-risk for internal support assistants, with transparency obligations) and ships with the documentation that act requires: purpose, training and retrieval data provenance, evaluation results, and a human-oversight path. EU-region hosting is the default.
How do you evaluate retrieval quality over time?+
A graded evaluation set of 150 to 300 real tickets is built with your senior agents during the pilot, and grows every month. We run the full set weekly and report precision, recall, citation accuracy, refusal rate, and hallucination rate per source domain. Regressions are triaged on the same two-week cadence as feature work, and the eval set is versioned alongside the pipeline.
Who is Deploris and why should we trust you to run our support knowledge system?+
Deploris is a US-registered engineering firm (Colorado LLC 20268259375) with a DACH delivery team, built as the mid-market answer to the gap between dev shops that write software and MSPs that run infrastructure. Of 40 mid-market firms benchmarked across the US and DACH, we are the only team that covers both halves under one contract. The person on your on-call escalation is the same person who wrote the module that paged.
