Chapter 5 — AI Across the Computer Science Domains

“Retrieve for facts; fine-tune for behavior. If you’re reaching for fine-tuning to fix a knowledge gap, you’ve already taken a wrong turn.” — a working rule of thumb among applied-ML practitioners, mid-2026

“An intelligent heart acquires knowledge, and the ear of the wise seeks knowledge.” — Proverbs 18:15 (ESV)

Why This Matters

For four weeks you have been a reader. You read like a scientist, you found a problem, you found the literature, and last week you built a comparison matrix that — if you did it honestly — has an empty column or an unaddressed row staring back at you. That empty cell is your gap. This week you turn toward filling it, and for most of you the instrument you will reach for is some form of modern AI.

Here is the trap, and I want you to see it before you fall in. The phrase “I’ll use AI” is not a method. It is a category, and a large one. As of 2026 the AI toolbox holds at least seven distinct families — prompted LLMs, retrieval-augmented generation, fine-tuning (LoRA/QLoRA), agents, computer vision, reinforcement learning, and multimodal models — and they fail in completely different ways, cost wildly different amounts, and demand different data. A reviewer who reads “we applied a large language model to the problem” learns nothing. A reviewer who reads “we used retrieval-augmented generation over a domain corpus because the failure we measured was factual coverage, not behavioral form” learns that you understand your own tool. The difference between those two sentences is the difference between a desk-reject and a defensible contribution.

This is the chapter where the applied in “applied AI” gets real. Every one of you chose a CS domain in Week 2 — software engineering, security, databases, networking, HPC, computer architecture, HCI, robotics, graphics, whatever it was — and committed to investigating how modern AI advances it. This week you decide which AI, against what baseline, and with what data shape. You will write that decision down as the Domain-Specific AI Integration Proposal, and it becomes the methodological spine of everything from here to the symposium.

There are two sides to the AI thread, and you carry both. AI as the instrument you wield in your domain: that is the method you propose this week. And AI as a workload you must govern: the same models that accelerate you will hallucinate a citation, invent a benchmark number, or confidently misclassify your data — and the human author owns every one of those failures. We keep saying it because it is the spine of the whole book: the human stays in the loop where the judgment lives. AI accelerates; you decide, you verify, and you are accountable.

And there is a question underneath the engineering, the one Proverbs 18:15 sets for us: how does a wise mind choose the right method? Not the newest method. Not the one with the highest leaderboard number on a benchmark that may be contaminated. The right one — fitted to the problem, honest about the baseline, sober about where it breaks. Wisdom, in research as in Scripture, is not the accumulation of clever tools. It is the discernment to reach for the right one and the humility to test whether it actually worked.

Coach’s Note — You are not being asked to train a frontier model. You are being asked to apply a method to a domain problem rigorously enough to beat a stated baseline and survive peer review. Scope down. A LoRA fine-tune of an open-weight model on a domain you understand, evaluated honestly, is a better practicum paper than a vague “agentic system” you can’t reproduce.

5.1 — The Method Ladder: Prompt → RAG → Fine-Tune → Distill

Before you name a method, internalize the ladder. It is the single most useful mental model in applied AI, and you climb it only when the rung below it has demonstrably failed.

The rule practitioners repeat in 2026: retrieve for facts, fine-tune for behavior. If your model is getting domain facts wrong, more fine-tuning will not save you — it will memorize a few examples and forget the rest. You want retrieval. If your model knows the facts but answers in the wrong form — wrong format, wrong tone, wrong structured output — retrieval will not help; you want fine-tuning. Diagnosing which failure you have is the entire game, and it is exactly what your comparison matrix and your pilot will measure.

A word on fine-tuning economics. Full fine-tuning is rarely justified in 2026 — it is expensive and invites catastrophic forgetting. The standard moves are LoRA (freeze the base model, train small low-rank adapter matrices) and QLoRA (LoRA plus 4-bit quantization of the base, which brings tuning of a sizable open-weight model down to a single GPU). For a master’s practicum, QLoRA on an open-weight model is often the only fine-tuning path your compute budget allows — and that is fine. Name it, justify it, reproduce it.

