Core technology
All three solutions are built on the same set of technologies. This page explains what each one is, why we chose it, and which solutions use it.
How we choose technology
We select technology against three constraints and discard anything that fails them. One, it must run entirely on hardware installed on site — no dependency on public AI services. Two, every answer must trace back to a source document, which forces a retrieval step into the architecture rather than letting the model answer from memory. Three, there must be a place to insert a human review gate before a result becomes official. Those three constraints explain almost every technical choice below.
Nine core technologies
These are the shared building blocks. Each solution is a different arrangement of the same pieces.
Local language models
01Local LLM
A large language model installed and running on a GPU server at your premises, rather than called over the Internet as an external service.
Why we use it: This is the root decision everything else follows from. In exchange for investing in GPUs, you get something no cloud service can offer: documents never leave the server room, and the system works with no Internet connection at all.
Retrieval-augmented generation
02RAG
Instead of letting the model answer from what it learned during training, the system finds the relevant passages in your own repository, hands them to the model, and asks it to answer from those passages only.
Why we use it: This is why every answer can name a document and a page. It is also how we control fabrication: when no passage provides sufficient grounds, the system says so rather than inventing something.
Embeddings and semantic search
03Embedding & Vector search
Each passage is converted into a numeric vector representing its meaning. The question is converted the same way, and the system finds the passages closest in meaning.
Why we use it: Keyword search only works when you type the exact words. Semantic search means asking about "support for poor households" still finds a document written as "allowance for households in difficult circumstances" — which is how administrative documents usually phrase it.
Document chunking
04Chunking
Long documents are split into reasonably sized passages along their structure — by article, clause and section — never mid-sentence or mid-table.
Why we use it: Good chunking finds the right passage and cites the right page. Sloppy chunking produces correct answers with citations pointing at the wrong place, and officers lose trust the first time they check.
Reranking
05Reranking
After retrieving a few dozen seemingly relevant passages, a second model rescores each one against the question and keeps only the best few for the main model.
Why we use it: Feeding in too many passages adds noise and skews the answer. Reranking costs a little time but noticeably improves accuracy, especially on large archives.
Optical character recognition
06OCR
Converts photographs and scans into machine-readable text, including Vietnamese diacritics and tables.
Why we use it: Most of a government archive is still paper or image-only scans. Without this step, everything downstream has nothing to work with. The system scores confidence per page and flags uncertain pages for an officer to re-check.
Speech recognition
07ASR — Automatic Speech Recognition
Converts speech to text, separates speakers and timestamps each passage.
Why we use it: Meeting content is often more sensitive than written documents, so the recognition model also runs on your own servers. With timestamps, re-listening to one specific passage takes seconds instead of scrubbing the whole recording.
Tool calling and agents
08Tool calling & Agent
The model does not just produce text; it can call functions the system exposes — query a database, read a file, write a note, create a task.
Why we use it: This is what turns a model from "a chatbot that answers" into "an assistant that works". It is also the most dangerous surface, so every function that can change data passes through a user confirmation gate.
Grounding and guardrails
09Grounding & Guardrails
The set of constraints forcing the model to answer only within the documents supplied, always with citations, and never letting a result become an official document without human approval.
Why we use it: Without this layer, the better the model the more dangerous it is: it writes a wrong sentence very convincingly, and nobody notices until that sentence is already in an issued report.
How the pieces fit together
This is the path data takes, from a sheet of paper going in to an officer receiving a sourced answer.
Loading documents into the store — done once per document, in the background
Ingest
Electronic documents, scans, audio files, photographs, links — all through the same door.
Convert to text
Scans through OCR, audio through speech recognition. Pages read with low confidence are flagged.
Chunk and tag
Split along document structure, tagged with reference number, issuing authority, date and page.
Embed as vectors
Each passage becomes a numeric vector of its meaning, stored beside the original document repository.
Vector store and original document store
Held on the organisation’s own servers, never synced outside
When a question arrives — runs in real time
A staff member asks a question
Retrieve on a question
Find the closest passages in meaning, limited to what the asker is authorised to access.
Rerank
Rescore relevance and keep the best few so the model is not diluted by noise.
The model composes an answer
Answers from exactly the passages supplied, with a pointer to the source of each statement.
An officer verifies
The user checks against the source document before using it. This step is not optional.
An answer with citations to document name and page number
All three solutions follow this same path and differ only at the input and the interface: government agencies feed in documents and meeting minutes, the kiosk feeds in administrative procedure data, and the personal assistant feeds in the user’s own links and notes.
Which technology goes into which solution
No single solution uses everything. This table shows which blocks each product needs.
| Technology | Government AI assistant | Public-service kiosk | Personal knowledge assistant |
|---|---|---|---|
| Local language models | Used — Government AI assistant | Used — Public-service kiosk | Used — Personal knowledge assistant |
| Retrieval-augmented generation (RAG) | Used — Government AI assistant | Not used — Public-service kiosk | Used — Personal knowledge assistant |
| Embeddings and semantic search | Used — Government AI assistant | Used — Public-service kiosk | Used — Personal knowledge assistant |
| Document chunking | Used — Government AI assistant | Not used — Public-service kiosk | Used — Personal knowledge assistant |
| Reranking | Used — Government AI assistant | Not used — Public-service kiosk | Used — Personal knowledge assistant |
| Optical character recognition (OCR) | Used — Government AI assistant | Not used — Public-service kiosk | Used — Personal knowledge assistant |
| Speech recognition (ASR) | Used — Government AI assistant | Used — Public-service kiosk | Used — Personal knowledge assistant |
| Tool calling and agents | Used — Government AI assistant | Not used — Public-service kiosk | Used — Personal knowledge assistant |
| Grounding and guardrails | Used — Government AI assistant | Used — Public-service kiosk | Used — Personal knowledge assistant |
A five-layer architecture
Every solution is built on these same five layers. Responsibilities are separated, so upgrading the AI model does not mean rewriting the interface, and replacing one part does not mean rebuilding the system.
- 01
Interface layer
What users see and interact with — different in each solution.
- Web interface
- Touchscreen kiosk
- Telegram conversation
- Admin console
- 02
Business logic layer
Where work rules are enforced: who may do what, and which steps a process goes through.
- Business rules
- Approval flows
- Permissions
- Action logging
- 03
AI processing layer
Where the nine technologies above actually run.
- Language models
- Embedding and retrieval
- Reranking
- Character and speech recognition
- Tool calling
- 04
Data layer
Where original documents, the vector store, business data and all logs live.
- Original document repository
- Vector store
- Business database
- System audit logs
- 05
Integration layer
The bridge to systems already running, and the import/export gateway.
- API connections
- Database connections
- Word, Excel and PDF import
- Report export
Infrastructure to run it
Running models on site means real hardware. The five components below are functional roles, not necessarily five physical machines — at small scale they can be consolidated.
AI processing server
Runs the language model, embedding model, reranker, character recognition and speech recognition. Requires dedicated GPUs — this component determines response time and is also the most expensive part.
Vector store
Stores and searches the meaning vectors. Needs fast disks and enough memory to hold the index.
Application server
Runs the interface and the business modules. Requires SSD storage and redundant network links.
Document storage
Holds original and digitised documents. Capacity expands as the archive grows.
Backup system
Scheduled backups stored separately from the main system, retaining multiple versions with a tested restore procedure.
Documents never leave
The internet and public AI servicesDetailed hardware specifications are prepared individually based on user numbers, document volume and response-time requirements. We present concrete figures in the technical proposal, after surveying your current situation.
Three deployment scales
There is no single correct configuration. We size against concurrent users, document volume and the availability level required.
Small
A single commune, ward, department, or a personal assistant. Components consolidate onto one or two servers. This is the right scale for a pilot.
Medium
A provincial department or a district authority. The AI processing server is separated out to keep response times acceptable under concurrent use.
Large
Province-wide, or several organisations sharing one platform. Each server group is separated, with redundancy, load balancing and storage that scales with document volume.
Integration capabilities
You have already invested in a document management system, an internal portal and sector databases. We connect into those rather than asking you to replace them.
- Document and operations management systems
- Internal portals
- Task management systems
- Sector-specific databases
- User authentication systems
Integration methods
- API connections
- Authorised database connections
- File synchronisation
- Scheduled data import and export
Extensibility
The system is designed to grow. Adding a department, a document type or a report template is configuration work, not a software rewrite.
- Add further departments and units
- Add new document types
- Add new report templates
- Add sector-specific business processes
- Add new data repositories and integration sources
See it run on your own documents
Every solution sounds good in a description. The only way to know whether this one works for you is to run it against your real documents, templates and workflows. That is exactly the kind of demo we do.
The demo is free and carries no obligation. If it turns out we are not the right fit, we will say so.