Services
Not a search that returns ten links, but an AI agent that decides where to look for the answer: it rephrases the query, opens the right page, looks at the drawing — and answers with a link to the source. And if the documents don't contain the answer, it says so.
01 — The problem
Keyword search finds a document, but a person needs an answer. An employee asks "how tight should the flange be", while the procedure says "tightening torque for flanged joint fasteners" — not a single word matches, and the search returns nothing or a hundred irrelevant pages.
The second problem is more serious: much of a company's knowledge isn't stored as text at all. It lives in drawings, wiring diagrams, interface screenshots and tables embedded as images. For full-text search, such pages are empty.
And the third, which makes simple solutions fall apart on real documents: you can't know in advance how much has to be read to answer. One question needs a paragraph, another needs a table twenty pages later, a third needs a look at a drawing. A fixed workflow can't cover that.
02 — Approach
Classic RAG works in a single pass: find similar passages, hand them to the model, get an answer. It is cheap and works well on a simple knowledge base. On technical documentation it breaks: the wrong passages are found, the answer is in a picture, the needed table isn't in the results at all — and the scheme has no second attempt.
Classic RAG
Agent over documents
The price is query time and cost: the agent goes to the index several times instead of once. That's why it is designed with limits, otherwise it would search forever. Keeping a typical question within a reasonable time is the main engineering work in such a project.
03 — How it works
/01
The first query is almost never ideal: an employee asks in their own words, while the document names the same things differently, often in another language. The agent looks at what it found and queries the index again until it reaches the right place.
/02
If a passage is enough to answer, it answers right away. If not, it takes the whole page or the neighbouring ones. If the answer depends on a picture, it opens the picture. The agent makes this decision itself, not a fixed workflow.
/03
When the answer depends on what exactly is shown — which elements are highlighted, where a line goes, which dimension is marked on a drawing — the agent opens the figure itself and answers from it, not from its caption.
/04
Every statement comes with a link to the document, page and figure. If the documents don't contain the answer, the agent says so and lists what it searched for. A refusal is a correct answer, not a failure.
04 — Scope
05 — The difference
Most document systems work with text only. Our agent also reads images: which modules on a board are highlighted, which terminal block a sensor is connected to, in what order elements sit on a panel, which dimension is marked on a drawing.
A figure first has to be found by the meaning of the question and then read as an image — these are two different tasks, and both are solved. The answer keeps a link to the specific figure: the engineer sees the original source, not a paraphrase.
For technical documentation this often decides the outcome: in equipment manuals, a significant share of answers exists only in graphics.
06 — Applications
Equipment manuals, diagrams, drawings. An engineer asks in their own language and gets an answer with a page link instead of scrolling through a thousand-page PDF.
Employees find out what to do without distracting colleagues. This is especially noticeable where procedures change faster than people can reread them.
An agent gets a ready answer with a source instead of searching through ten articles. The same index can also power automatic replies to customers.
Search across terms, deadlines and obligations in hundreds of contracts — always with a link to the clause, because a lawyer needs the original source.
Estimates, specifications and project correspondence in a single search. The answer to "why did we decide this" no longer depends on one person's memory.
Newcomers ask the agent instead of a senior colleague. A side effect: you see what people ask most often and what is worth rewriting in the documentation.
07 — Industries
The method doesn't depend on the industry: the documents and vocabulary change, not the approach. What makes a document set hard is not the subject but the form — scans, drawings, tables as images, dozens of versions of the same procedure.
Schematics, datasheets, technical specifications, assembly and calibration manuals. The answer is most often in a diagram rather than the text — exactly the case the agent's ability to read images is built for.
Equipment instructions, standard operating procedures, regulations and registration dossiers. Linking to the original source is not a wish here but a condition of the work.
Standards, substation diagrams, switching procedures, equipment data sheets. The documents are large, versions change, and the cost of a wrong answer is high.
Design documentation, codes of practice, drawings and specifications. A single question often requires combining data from a drawing and the text.
Repair manuals, parts catalogues, manufacturer bulletins. A mechanic needs a part number and a page, not a paraphrase.
Process sheets, equipment manuals, occupational safety instructions. This is where our measured case comes from — CNC machine documentation.
08 — Data
If the documents contain trade secrets, personal data or engineering documentation, we deploy the agent on your server: the model, the index and the database stay inside your perimeter, and no request leaves it. This is a standard delivery option, not an exception. It also simplifies working with personal data under the GDPR: if the data never leaves your infrastructure, no external AI provider processes it.
Cloud models are cheaper to start with and stronger on complex phrasing, so for non-confidential data we often start with them. The choice is made once, at the pilot stage, and not revisited later: both the choice of models and the hardware requirements depend on it.
09 — Proof
For an industrial holding, we built CNC-RAG from scratch — an agent that answers questions about a library of technical documentation for computer numerical control machines. An engineer asks a question in Russian, the agent searches manuals in English, opens a drawing when needed and backs up the answer with links to the document, page and figure.
The library holds more than a hundred manuals and over 53,000 pages. A significant share of the answers exists only in drawings and diagrams, so working with images was not an add-on but the foundation of the project.
We measured quality on a set of 311 questions with reference answers fixed in advance: 94.5% correct. We separately tested questions that the documents don't answer — the agent must decline, and it does. The whole stack fits on a single GPU. An answer usually takes 30–60 seconds, up to several minutes for complex questions, and all that time you can see what the agent is doing.
More about the project10 — How we work
Week 1
We look at what the documents are, what state they are in and what questions people ask about them. Together with your specialists, we build the first test question set.
Weeks 2–4
We build a working agent on part of the document set and show the numbers on the test set. By the end of this stage, it is clear whether the approach works on your data.
Months 2–3
The full document set, interface, access rights, integrations, regular index updates, deployment on your infrastructure.
After that
New documents, new types of questions, quality re-measured after every change. A system that isn't maintained goes out of date along with the documents.
11 — Budget
We give an estimate after reviewing the documents: without knowing what state they are in, any number would be made up.
12 — Questions
Plain RAG works in a single pass: find similar passages, hand them to the model, get an answer. An agent works in a loop: it looks at what it found and decides what to do next — rephrase the query, take the whole page, open a drawing, or admit that the documents don't contain the answer. On a simple knowledge base the difference is barely visible; on technical documentation it decides the outcome, because the answer is often not in the first passage found but on a diagram twenty pages later. The price is query time and cost, so such systems are designed with limits.
Fine-tuning changes the model itself and is expensive: you need a labelled dataset, GPUs, and a repeat of the procedure every time the documents change. RAG leaves the model as it is and feeds it the relevant passages at question time. When a document changes, you re-index it; nothing has to be retrained. For company knowledge that changes every week, this is the only practical option.
There is no lower limit on the number of documents; what matters more is how much time staff spend searching and how costly a mistake is. If five people spend twenty minutes a day looking for answers in procedures, it pays off even on a hundred documents. The upper limit is practically open: in our machine-tool documentation project, the system works over a library of more than a hundred manuals and 53,000 pages.
Yes, this is a standard delivery option. The model, the database and the index live on your server, and no request leaves it. Companies choose this when documents contain trade secrets, engineering documentation or personal data — in the last case, keeping everything in-house also means no third-party AI provider processes that data, which simplifies the GDPR assessment. The whole stack of one of our projects fits on a single GPU; you don't need a data centre for it.
The system must say there is no answer instead of making one up. This is a separate part of the work: we build a set of questions that the documents definitely don't answer and check that the system declines. A refusal at the right moment is as measurable a result as a correct answer.
Before development, we build a set of questions with correct answers fixed in advance — usually several hundred, together with your engineers or subject-matter experts. After that, every change to the system is run against the whole set, and you can see whether it got better or worse. Without such a set, "it got better" remains a matter of taste.
A pilot on your documents takes three to four weeks: document analysis, building the index, the test question set and first measurements. A production version with integrations, access rights and regular index updates takes two months or more. Exact timelines depend on the state your documents are in.
That is exactly our specialty. Much of the useful information in technical documentation is not in the text but in drawings, wiring diagrams, interface screenshots and tables embedded as images. We build search that finds answers there too and links to the specific figure and page.
It's enough to describe what the documents are and what questions people ask about them. That already shows whether you need an agent or a simpler solution will do. If the task isn't about document search, we'll say so.
The first step is a free consultation: a call of up to 30 minutes with the company's founder. You don't need a ready specification for it.