A working AI application combines a model, data, an interface, access rules and a way to verify the result. Connecting an API solves only part of the task. An answer may look convincing while referring to an old instruction, disclosing someone else’s document or suggesting an action the user is not allowed to perform.
The ten diagrams below explain the main areas of AI engineering, from model types to application operation. Read them as a concept map. Some categories overlap, and individual arrows represent possible choices rather than a mandatory development sequence.
For a practical discussion, consider an educational example: a CMS documentation assistant. An employee asks how to publish a page, configure a role or restore a backup. The system should find current instructions, account for the employee’s permissions and show a verifiable answer. This is a design example, not a claim about an implemented product or results achieved by DDRW.
1. Model types: the task first, the tool second
Compare models along several independent dimensions. One describes input data: text, images, audio or a combination. Another describes the expected result: classification, retrieval, generation or recognition. A third describes the available usage model: an external API or self-hosting.
A language model can prepare an answer, an embedding model can represent a query and document as vectors for search, and a reranker can reorder retrieved excerpts by relevance to a question. These are different roles; a large generative model does not have to perform them all.
Categories can overlap. A multimodal model may also be generative and process text. Available model weights do not necessarily permit every commercial use: licenses, usage restrictions and distribution terms require separate checking.
For our assistant, choosing retrieval and text-generation methods is initially enough. Image recognition becomes necessary if important instructions exist only in screenshots. Collect real questions and sample documents before choosing: they reveal which capabilities are actually needed.
Compare candidates on the same tasks: answer correctness, Russian-language quality, output format, latency, cost and whether the data may be processed. Do not choose solely by parameter count or a general leaderboard ranking: neither fully describes the specific CMS scenario.
2. Architectures: not every block belongs to the same level
Transformer describes the organization of neural computation using attention. Encoders, decoders and their combinations define different ways to process sequences. For an application team, this affects suitability for a task, available interfaces and deployment requirements.
MoE, or mixture of experts, can describe individual layers inside a model. “Transformer or MoE” is therefore not always a valid choice: a Transformer can use expert blocks. The total parameter count and computation required for one request are also different quantities.
State space models, or SSMs, concern sequence modeling. The Mamba research, for example, proposes selective state propagation mechanisms. This is a distinct direction, not simply another name for attention. Mamba research.
3D Gaussian Splatting occupies a different level of the map: it is a representation and a method for optimizing and rendering a three-dimensional scene using Gaussian primitives. Placing it directly alongside a language architecture without explaining the task is misleading. 3D Gaussian Splatting research.
When selecting a ready model for documentation, you do not need to design an architecture yourself. Checking its behavior and limitations in the application matters more. Architectural understanding helps you ask providers the right questions and avoid comparing solutions intended for different tasks.
3. Reasoning: additional computation still needs result checks
Reasoning usually means working through a task using intermediate steps: analyzing conditions, choosing an action and checking an option. This can be useful when an answer requires comparing several instructions. Additional processing time does not itself prove correctness, however.
Chain of Thought describes intermediate textual steps. In an application API, access to them depends on the model and provider. OpenAI, for example, describes internal reasoning tokens that are not shown directly to users, and available summaries separately. Reasoning documentation.
Even a detailed explanation of an answer should not be treated as an exact log of internal computation. Auditing needs observable evidence: documents used, tools called, supplied parameters and the result of external verification.
“How do I publish a page?” usually does not require a complex multistep system. Finding the appropriate instruction is enough. A question about a draft differing from the published version may require clarifying the role and CMS version, then comparing several sections.
Set time and computation limits. If the task cannot be resolved within the budget, the assistant returns what it found, identifies uncertainty or offers to contact an administrator. For numerical calculations, a verifiable tool is preferable to a long textual model rationale.
4. RAG: bringing retrieved information into context
RAG connects retrieval of external materials with answer generation. In a typical application, the system retrieves excerpts, supplies them to the model and asks for an answer grounded in those sources. Passing documents into context does not change model weights. The historical RAG research also considers component training, so the term is broader than a single integration template. Retrieval-Augmented Generation research.
The practical process begins before a query. Documents must be extracted from sources, cleaned of technical noise, divided into meaningful excerpts and supplied with metadata: URL, title, version, date and access rules.
Hybrid search is useful for a CMS. Exact field names and error codes suit word-based search; semantic questions suit vector representations. Results can then be reranked and a limited set of excerpts selected for the answer.
Apply permissions before sending materials to the model. Asking an assistant “not to show secret documents” is insufficient: a restricted excerpt must never enter its available context. The same restrictions apply to headings, snippets and caches.
RAG does not guarantee truth. Search can retrieve an outdated page, miss the right one or return conflicting versions. Answers therefore need links to the sections used, and the system needs index update and deletion rules. Without evidence, clarifying the CMS version or saying the instruction was not found is more useful than filling the gap with a guess.
5. Agents, MCP and A2A: separate connection from authority
An agentic approach is useful when the model not only formulates an answer but chooses subsequent actions. For example: finding an instruction, clarifying parameters, requesting a page’s state and preparing a proposed fix. The loop needs an explicit stopping condition.
MCP standardizes connections to tools and context sources. A2A describes interaction between independent agents: capability discovery, task transfer and results. The protocols complement each other, but do not replace server-side authorization. The A2A specification explicitly explains this distinction.
For a CMS assistant, start with an allowlist of tools: documentation search and reading states accessible to the user. Arbitrary SQL, server command execution and a universal HTTP client are excessive for this scenario.
Each tool receives typed parameters, a bounded response and a verified user context. A user identifier must not come from arbitrary text proposed by the model. Publishing or changing access needs separate authorization and, where required, human confirmation.
Set budgets for steps, time, tokens and costs. Retrying after a network failure must not publish a page or send an email again: mutations need idempotency or another safe-retry mechanism.
Multiple agents make sense when tasks are genuinely separable. For finding one instruction, an extra intermediary usually complicates logging and error handling. Start by testing a simple controlled process, then add autonomy where it brings measurable value.
6. Training: a separate decision after testing the basic approach
Pretraining builds a model’s foundational capabilities using a large corpus. SFT, training on examples of inputs and desired answers, helps adapt behavior to a task. For a company with CMS documentation, training from scratch is usually not the first step: first test a ready model, instructions and retrieval.
PEFT groups adaptation methods that change a relatively small share of parameters. LoRA belongs to this family: base weights are frozen while additional low-rank matrices are trained. LoRA and PEFT should therefore not be presented as unrelated alternatives. LoRA research.
RLHF with a learned reward model and subsequent optimization, and DPO, are different approaches to using preferences. DPO is not a mandatory next step after RLHF: its research proposes another way to optimize against preferences. DPO research.
If a model regularly violates the required format despite good examples, fine-tuning may justify a separate experiment. If it does not know today’s instruction, check retrieval freshness first: training does not replace an updatable document database.
Keep training examples separate from evaluation examples. Check data provenance, permissions and the absence of secrets. After adaptation, evaluate the target task as well as possible degradation in other required capabilities.
The training diagram’s mention of vLLM needs qualification: it can generate examples, or rollouts, within a process managed by a separate trainer. It is not a universal replacement for a training tool.
7. Inference: serving requests with predictable limits
Inference applies a model that has already been prepared. Self-hosting requires managing device memory, concurrent requests and queues. An external API removes some infrastructure work but leaves rate limits, network errors and cost control.
vLLM is primarily designed for generation and model serving. Combined with training libraries, responsibilities are separate: a trainer updates weights, while the server generates responses. This is illustrated in the vLLM integration documentation for TRL.
A KV cache stores attention keys and values so already processed positions do not need to be recalculated during generation. It is computational memory, not a verified fact database, user permission history or a way to teach the model new information.
Quantization reduces numeric representations and may reduce memory requirements. Batching improves serving efficiency but can increase an individual request’s wait. Test every optimization on your own examples: reduced memory usage must not conceal an unacceptable quality change.
For the documentation assistant, observe retrieval time, model wait and answer preparation separately. Limit context and output length, and provide timeouts and cancellation. Cached answers account for document versions and access scope; the same question from different employees does not imply the same right to data.
8. Evaluation and security: test the system in parts
Editorial note: the original Russian diagram labels MRR inaccurately. The metric averages the reciprocal rank of the first relevant result, rather than the rank itself. The English diagram corrects this label.
Start evaluation with a set of tasks and expected behavior. For a CMS, include ordinary questions, ambiguous wording, missing instructions, outdated documents and requests for another user’s data. A single convincing conversation does not test these situations.
Measure retrieval and generation separately. In retrieval, precision@k is the proportion of relevant results among the first k; recall@k is the proportion of all known relevant documents for a query found in those results. Calculation needs a labeled dataset and agreement on relevance. Precision and recall definitions.
MRR averages the reciprocal rank of the first relevant result across queries. For one query, this is 1/r, where r is the position of the first suitable document; if none is found in the evaluated results, the contribution is zero. MRR does not measure the completeness of all retrieved information. The first-relevant-result mechanism is visible in TorchMetrics’ reciprocal rank implementation.
For answers, check consistency with sources, completeness of required steps, correct refusals and useful links. Another model can assist as a judge, but disputed cases and criteria need human review.
A document can contain malicious instructions. The application must treat retrieved text as data, without giving it authority to change rules or call tools. Supplement this with action limits, authorization checks and safe output rendering.
Run every model, instruction or retrieval change through the saved evaluation set. Add new failures as regression examples. Separately verify that restricted information does not enter answers, technical logs or caches.
9. Foundations: data, mathematics and ordinary software development
Integrating a ready model does not require first becoming a researcher in every neural architecture. Understanding vectors, similarity, probabilistic output and the limits of statistical evaluation is useful, however. It helps distinguish confident text from a substantiated statement.
Ordinary development skills are needed too: HTTP, data storage, queues, timeouts, access control, observability and configuration management. An application remains a software system even when a model proposes part of its result.
Data discipline is especially important for CMS documentation. An instruction needs an owner, version and scope. Deleting a document must affect the search index; changing permissions must affect excerpt and cache availability. Do not expect the model to reconstruct these rules from filenames.
Start design with access rules and anonymized examples. Then decide which materials may go to an external provider, how long queries are retained and who can see logs. Infrastructure secrets do not become training data merely because a useful instruction sits beside them.
Separate team responsibilities: the editor owns content, the developer owns the application and integrations, the administrator owns access and operation, and the product owner defines usefulness criteria. One person can combine roles, but the obligations must remain clear.
10. AI application architecture: assemble a verifiable user journey
The first assistant version can use a sequential process: the interface accepts a question, the server checks the session and limits, retrieval selects permitted excerpts, the model forms an answer, and the application returns text and sources. Errors at every stage need a clear state for users.
A separate task builds the index from trusted documents with metadata and permissions. A content change triggers an update, and missing access excludes a document from results. If the index lags, the system must account for that limitation rather than presenting an outdated result as a current instruction.
An execution log benefits from a request identifier, configuration versions, sources used, tool calls, latencies and costs. Full personal information and secrets are not required for this. Access to details is restricted separately.
Release a new version with a limited scenario and the ability to disable a problematic component. If generation fails, the interface can offer retrieved instructions and ordinary search. If authorization checking is unavailable, a safe answer must not include restricted materials.
A practical pre-launch checklist
- One task and the user action to be completed are defined.
- Current documents have owners, versions and permissions.
- An evaluation set covers retrieval, answers, refusals and attempts to obtain another user’s data.
- Tools are allowlisted; mutations are checked by the server.
- Budgets, timeouts and safe-retry rules are set.
- Caches and logs account for confidentiality, and updates undergo regression evaluation.
- Users see sources and can continue working if the assistant fails.
Frequently asked questions
Do we need to fine-tune the model immediately? No. First test the task using a ready model, good instructions and current retrieval. Fine-tuning needs a separate justification and evaluation data.
RAG or an agent? RAG helps use retrieved materials; an agent loop chooses actions. They can be combined, but a reference assistant often needs only retrieval and one answer.
How do we know the application is ready? Through scenarios and limits agreed in advance: answers are grounded in sources, permissions are respected, errors are clear and costs are controlled. A demonstration conversation does not replace these conditions.
Start with a small, verifiable journey from a question to a useful result. Further complexity is justified by a specific problem found through operating and evaluating the system.