Coach’s Note — When a stakeholder (or your past self) says “we need to fine-tune this,” the disciplined first response is: what does the baseline get wrong, and is it a knowledge error or a behavior error? Most “we need fine-tuning” requests are fixed with better retrieval. Try the lower rung first; report that you tried it.

5.2 — Retrieval-Augmented Generation, Honestly

RAG is the workhorse of applied LLM systems, and it is the method most of you will at least consider. The architecture is simple to draw and brutal to get right: a query retrieves relevant chunks from a corpus, and those chunks are stuffed into the model’s context so it answers grounded in your documents rather than its training data.

The lesson that matters for a researcher: retrieval, not generation, is the dominant failure mode. When a RAG system gives a wrong answer, the model usually generated faithfully from bad context — it retrieved the wrong chunks, or missed the relevant one entirely. A widely repeated practitioner estimate is that naïve RAG fails to retrieve the right material a substantial fraction of the time (treat that number as folklore, not a measurement). The research consequence is non-negotiable: you must instrument retrieval — recall and precision of the retrieved set — before you blame the LLM for the final answer. A paper that reports only end-to-end accuracy and concludes “the LLM struggled” has not done the science.

The 2026 RAG landscape has matured past naïve top-k:

If you go RAG, your baseline is almost always the same base model with no retrieval (or with naïve top-k, if you are proposing a fancier variant). State it now.

Two measurements separate a RAG paper from a RAG demo. First, retrieval recall: of the chunks that actually contain the answer, what fraction did you retrieve? If recall is low, no amount of model cleverness saves you — fix retrieval. Second, end-to-end faithfulness: given the retrieved context, did the model answer from it, or did it ignore the context and confabulate? A system can have high retrieval and still hallucinate if the model overrides good context, and you cannot tell these two failures apart without measuring them separately. Report both. A reviewer who sees only end-to-end accuracy will assume you don’t know which half of your pipeline is broken — and they’ll usually be right.

5.3 — Agents and the Tool-Use Standard

An agent is an LLM in a loop with tools and memory: it plans, calls a tool, reads the result, and decides the next step. As of 2026 the common frameworks are LangGraph, the Claude Agent SDK, and CrewAI, and the connector standard binding agents to tools and data is the Model Context Protocol (MCP). If your domain problem is genuinely multi-step — read this file, run that test, query that database, decide — an agent may fit. If it is single-shot, an agent is overkill and a reviewer will say so.

Agents are also where research integrity gets sharp, because an agent’s trajectory is your data. If you propose an agentic system, you must log every step — every tool call, every intermediate decision — or your results are not reproducible and your error analysis is impossible. This is not optional bookkeeping; it is the difference between “the agent solved 41% of tasks” and “the agent solved 41% of tasks, and here is where the other 59% broke.”

The canonical applied-AI anchor in this space is code review and software engineering: SWE-bench Verified (500 human-validated real GitHub issue-resolution tasks, where success means the project’s own test suite passes) is the benchmark the field measures agentic coding against, and c-CRAB (arXiv:2603.23448) is a code-review-agent benchmark you can anchor an SE proposal to. If you are in SE, that is your starting baseline literature.

Evaluating an agent is harder than evaluating a single prompt, and that difficulty is a research design problem, not an afterthought. A single end-to-end success rate hides everything interesting: which step failed, whether the agent recovered, how many tool calls it burned, whether it looped. Your proposal should commit to a trajectory log schema — per step: the tool called, its arguments, the result, the agent’s stated reasoning, and a timestamp — so that your error analysis can say where the 59% it failed went wrong. And mind the baseline trap: an agent’s natural baseline is often a non-agentic single-shot prompt on the same task. If the loop, the tools, and the memory don’t beat one good prompt, you’ve added complexity for nothing — and a reviewer will ask exactly that.

Coach’s Note — Be suspicious of leaderboard top scores. The headline SWE-bench numbers in 2026 include models that were export-suspended mid-year (Chapter 0 of reality: the frontier churns weekly). Cite the methodology and the date, never a frozen “state-of-the-art %,” because by the time your reviewer reads it the number has moved.

