Capabilities
Knowledge assistants
What it is
A knowledge assistant is a conversational interface over your curated content and live systems. It retrieves relevant passages, applies your business rules and returns an answer with sources attached. It is not a general-purpose chatbot trained on the public internet.
The assistant sits inside the channels people already use: intranet, service portal, CRM sidebar or product help. It reads from document stores, wikis, ticket history and structured catalogues. When the corpus does not support an answer, it says so and routes to a human or a form — it does not invent policy.
Core components
- Ingestion and chunking tuned to your document types — policies, manuals, FAQs, release notes.
- Hybrid retrieval: semantic search plus metadata filters for region, product line and role.
- Permission-aware answers so a warehouse user never sees executive compensation guidance.
- Citation links back to source pages or document versions, not opaque paraphrase.
- Feedback capture: thumbs, reasons and optional correction workflows for content owners.
- Evaluation sets built from real historical questions, rerun on every model or prompt change.
When it pays back
Payback is fastest when repeat questions consume skilled time: HR policy, IT support tier zero, product specification, compliance interpretation, dealer enablement. If your teams answer the same questions weekly from static documents, a grounded assistant returns hours quickly.
It also pays back when wrong self-service answers create risk: mis-stated warranty terms, outdated safety procedures, incorrect tax guidance. Citations and version-aware retrieval reduce silent error. Measure deflection of live chats, time-to-answer for internal tickets and content gaps surfaced by failed queries.
Signals you are ready
- You have authoritative sources, even if scattered — not everything in one perfect CMS.
- Subject-matter experts can spend a few hours validating answers during build.
- You know which user groups and regions need different corpora.
- Leadership accepts that some questions must escalate instead of being guessed.
How Incubics engineers it
We follow Perceive, Engineer, Deliver, Run. Discovery is two weeks. First production release by week twelve.
Perceive — weeks 1–2
We inventory sources, access models and top question types from tickets, chat logs and interviews. We score retrieval difficulty: scanned PDFs, tables, multi-language content, frequent updates. Output: corpus plan, evaluation question set, architecture sketch and fixed-price proposal.
Engineer — weeks 3–10
We build ingestion pipelines, embedding strategy and retrieval with reranking. We design prompts and refusal behaviour, wire authentication and channel adapters, and run weekly evals against your golden questions. Security review covers prompt injection and data exfiltration paths.
Deliver — by week 12
Production release in at least one channel with monitoring, admin tools for content owners and a runbook. Users trained on when to trust citations and how to flag bad answers. Documentation covers data residency and retention.
Run — ongoing
Managed operations: drift checks when sources change, regression evals after model upgrades, cost dashboards and quarterly roadmap for new corpora and locales. You can take operations in-house; artefacts and infrastructure are yours.
Failure modes
Most failures are operational, not model-related. Stale content makes correct retrieval useless — owners must know when to reindex. Over-broad corpora mix conflicting policies; metadata and scope filters matter. Assistants without escalation frustrate users when confidence is low.
- Treating the assistant as search with fluff — no citations, no version control.
- Skipping permission mapping — answers leak across departments.
- Optimising for fluency scores instead of factual accuracy on your eval set.
- No owner for content freshness after launch.
- Letting users believe the model is authoritative when retrieval returned nothing.
What you get
- Solution design and channel integration for the first production surface.
- Ingestion pipelines and retrieval configuration with reranking.
- Prompt and policy layer with refusal and escalation rules.
- Evaluation harness with golden questions and regression gates.
- Admin experience for feedback and content gap reporting.
- Monitoring for latency, cost, retrieval quality and user satisfaction.
- Runbook and optional managed run.
What we refuse to ship
We do not ship a demo that answers from a dumped folder without access control, evals or a plan for updates. We do not ship assistants that cannot show sources. We do not ship without an identified business owner for corpus quality.
Do we need a perfect knowledge base first?
No. We start with the sources that answer the highest-volume questions and expand. Discovery identifies what must be cleaned versus what can ship with metadata and scope limits.
Can one assistant serve customers and employees?
Often yes, with separate corpora and permissions. We design one platform with scoped experiences rather than two disconnected bots.
Which models do you use?
Whatever passes your evaluation on accuracy, latency and cost — frontier or open-weight. Model choice is an engineering decision documented in discovery, not a brand choice.
How do you handle wrong answers?
Citations let users verify. Feedback flows to content owners. Eval suites catch regressions before release. High-risk topics get stricter retrieval thresholds or mandatory human review.
What if our documents are mostly PDF scans?
We plan OCR and layout-aware parsing in discovery. Heavy scan workloads may shift the first release scope to structured FAQs while longer documents are processed in a second increment.
Next step
Start with two weeks.
A fixed-fee discovery gives you a ranked use-case portfolio, a target architecture, a cost model and a build proposal you can take to your board. If we don't find a case worth building, we tell you.