1. Course overview

Computer-aided engineering (CAE) is knowledge-intensive by nature. A single structural analysis may require the analyst to recall material allowables from a supplier datasheet, a mesh-quality rule from an internal guideline, a solver keyword from a user manual, and a boundary-condition convention agreed upon in a previous project. Large language models (LLMs) can draft text fluently, but they cannot reliably recall your organization's specific allowables, solver version behavior, or the reasoning behind a past design decision. Retrieval-augmented generation (RAG) closes that gap by grounding model output in an external, curated knowledge base that is retrieved at query time.

This course teaches you how to design, build, evaluate, and operate a retrieval-augmented AI assistant specifically for CAE workflows. The emphasis is on engineering correctness: the assistant must cite sources, respect unit systems, avoid inventing material properties, and hand off to a human when confidence is low.

What "Retrieval-Augmented" Actually Means

A conventional LLM answers from parametric memory — the statistical patterns frozen into its weights during training. A RAG system adds a second stage: before generating an answer, it converts the user's question into a vector, searches a knowledge index for the most relevant passages, and injects those passages into the model's context window as evidence. The model then synthesizes an answer conditioned on that evidence.

The pipeline has four canonical stages, each with its own failure modes:

• Ingestion — parsing source documents (PDF manuals, Excel allowables tables, solver decks, test reports) into clean text and metadata.
• Indexing — chunking text and embedding each chunk into a vector store, often alongside a keyword index for hybrid search.
• Retrieval — at query time, ranking chunks by relevance using dense, sparse, or hybrid scoring, then optionally re-ranking.
• Generation — prompting the LLM with retrieved context and enforcing citation, unit, and refusal behavior.

For CAE, the ingestion stage is where most projects fail. A Nastran bulk data file, a Fluent journal, and a scanned material certificate are three completely different parsing problems. Treating them identically produces a knowledge base that retrieves plausible-looking but wrong context.

Why CAE Is a Distinctive RAG Domain

Generic RAG tutorials assume prose documents. CAE knowledge is heterogeneous and numerically sensitive. Consider the differences:

These differences drive concrete design decisions. A material allowables table should be chunked by row with column headers preserved, not split mid-table. A solver manual should be indexed with the keyword as a strong metadata field. A guideline document should retain its conditional structure so the retriever can match "thin-walled shell" to the right rule.

Technical Context: Where the Assistant Sits

The assistant is not a replacement for the CAE toolchain. It sits alongside it, mediating between the engineer's natural-language intent and the structured artifacts of simulation. The diagram below shows the reference architecture and the data flow between components.

The dashed blue path shows the retrieval-specific flow: the query is vectorized, matched against the index, and the retrieved passages are injected into the generation prompt. The dashed gray path shows the feedback loop — a critical component that distinguishes a production CAE assistant from a demo. When an engineer corrects an answer, that correction should be captured and used to improve the knowledge base or retrieval configuration.

Core Concepts You Will Use Throughout This Course

Chunking. Splitting documents into retrievable units. For CAE, chunk boundaries should follow semantic structure: one material row, one solver keyword section, one guideline rule. Fixed-size chunking (e.g., 512 tokens) destroys table integrity and separates a rule from its condition.

Embeddings. Dense vector representations of text. General-purpose embedding models handle prose well but may not distinguish "E = 71.7 GPa" from "E = 71.7 MPa." Domain-specific fine-tuning or hybrid search with keyword matching mitigates this.

Hybrid retrieval. Combining dense (semantic) and sparse (keyword/BM25) search. For solver syntax queries, keyword matching is essential; for conceptual questions, dense retrieval performs better. A typical weighting is 0.7 dense / 0.3 sparse, tuned on a validation set.

Grounding and citation. The assistant must attribute every factual claim to a retrieved source. If no source supports a claim, the assistant should say so rather than generate a plausible value. This is non-negotiable in engineering contexts.

Evaluation. Measuring retrieval quality (recall@k, mean reciprocal rank) and generation quality (faithfulness, answer relevance, citation accuracy). A CAE assistant that retrieves the right document but cites the wrong clause is still dangerous.

A Concrete Example: Material Allowable Lookup

Suppose an engineer asks: "What is the tensile allowable for Al 7075-T6 plate at 120°C?"

A naive LLM might answer "around 480 MPa" from training data — a room-temperature value that is wrong at 120°C and unsourced. A properly designed RAG assistant would:

1. Parse the query into entities: material = 7075-T6, form = plate, temperature = 120°C, property = tensile allowable.
2. Retrieve from the material allowables index using metadata filters (material family, form, temperature range).
3. Return the specific row from the correct table, with the source document, revision date, and table identifier.
4. If the temperature falls between tabulated values, either interpolate with a stated method or refuse and ask the engineer to confirm the interpolation basis.

The expected output might look like:

Allowable: Ftu = 448 MPa (basis: A-basis, 120°C, 12.7 mm plate)
Source: MMPDS-15, Table 3.7.2.1.2(b), p. 3-214
Note: Value interpolated linearly between 100°C (455 MPa) and 150°C (438 MPa).
Verify interpolation is acceptable for your certification basis.

If the retrieval returns no matching row — for example, the material is not in the indexed allowables — the assistant must state that the value is unavailable rather than estimate. This refusal behavior is a design requirement, not a limitation.

Scope and Boundaries of This Course

This course covers the full lifecycle of a CAE-focused RAG assistant: requirements definition, knowledge base construction, retrieval design, prompt engineering, evaluation, deployment, and maintenance. It does not teach LLM pre-training, nor does it cover general-purpose chatbots. Every technique is presented in the context of engineering data — units, standards, solver versions, and traceability.

By the end, you will be able to build an assistant that answers CAE questions with cited, version-controlled, unit-consistent evidence, and that knows when to say "I don't know." That last capability is what makes it trustworthy enough for engineering use.