5.4 — Reinforcement Learning: For Control, and For Models

RL shows up in your work two ways, and you should know which one you mean.

RL as a domain method. Where the problem is sequential decision-making under a reward — scheduling, control, caching, routing — RL is a natural fit. The verified domain anchors:

• Networking: Aurora (Jay et al., ICML 2019), RL for congestion control; and NVIDIA’s Programmable Congestion Control work (arXiv:2207.02295). Baseline: classical TCP congestion control (Cubic/BBR).
• HPC / scheduling: RL for job scheduling (e.g., Slurm-style schedulers). Hedge: specific scheduling papers like HeraSched and the RLSchert line were not re-verified for this brief — confirm the DOI/arXiv ID against the source before you cite it. Baseline: the production heuristic scheduler (FIFO, backfill).
• Computer architecture: RL for cache-replacement policy. The classic learned-replacement line is Hawkeye (ISCA 2016) and Glider (MICRO 2019). Hedge: their exact quantitative figures were not re-verified — pull the numbers from the papers directly. Baseline: LRU and the practical near-optimal Belady bound.

RL as a way to shape models. This is the live frontier and a likely literature anchor for AI-domain students. RLHF trains on human preferences; RLVR trains on verifiable rewards (math answers, passing unit tests). GRPO, the optimization method popularized by DeepSeek-R1 (arXiv:2501.12948), made RLVR cheap enough to be everywhere. There is a real, unresolved scientific debate here, and if you touch it you must cite both sides: one line of work argues RLVR genuinely expands a model’s reasoning beyond its base (arXiv:2506.14245); another argues it merely sharpens sampling of capabilities the base already had (the “Limit of RLVR” work). A practicum question that lands on the right side of evidence in that debate, for one domain, is a publishable contribution.

5.5 — Fine-Tuning Without Burning Your Budget: LoRA and QLoRA

If your diagnosis says behavior — the model knows the facts but answers in the wrong form, structure, or style for your domain — you climb to fine-tuning. For a master’s practicum, do this the cheap, reproducible way and say so in the proposal.

Full fine-tuning updates every weight. It is expensive, it invites catastrophic forgetting (the model loses general capability while learning your narrow task), and in 2026 it is rarely justified outside industrial labs. Skip it.

LoRA (Low-Rank Adaptation) freezes the base model entirely and trains small low-rank adapter matrices that are injected into the attention layers. You train a tiny fraction of the parameters, the base model’s general knowledge is preserved, and you can keep many task-specific adapters around one frozen base. QLoRA adds 4-bit quantization of the frozen base, which collapses the memory footprint enough to fine-tune a sizable open-weight model on a single GPU — often the only fine-tuning path a student’s compute budget allows.

What a fine-tuning proposal must commit to, in writing:

• The labeled dataset — fine-tuning is supervised; if you don’t have labels, you’re on the wrong rung. State size and source.
• A catastrophic-forgetting check — evaluate on a general held-out task before and after, not only on your target task, so you can show you taught a behavior without lobotomizing the model.
• The base model and its version/date — open-weight model versions (Llama / DeepSeek / Qwen / GLM lineages) drift through 2026; pin the exact one.
• The baseline — almost always the same base model, un-tuned, with good prompting. If prompting alone closes the gap, you never needed to fine-tune (§5.1).

Coach’s Note — “We fine-tuned it” impresses nobody by itself. “We QLoRA-tuned an 8B open-weight model on 4,000 labeled examples, checked general-task retention, and beat the prompted base by 9 points on the target metric” is a method a reviewer can reproduce and trust. Specifics are the currency of credibility.

5.6 — Computer Vision and Multimodal AI

If your domain is graphics, robotics, medical imaging, AR/VR, or anything that sees, the 2026 story is convergence on prompt-driven vision-language foundation models rather than bespoke architectures. The canonical building blocks remain ViT, CLIP, DINO, Stable Diffusion, and YOLO; the dominant production pattern is YOLO+SAM — detect with YOLO, then segment with the Segment Anything Model. The SAM lineage is moving fast: SAM 3 (Nov 20, 2025; arXiv:2511.16719) and SAM 3.1 “Object Multiplex” (Mar 27, 2026; real-time video). Cite the version and date.

