3. Retrieval-augmented generation architect

A retrieval-augmented generation (RAG) system for CAE engineering is not a single model but a pipeline of cooperating services. Understanding the architecture means understanding what each component owns, how data moves between them, and where the pipeline must be wired into existing simulation and PLM workflows. This section breaks the architecture into its functional layers, traces a request end to end, and then examines the integration patterns that determine whether the assistant behaves as a helpful engineering tool or an unreliable text generator.

Functional Components

A production RAG stack for CAE decomposes into five layers. Each layer has a distinct responsibility and a distinct failure mode.

• Ingestion and parsing layer. Converts heterogeneous CAE artifacts into normalized text plus metadata. Inputs include solver input decks (.inp, .k, .jou), result summaries, material cards, meshing guidelines, validation reports, and PDF standards. Parsers must preserve structural context: a boundary condition keyword is meaningless without its set definition and the step it belongs to.
• Chunking and enrichment layer. Splits parsed content into retrievable units and attaches metadata. For CAE, chunk boundaries should follow semantic units — a complete keyword block, a material definition, a load case — rather than fixed token windows. Metadata typically includes solver, analysis type, discipline, part or assembly ID, revision, and source document.
• Embedding and indexing layer. Produces vector representations and stores them alongside metadata in a vector database. Hybrid indexes that combine dense vectors with sparse lexical search (BM25) are strongly preferred because CAE queries contain exact identifiers such as *CONTACT_PAIR, MAT1, or STEP-2 that dense embeddings often blur.
• Retrieval and reranking layer. Executes the query, applies metadata filters, retrieves candidate chunks, and reranks them with a cross-encoder or a domain-tuned scoring function. This layer is where precision is won or lost.
• Generation and grounding layer. Assembles the prompt from the user question, retrieved context, and system instructions, then produces an answer with citations. The generator must be constrained to answer only from retrieved evidence and to emit explicit references.

Around these five layers sit two cross-cutting services: an orchestration layer that manages request state, retries, and timeouts, and an observability layer that logs queries, retrieved chunk IDs, scores, and final answers for audit and evaluation.

End-to-End Data Flow

Consider a concrete request: an engineer asks, "Why did STEP-2 of the crash model diverge after 12 ms?" The flow proceeds as follows.

1. Query normalization. The orchestrator extracts entities: STEP-2, crash model, diverge, 12 ms. It maps these to metadata filters — analysis type explicit_dynamics, step ID 2, and a time window.
2. Hybrid retrieval. The dense retriever returns semantically similar chunks (prior divergence post-mortems, contact instability notes). The sparse retriever returns exact matches for STEP-2 and the specific solver message. Results are merged with reciprocal rank fusion.
3. Reranking. A cross-encoder scores each candidate against the full query. The top 5–8 chunks survive. A typical cutoff is a rerank score threshold of 0.35, below which chunks are discarded rather than passed to the generator.
4. Context assembly. Chunks are ordered by relevance and truncated to fit the context window. Each chunk carries its source ID and revision so the generator can cite it.
5. Generation. The model produces an answer such as: "STEP-2 divergence at 12 ms is consistent with contact penetration in the *CONTACT_PAIR definition for the bumper-to-rail interface. The prior incident INC-4471 shows the same signature when the penalty stiffness was left at default. Verify the contact stiffness and the initial gap." Each claim is linked to a chunk ID.
6. Post-processing. The orchestrator validates that every citation resolves to a retrieved chunk. Unresolved citations trigger a regeneration or a fallback response.

The critical property is that the answer is traceable. If the retrieved chunks do not contain evidence for a claim, the system must say so rather than fill the gap from parametric memory.

Integration Patterns for CAE Workflows

How the RAG service connects to the surrounding engineering environment determines its practical value. Four patterns recur in CAE deployments.

The chat-side assistant is the simplest and most common starting point. It indexes documentation, prior tickets, and validation reports, and answers ad hoc questions. Its weakness is that it only knows what was indexed; a solver log generated five minutes ago is invisible unless ingestion is continuous.

The solver-log copilot addresses this by subscribing to the solver's stdout stream. When a new warning or error line appears, the copilot retrieves similar historical log signatures and their resolutions. This pattern requires a log parser that normalizes variable fields (timestamps, node IDs, element IDs) so that two logs with different node numbers but the same failure mode match.

The PLM-embedded advisor hooks into revision checkout events. When an engineer opens a revision, the advisor retrieves linked analysis reports, material cards, and change requests, then surfaces a summary. This pattern depends on reliable metadata linkage between PLM objects and CAE artifacts — a mapping that is often incomplete and must be maintained.

The CI/CD validation gate is the most automated. After a regression suite runs, the gate retrieves baseline results and prior triage notes, then classifies each failure as known or novel. Known failures link to existing tickets; novel failures open new ones with retrieved context attached. This pattern demands high precision because a false "known" classification can suppress a genuine regression.

Grounding and Citation Discipline

The generation layer must enforce three rules. First, answer only from retrieved context; if context is insufficient, state the limitation explicitly. Second, attach a citation to every factual claim. Third, never invent solver keywords, material properties, or revision numbers. These rules are implemented through system prompts, output schemas, and post-generation validation. A practical validation step parses the answer for citation markers and checks each against the retrieved chunk set; any unresolved citation is flagged.

Failure Modes and Their Architectural Causes

Most RAG failures in CAE trace back to a specific layer. Retrieval misses exact identifiers when only dense vectors are used — the fix is hybrid search. Chunks split mid-keyword-block when fixed-size chunking is applied — the fix is semantic chunking. The generator hallucinates when context is thin — the fix is a relevance threshold and an explicit "insufficient evidence" response path. Metadata filters exclude valid results when revision tags are stale — the fix is an ingestion pipeline that re-indexes on revision change. Each failure mode maps to a component, and each component has a measurable health metric: retrieval recall@k, rerank precision, citation resolution rate, and answer latency.

Architecture, in this context, is not an abstract diagram. It is the set of decisions about what gets indexed, how chunks are bounded, which retrieval signals are combined, how the generator is constrained, and where the service attaches to the engineering workflow. Getting these decisions right is what separates a RAG assistant that engineers trust from one they abandon after the first hallucinated material property.