AI & Data
The full domain, and the other capabilities within it.
Enterprise AI & RAG
Answers grounded in your own documents, with citations and the permissions those documents already carry.
What this is
Retrieval-augmented generation (RAG) puts your content in front of a language model at question time instead of training it in. A pipeline ingests documents, splits them into passages, embeds them into a vector store, retrieves what matches a question, and asks the model to answer from those passages with citations.
Retrieval quality, not model choice, decides most enterprise AI outcomes. When an assistant gives a wrong answer, the cause is nearly always that the correct passage was never retrieved: poor chunking, a missing document, a stale index, or a question the embedding does not match. Teams spend months trialling larger models when the fix was in the ingestion pipeline.
When you need it
If more than one of these is true, this is usually the right place to start.
- Staff cannot find answers that exist somewhere in a document store nobody has curated for years.
- A chatbot pilot returns confident answers your subject-matter experts cannot verify.
- Legal or HR will not approve an assistant because it might surface a document to the wrong employee.
- Answers were acceptable at launch and have quietly drifted as the underlying content changed.
What the scope covers
- Source assessment: which repositories are current, who owns them, and what must be excluded before anything is indexed.
- Document pipeline with parsing, a chunking strategy and embeddings, refreshed incrementally as content changes.
- Retrieval design - hybrid keyword and vector search, re-ranking, and a tuning loop against real questions.
- Permission filtering at retrieval time, so answers inherit the access rules of the source documents.
- An evaluation set of real questions with reviewed answers, used to measure the system before and after every change.
What you receive
| Deliverable | What it contains |
|---|---|
| Content and access audit | A written view of which sources are fit to index, who owns each one, and where document permissions are broken today. |
| Ingestion and index pipeline | Parsing, chunking, embedding and incremental refresh, with a documented path for adding a new source later. |
| Retrieval and answer service | Hybrid retrieval with re-ranking, permission filtering, and answers that cite the passage they were drawn from. |
| Evaluation set and review loop | A question set agreed with your experts, scored on retrieval and on answer quality, and re-run on every change. |
Reference architecture
A reference, not a template. Your estate decides which parts apply and in what order they arrive.
How success is measured
Targets are agreed with you before the work starts, and reported against for its duration.
- Answer accuracy against a held-out question set agreed with your subject-matter experts.
- Retrieval hit rate: how often the passage containing the answer appears in the retrieved context at all.
- Citation coverage - the share of answers pointing to a source passage a reviewer can open and verify.
Questions we are asked
Do we need to fine-tune a model on our data?
Usually not. Fine-tuning teaches style and format; it is a poor way to teach facts, and it makes updates expensive because every content change means retraining. Retrieval keeps content outside the model, so a corrected document takes effect on the next index refresh. We would propose fine-tuning only for a narrow formatting or classification need.
Will it leak documents to people who should not see them?
Only if you let it. A model inherits the permissions of its retrieval layer: if the index holds a document and the filter does not apply the source system access rules, anyone who can ask a question can reach it. Document permissions must be solved before a demo becomes production, and in most organisations that audit uncovers pre-existing over-sharing that has nothing to do with AI.
Why does it still get things wrong?
Usually because retrieval missed. Before blaming the model, check whether the answer passage was in the retrieved context at all; if it was not, no model can produce a correct answer. Most of the remainder comes from contradictory source documents, which is a content governance problem the assistant makes visible rather than causes.
Can it work in Arabic and English?
Yes, with deliberate design. A mixed-language corpus needs an embedding model evaluated on both languages, and asking in Arabic against English documents needs cross-lingual retrieval to be tested rather than assumed. We build the evaluation set in both languages for exactly this reason.
Where do the models run?
That is your choice, and we set out the trade-off. A hosted API is faster to launch; a model in your own cloud tenancy or on-premises keeps content inside your boundary at a higher operating cost. Data residency, sector regulation and the sensitivity of the indexed content usually decide it.
How long before staff can actually use it?
A working pilot on one well-owned content source is a matter of weeks. Broad rollout takes longer, and the time goes into content cleanup, permission alignment and evaluation rather than model work. A plan that skips those steps is buying a demo, not a system.
Continue reading
Computer Vision
Vision models on your camera and sensor feeds: annotation, edge inference, confidence thresholds, human review and drift monitoring after go-live.
Predictive Analytics
Forecasting and risk scoring on your own history, with point-in-time features, honest backtesting, drift monitoring and a benchmark against the simple method.
Start with an assessment
The fastest way to a useful answer is a short, scoped look at what you already have.