Multimodal models — natively handling text, image, and often audio together — are now the default frontier shape rather than a special case. If your problem genuinely spans modalities (a UI-understanding task that reads both screenshot and DOM, say), a multimodal model is the fit; if it is text-only, do not pay the multimodal tax for a screenshot you do not need.

Coach’s Note — Vision benchmarks carry the same contamination and churn risks as text. The “~80% on MMMU-Pro” kind of figure you’ll see quoted is illustrative and secondary — treat it as a vibe, not a citation, and find the primary number for the specific model and date you actually use.

5.7 — Matching Method to Problem: The Decision Framework

Here is the discipline. You match a method to a problem along three axes, in this order:

1. What is the task shape? Generate text? Retrieve facts? Make a sequential decision? See an image? Classify? The task shape eliminates most of the menu immediately.
2. What is the data shape? Do you have a labeled dataset (supervised / fine-tune is on the table) or only a document corpus (RAG) or only a reward signal (RL) or nothing but a few examples (prompting)? Your data is the hardest constraint. Most students over-estimate what data they have.
3. What is the failure you measured? Back to the ladder: a knowledge failure says RAG; a behavior/form failure says fine-tune; a can’t-elicit-it failure says better prompting first.

Then — and this is the part students skip — name the baseline you intend to beat. Every method proposal is implicitly a comparison: method X beats baseline Y on metric Z by margin M. If you cannot name Y, you do not yet have a research design; you have an enthusiasm. The honest baseline is usually embarrassingly simple — the production heuristic, the non-AI tool, the base model with no retrieval, last year’s published number on the same benchmark. Simple baselines are good; they make your contribution measurable and they protect you from the most common reviewer kill-shot: “you never showed this beats the obvious thing.”

Use code/method-fit-matrix.csv as the worksheet: one row per candidate method, columns for task shape, data shape, measured failure, baseline, and failure modes. Fill it before you write a word of prose.

A worked walk-through. Suppose your domain is databases and your problem is natural-language-to-SQL on a private enterprise schema. Axis 1 (task shape): generate structured text — an LLM is on the menu. Axis 2 (data shape): you have the schema and a few hundred example NL/SQL pairs, but no large labeled corpus. Axis 3 (measured failure): the base model writes syntactically valid SQL that references the wrong tables — it doesn’t know your schema. That is a knowledge failure, not a behavior failure, so the ladder says RAG (retrieve the relevant schema and example queries into context), not fine-tuning. Your baseline is the prompted base model with the schema dumped naïvely into context (or a cost-based optimizer’s template SQL); your metric is execution-match accuracy on a held-out set; your anchor is LLMSTEER (arXiv:2411.02862). Notice what happened: the failure diagnosis picked the rung, the data shape ruled out fine-tuning, and the baseline is something simple you can actually measure. That is the whole method, and you derived it without reaching for the shiniest tool.

5.8 — The Failure Modes You Must Govern

Every method on the ladder fails, and naming the failure mode is part of the proposal — reviewers expect it, and integrity demands it.

• Hallucinated facts and citations. The headline risk. Walters & Wilder (2023, Scientific Reports) found 55% of GPT-3.5 and 18% of GPT-4 citations entirely fabricated, and among the real ones, 43% / 24% had substantive errors; Bhattacharyya (2023, Cureus) found 87% of citations to real works carried ≥1 metadata error. Those are 2023-model figures — treat them as illustrative, point-in-time; newer retrieval-grounded agents shift them downward but do not zero them. Verify every citation against a real index (dblp, Semantic Scholar, the publisher). This is not advice; in your paper it is the difference between scholarship and misconduct.
• Fabrication that scales with context. A 2026 study over 172 billion tokens (arXiv:2603.08274) found fabrication rises with context length — the longer the prompt, the more confidently the model invents. If your method feeds long contexts, this is a named threat.
• Retrieval failure masquerading as reasoning failure (§5.2): instrument retrieval separately.
• Contaminated benchmarks: the model may have seen your test set in training. Prefer contamination-resistant benchmarks (LiveCodeBench, LiveBench, MMLU-Pro) and report the risk.
• Over-trust / automation bias: the human stops checking because the output looks fluent. The faithfulness caution is real — outputs can be fluent and unfaithful at once.

