RAG & Knowledge Assistants
An AI assistant that answers from your own documents — and shows where the answer came from.
Manuals, wiki, contracts, tickets, product data. Indexed with the same access rules as the originals, kept in sync, available on your website, in Teams, Slack or the intranet.
KNOWLEDGE ASSISTANTS, BUILT PROPERLY
Your company already knows the answer. It is just hard to find.
Retrieval-augmented generation (RAG): search first, then let the model answer only from what was found.
Procedures live in a wiki nobody updates, product details in a PIM export, the real fixes in old support tickets, and the contract clause in a PDF on a shared drive. People ask colleagues instead, support answers the same question for the tenth time, and new hires take months to find their way. A general chatbot does not help here: it does not know your documents, and when it does not know, it guesses.
A knowledge assistant built on RAG works differently. Your content is indexed in a search layer you own; for every question the system retrieves the most relevant passages, checks that the user is allowed to see them, and the language model writes an answer from those passages only, with links to the sources. Our team has been building production software since 2013, and we treat this as a software and data project, not as a prompt. If you need the assistant to also take actions, not only answer, see our work on AI agents.
Ingestion and search
Connectors for files, wikis, ticketing and databases. Clean parsing, sensible chunking, embeddings, and hybrid search that combines vectors with keywords, so part codes and names are found too.
Permissions and citations
Each user only gets answers from documents they can already open. Every answer cites its sources, so people can check it in one click instead of trusting it blindly.
Evaluation and operation
A test set of real questions, measured before launch and after every change. Sync, monitoring and hosting on your servers or on our own cloud network (AS56951).- Source inventory and a question set agreed with your team
- Connectors for files, SharePoint, Confluence, tickets and databases
- Parsing, chunking and metadata tuned to your documents
- Vector and hybrid search, for example PostgreSQL with pgvector
- Permission-aware retrieval tied to your existing identities
- Answers with citations and an honest “I could not find this”
- Chat on your website, in Teams, Slack or the intranet, plus an API
- Incremental sync, re-indexing and deletion handling
- Evaluation suite, feedback loop and quality dashboard
- Cloud API models or private deployment on our GPU cloud
HOW WE WORK
From scattered documents to a trusted assistant
Small pilot first, measured on your own questions, then scale.
Pick the use case
Who asks, what they ask, and where the answers live today. We collect real questions from support, sales or operations and agree what a good answer looks like.
Map sources and access
We list the systems, formats, owners and permission models, and flag content that is outdated, duplicated or must stay out of the index.
Build the pipeline
Ingestion, chunking, embeddings, hybrid search and re-ranking, with access filters applied at query time, not after the answer is written.
Evaluate and tune
We score retrieval and answers on the question set: right sources found, answer supported by them, correct refusals. Then we tune chunking, search and prompts.
Pilot with real users
A limited group uses it where they already work: website, Teams, Slack or intranet. Feedback on each answer goes straight back into the evaluation set.
Operate and extend
Sync, monitoring, cost tracking and regular quality reports. New sources and teams are added once the first use case holds up.STACK AND RISKS
What is under the hood, and what we watch for
Most RAG problems are data and search problems, not model problems.
We choose components for your constraints rather than for fashion. Typical building blocks: PostgreSQL with pgvector or a dedicated vector database for the index, full-text search alongside it for hybrid retrieval, a re-ranking step, and models from OpenAI or Anthropic Claude, or open-weight models such as Llama, Mistral or Qwen served with vLLM. Orchestration is plain, testable code, with frameworks such as LangGraph where a multi-step flow needs them. Scanned files and complex forms often need extraction first; that is where document AI comes in, and structured sources such as ERP or product data usually go through a proper data pipeline before they reach the index.
Wrong or invented answers. The model answers only from retrieved passages, cites them, and is allowed to say it does not know. We track groundedness and correct refusals as metrics, and you can read more about how we test this on the AI testing and evaluation page.
Data leaking across roles. Access rules are stored with every chunk and enforced inside the search query. We test it explicitly with users from different groups before anyone outside the project sees the assistant.
Stale content. Sync jobs, deletion handling and visible source dates keep answers tied to the current version of a document, not to last year’s.
Prompt injection and sensitive data. Retrieved text is treated as data, not instructions; we filter what goes into the index and log what comes out. When documents must not leave your premises, we run the whole stack as private AI on dedicated servers or on our GPU cloud in Romania.
FAQ
Questions we hear before a RAG project
Will the assistant make things up?
Any language model can produce a wrong answer, so we design against it rather than hope. The assistant is instructed to answer only from the retrieved passages, to cite them, and to say so when the sources do not contain the answer. We measure groundedness on a test set of real questions before launch and keep measuring after it.
Can different users see different answers?
Yes, and for most companies this is a requirement. Every chunk keeps the access rules of its source document, and the search filters on the identity of the person asking. Someone from sales will not get passages from an HR folder they cannot open in the original system.
Does our data have to leave our infrastructure?
No. We can use commercial model APIs where your policy allows it, or run open-weight models and the vector database on dedicated servers or on our own GPU cloud in Romania, so documents, embeddings and prompts stay inside an environment you control.
How does the assistant stay up to date?
Connectors sync changes from the source systems on a schedule or through webhooks. New and edited documents are re-indexed, deleted ones are removed from the index, and permission changes are picked up as well. Each answer can show the date of the source it used.
How do we start, and how is it priced?
Usually with a pilot on one document collection and one group of users, with a question set agreed upfront. Pricing depends on scope, sources and hosting; we can work on a fixed scope, a monthly team or a value-based model. See our engagement models.
Have the documents? Let us make them answer.
Tell us which documents and which questions matter most, and we will tell you honestly what a first pilot would look like.