Coach’s Note — When you write the proposal, give each failure mode a sentence and a mitigation. “We mitigate citation hallucination by verifying every reference against dblp before inclusion” is a sentence a reviewer trusts. Silence on failure modes reads as naïveté.

5.9 — Interactive Lab: AI Method Matcher

Open the AI Method Matcher embedded directly below this chapter on the site.

Drive it the way you’ll drive your own proposal. Choose your domain problem and describe your data shape (labeled set? document corpus? reward signal? a handful of examples?). The widget walks the method ladder with you and surfaces a fitting family — prompting, RAG, fine-tune (LoRA/QLoRA), agent, CV, RL, or multimodal — together with the baseline it should beat and the failure modes you must govern for that choice.

Run it at least three times: once with the data shape you wish you had, once with the data shape you actually have, and once for the lower rung of the ladder than the one you first reached for. Watching the recommendation change as you tell the truth about your data is the entire lesson of §5.7. Screenshot the run that matches your real project and paste the rationale into your proposal’s “method selection” paragraph — then rewrite it in your own words (the widget is a thinking aid, not a ghostwriter).

What it teaches: that “use AI” is seven different decisions, that your data is the binding constraint, and that a method without a named baseline is not yet research.

5.10 — How a Wise Mind Chooses the Right Method

Proverbs 18:15 gives us our question this week: how does a wise mind choose the right method? The verse splits into two motions — “an intelligent heart acquires knowledge, and the ear of the wise seeks knowledge.” Acquiring, and seeking. The Hebrew puts an active ear at the center of wisdom: the wise one is not the one who already knows but the one who keeps listening for what is true. That is a startling thing for Scripture to praise — not certainty, but the disciplined hunger to find out.

It cuts directly against the temptation of this chapter. The fastest way to look smart in applied AI is to reach for the newest, largest, most impressive method and announce it. The wise way is slower: to seek — to ask what the failure actually is, to try the lower rung, to name the unglamorous baseline, to instrument retrieval before blaming the model. The fool grabs the shiniest tool; the wise one’s ear stays open to the evidence, even when the evidence says your fancy method did not beat the simple thing. Confessional Lutheran thought has a name for the posture underneath this: we are, all of us, simul — at once justified and still sinners, and so still capable of self-deception. The researcher who forgets that will quietly fit the data to the hope. The one who remembers it builds the honest baseline on purpose, as a guard against his own heart.

And there is a deeper humility here. We do not create knowledge from nothing; we search out an order that was already laid down. A wise mind choosing the right method is, in the end, submitting its cleverness to what is actually the case — listening, with an open ear, for the truth that does not bend to our preference. The model will tell you what you want to hear. Reality will not. The discipline of the next eleven weeks is to keep your ear turned toward the second voice.

5.11 — Common Pitfalls

Pitfall: Naming a method before naming the failure. Example: “We will fine-tune an LLM for SQL generation.” Why fine-tune? Is the model getting SQL syntax wrong (behavior — fine-tune may fit) or schema facts wrong (knowledge — you want RAG)? Fix: Diagnose the failure first (§5.1, §5.7). Let the failure pick the rung. Write the diagnosis down before the method.

Pitfall: No baseline, or a baseline that’s also AI. Example: “Our GPT-based detector beats our older GPT-based detector.” A reviewer asks: does either beat the rule-based filter that costs nothing? Fix: Always include a non-AI or trivially-simple baseline (production heuristic, last published number, base model no-retrieval). Simple baselines protect you.

Pitfall: Reporting end-to-end accuracy for a RAG system and concluding “the LLM struggled.” Example: 60% answer accuracy, no retrieval metrics — so you can’t tell if the model reasoned badly or just never saw the right chunk. Fix: Instrument retrieval recall/precision separately (§5.2). Most RAG failures are retrieval failures.

Pitfall: Citing a frozen leaderboard top score as “state of the art.” Example: “Model X achieves 95% on SWE-bench (SOTA)” — written about a model that was export-suspended two months later. Fix: Cite methodology + date, not a frozen number. The frontier moves weekly; your number will be stale before review.

Pitfall: Trusting LLM-generated citations into your bibliography. Example: Three of your “related work” references don’t exist; ICCV-class venues reject papers with non-existent citations without review. Fix: Verify every reference against dblp / Semantic Scholar / the publisher (§5.8). The 55%/18% fabrication figures are why.

Pitfall: Over-scoping — proposing to train a frontier model on a master’s compute budget. Example: “We will pre-train a 70B multimodal model.” You have one GPU and twelve weeks. Fix: Scope to QLoRA / RAG / prompting on an open-weight model, or RL on a small simulator. A reproducible small result beats an unreproducible grand one.

Pitfall: Ignoring the venue’s AI-disclosure policy until the end. Example: You used an LLM to generate part of your method and never disclosed it; the venue desk-rejects for an incorrect filing. Fix: Read the disclosure rule now (Appendix C) and write the disclosure paragraph into the proposal template this week.

5.12 — Reps

The full set lives in the exercises — 8–12 graduate reps that move your project forward this week, ending in a capstone that rehearses the deliverable. A preview:

• Rep 1 — Diagnose the failure. State, in two sentences, whether your domain’s current failure is knowledge, behavior, or can’t-elicit-it.
• Rep 2 — Walk the ladder. For your problem, write one line each for prompting / RAG / fine-tune, and why each does or doesn’t fit.
• Rep 4 — Name the baseline. Write the single sentence “Method X beats baseline Y on metric Z by margin M” for your project.
• Rep 6 — Anchor to a paper. Tie your domain to one canonical applied-AI paper from §5.7 and verify it exists in dblp.
• Rep 9 — Govern the failure modes. Give each named failure mode a one-line mitigation.

Do the on-page Check Your Reps quiz before you start — it’s five questions and it tells you whether §5.1–5.8 actually landed.

5.13 — This Week’s Deliverable

This week you produce the Domain-Specific AI Integration Proposal — the full spec is in Project 5. In one tight document you will state your domain problem, diagnose its failure mode, select an AI method by walking the ladder, name the baseline it must beat and the metric that decides it, identify the dataset/benchmark and the canonical paper you anchor to, and list the failure modes with mitigations and the venue disclosure stance.

Use the starter files: code/method-fit-matrix.csv to compare candidate methods, code/proposal-skeleton.txt for the document structure, code/baseline-card.yaml to pin down exactly what you’re beating, and code/verify_citations.py to check that every reference you cite is real. This proposal is the methodological core of your paper; it feeds directly into the research questions and hypotheses you’ll sharpen next week. Set up your portfolio and ACM/IEEE template per Appendix A if you haven’t; lean on Appendix B for tools and Appendix C for the disclosure rules.

5.14 — Coach’s Final Word

Five weeks in, you stop being a reader and start being a methodologist. The hard part of this week is not learning what RAG or LoRA is — that’s an afternoon of reading. The hard part is the discipline to choose the right method instead of the impressive one, to write down the unglamorous baseline that might beat you, and to keep your ear turned toward the evidence when it contradicts your hope.

That discipline is the whole craft. Anybody can announce a method. A researcher diagnoses the failure, picks the lowest rung that fits, names what they must beat, and tells the truth about where it breaks. Do that this week, on paper, for your domain — and you’ll have the spine of a paper a real venue would read.

Choose wisely. Keep your ear open. See you on Monday.

Up next: the exercises for this week’s reps · Project 5 for the Domain-Specific AI Integration Proposal · then Chapter 6, where we turn this method into a falsifiable question. Previously: Chapter 4.