Software Development 重點整理

核心概念

「Software Development」是 NCA-GENL 占比 24% 的第二大領域，考的是如何用 Python 把一個 LLM 應用從零打造到上線。官方競能清單把這條路拆成四層：先用 chat-completions API 串出端到端骨架（client → app → LLM API → response），再用 prompt engineering 把模型「調教」到位，接著用 RAG 把外部知識接進來消除幻覺，最後用 tool use 與 agents 讓模型能行動。NVIDIA 在「Fast Path to Developing With LLMs」明確給出開發順序：API-first → RAG → 小規模 fine-tune → 自訓模型，每一層只在前一層撞牆時才往上爬，避免過早優化。

本科四大主題環環相扣。LLM Application Stack 處理架構、API/SDK 用法與 inference optimization（KV cache、quantization、batching）。Prompt Engineering 涵蓋 prompt 結構、迭代法，以及 few-shot、chain-of-thought、self-consistency 等技巧。Retrieval-Augmented Generation 是企業級部署的事實標準——ingest → chunk → embed → index → retrieve → rerank → generate，重點在 chunk 大小、embedding、vector store 選型與 hybrid retrieval + reranking。Agents & Tool Use 則用 function calling 與 ReAct/LangGraph loop 組裝多步驟 agent，並善用 LangChain、LlamaIndex、NeMo 框架。貫穿全科的工程紀律是：streaming 降低 time-to-first-token、guardrails 過濾輸入輸出、caching 省成本、observability 可追蹤、eval 不可省，且永遠把 agent 當成「需要授權、限速、稽核的初階工程師」來對待。

LLM Application Stack

LLM application architecture

定義。 一個典型的 LLM 應用，是把使用者輸入經過後端編排、組裝成 prompt 送給 LLM、再把輸出解析成可用結果的端到端流程。NVIDIA DLI 把它描述為：client → backend → [retrieve context] → prompt template → LLM → output parser → response。

原理。 架構的核心是「prompt template」與「output parser」這兩個夾在 LLM 兩側的轉換層。Prompt template 用變數把 instruction、context、examples、format constraints 拼成最終 prompt；output parser 把 LLM 回傳的純文字轉成結構化型別（如 JSON、Pydantic 物件）。官方強調五項生產級最佳實踐並列其上：streaming（逐 token 回傳，降低 time-to-first-token）、guardrails（輸入過濾 PII/prompt injection，輸出過濾 toxicity/格式）、caching（快取 prompt/response 省成本）、observability（用 LangSmith/Phoenix/Langfuse 記錄 prompt+response 與 trace ID）、eval（自動回歸測試 + LLM-as-judge）。

具體例子。 一個客服機器人：使用者問題進 backend，先做 PII 過濾，從知識庫撈出相關段落填入 prompt template，串流呼叫 NIM-hosted Llama-3，output parser 抽出答案與引用來源回傳前端。

常見陷阱。 把所有邏輯塞進一個巨型 prompt 而沒有 template/parser 分層，導致無法測試與替換；忘了在 day 1 就加 eval（官方說 evals 要 day 1 加，不是 day 30）；以為 guardrails 只需輸入端，其實輸出端也要過濾。

常考點：client→backend→prompt template→LLM→output parser→response 流程、五大最佳實踐（streaming / guardrails / caching / observability / eval）、time-to-first-token 與 streaming 的關係

Working with LLM APIs and SDKs

定義。 LLM 應用透過 chat-completions API 與模型互動，官方要求能使用 OpenAI / NVIDIA NIM / Anthropic SDK 的 chat-completions API，並掌握三項進階能力：streaming、function calling、structured output。

原理。 Chat-completions 以 message 串為輸入（system / user / assistant 角色），回傳模型回應。三項進階能力分別解決不同問題：streaming 讓 token 邊產生邊回傳，改善互動 UX；function calling 讓模型在回應中輸出結構化的工具呼叫意圖（tool_calls），由應用執行後把結果餵回；structured output 強制模型輸出符合 schema 的 JSON，避免事後字串解析的脆弱性。關鍵設計優勢是介面標準化——NVIDIA NIM 提供 OpenAI-compatible API，意味著只要換 base URL 與模型名，同一段程式碼就能在 GPT、Claude、self-hosted Llama 之間切換，避免 vendor lock-in。

具體例子。 用 OpenAI SDK 串 stream=True 做打字機效果；用 function calling 定義 get_weather(city) 讓模型自行決定何時查天氣；用 structured output 要求模型回傳 {"sentiment": "...", "score": ...} 直接入庫。

常見陷阱。 期待 function calling 會「自動執行」函式——其實模型只回傳呼叫意圖，執行與餵回結果是應用的責任；以為 structured output 永遠合法而不做 schema 驗證；忽略 NIM 是 OpenAI-compatible，誤以為要重寫整套 client。

常考點：chat-completions 三能力（streaming / function calling / structured output）、NIM 是 OpenAI-compatible API、function calling 由應用負責執行工具、structured output 用於 schema 驗證輸出

Inference optimization basics

定義。 Inference optimization 是在不重訓模型的前提下，提升吞吐（tokens/sec）與降低延遲的工程手段。官方競能點名五項：KV cache、batching、INT8/INT4 quantization、TensorRT-LLM、NIM。

原理。 主要槓桿如下：（1）Quantization 把權重從 FP16 降到 INT8/FP8（品質損失極小、約 2× 吞吐）或 INT4（AWQ/GPTQ，省更多但須留意品質下降）。（2）KV cache 快取已算過的 key/value，避免重算；快取會隨 context 長度成長，可用 vLLM 的 PagedAttention 分頁，並可在共用 system prompt 的請求間共享 prefix KV。（3）Batching：static batching 簡單但浪費，continuous / in-flight batching（vLLM、TRT-LLM）做 token 級排程，吞吐大增——官方點名「沒開 continuous batching 會比應有吞吐低 5×」是常見錯誤。（4）Speculative decoding：小 draft model 產生候選、大 target model 驗證，簡單 token 約 2× 加速。（5）TensorRT-LLM / NIM / Triton 做生產級部署與動態批次。

具體例子。 LLaMA-3-8B 在 FP16 約需 16 GB，INT4 約 5 GB，量化後可塞進單張消費級 GPU；多個共用同一 system prompt 的請求重用 prefix KV cache 省下重算成本。

常見陷阱。 把 time-to-first-token 與 time-per-token 混為一談（官方明列要分開量測）；INT4 後不重新評估品質就上線；挑了比任務需求大 2× 的模型；以為「我們自控模型」就不需要安全過濾。

常考點：INT8/FP8≈2×、INT4 省更多但品質風險、continuous/in-flight batching vs static、KV cache 隨 context 成長且可共享 prefix、speculative decoding 小 draft+大 target、分開量測 TTFT 與 TPT

Prompt Engineering

Prompt engineering principles

定義。 Prompt 是「使用者提供、用以引導出特定回應的輸入」，輸出品質高度取決於 prompt 品質。Prompt engineering 是有系統地設計與迭代 prompt 的工程實踐。

原理。 官方拆解 prompt anatomy 為四要素：instruction（指令）+ context（背景）+ examples（範例）+ format constraints（格式約束）。而方法論核心是 iterative prompting——「write → test → refine → measure」的閉環：寫出初版、用代表性輸入測試、根據失敗案例修正、再用 eval 量化是否進步。這呼應「You can't tune what you don't measure」的工程信條。最基本的形式是 zero-shot prompting：不給範例直接問，對訓練良好的任務有效，但對罕見任務可能失敗。

具體例子。 把「總結這篇文章」改寫為帶四要素的 prompt：instruction（用三點條列總結）+ context（貼上文章）+ example（示範一個三點總結）+ format（每點不超過 20 字），輸出穩定度大幅提升。

常見陷阱。 憑感覺改 prompt 卻沒有固定 eval 集，無法判斷是否真的變好；把 context 與 instruction 混在一起讓模型分不清；zero-shot 套用在格式特殊的任務上而不給範例導致格式飄移。

常考點：prompt anatomy 四要素（instruction/context/examples/format）、iterative loop（write→test→refine→measure）、zero-shot 適用與失效情境、「不量測就無法調校」

Few-shot, chain-of-thought, self-consistency

定義。 這組是進階 prompting 技巧。Few-shot 在真正問題前提供 1–5 個範例，讓模型「學會格式」而不需訓練；Chain-of-thought（CoT） 引導模型輸出推理步驟；Self-consistency 取樣多條 CoT 推理鏈再投票取答案。

原理。 Few-shot 利用模型的 in-context learning，用少量 demonstration 對齊輸出格式與風格。CoT 有兩種觸發方式：few-shot CoT——範例中包含明確推理步驟，模型模仿該模式；zero-shot CoT——用觸發語「Let's think step by step」在無範例下引出推理。CoT 大幅改善算術、邏輯與多步推理。Self-consistency 則認知到單一推理鏈可能出錯，故取樣多條鏈後對最終答案做多數投票，提升穩健度。相關技巧還有 self-refine（模型自我批評並重寫草稿）與 ReAct（交錯 reasoning 與 action/observation，屬 agent 範疇）。

具體例子。 數學應用題加「Let's think step by step」（zero-shot CoT）即顯著提升正確率；對關鍵分類任務取樣 5 條 CoT 鏈投票（self-consistency）以降低偶發錯誤。

常見陷阱。 Few-shot 範例本身格式不一致，反而教壞模型；把 self-consistency 用在只需單次、成本敏感的場景（取樣多次費用倍增）；混淆 few-shot CoT（範例帶推理）與 zero-shot CoT（靠觸發語）。

常考點：few-shot 給 1–5 範例學格式、zero-shot CoT 觸發語「Let's think step by step」、few-shot CoT vs zero-shot CoT 差異、self-consistency = 多條 CoT 投票、CoT 改善多步推理

Retrieval-Augmented Generation

RAG architecture and components

定義。 RAG 是「用來自特定且相關資料來源的資訊，提升生成式 AI 模型準確性與可靠性的技術」。NVIDIA 用法庭類比說明：法官擁有一般法律知識，但複雜案件需法庭書記員（court clerk）做專門研究——LLM 用 parametric knowledge 回答一般問題，但要做有來源依據的權威回答，就需 RAG 扮演書記員角色。

原理。 RAG 解決 LLM「parameterized knowledge」無法涵蓋專屬/即時資料的問題。高階運作四步：（1）Query Embedding——把使用者查詢經 embedding model 轉成數值向量；（2）Vector Matching——與知識庫索引中的向量比對；（3）Data Retrieval——取出相符資料轉回可讀格式回給 LLM；（4）Response Generation——LLM 結合檢索資訊與自身回應產出最終答案，可附引用。完整工程 pipeline 為 ingest → chunk → embed → index → retrieve → rerank → generate。RAG 建立信任的四理由：citability（可引用）、clarity（釐清歧義）、accuracy（減少幻覺）、accessibility（最少五行程式即可實作）；且比重訓便宜、來源可動態抽換而不需重訓。

具體例子。 醫療 AI 助理配臨床索引、金融分析接市場資料、企業把手冊/影片/日誌轉成知識庫供客服與開發者使用。NVIDIA 提供 AI Blueprint for RAG、NeMo Retriever、NIM 等堆疊。

常見陷阱。 以為 RAG 需要重訓模型（其實是 fine-tuning recipe 般地外掛、來源可動態抽換）；不附引用導致使用者無法驗證；以為 RAG 能完全消除幻覺（只是大幅降低）。

常考點：法庭書記員類比、四步驟（embedding→matching→retrieval→generation）、完整 pipeline、RAG 四信任理由（citability/clarity/accuracy/accessibility）、比重訓便宜且來源可抽換、LangChain 常用於串接

Chunking, embedding and indexing strategies

定義。 這是 RAG ingest 階段的核心決策：如何把文件切塊（chunking）、轉向量（embedding）、建索引（indexing），並選對 vector store 與相似度度量。

原理。 Chunking：官方建議 chunk 大小 200–800 tokens、overlap 10–20%——太大則檢索精度低、太小則上下文破碎，overlap 用來避免語意被切斷。LangChain 提供 RecursiveCharacterTextSplitter（預設）、MarkdownHeaderTextSplitter、CharacterTextSplitter，可調 chunk_size 與 chunk_overlap。Embedding：用 embedding model（Sentence-Transformers、NVIDIA Embed、OpenAI Embedding-3）把 chunk 與 query 轉成定長向量。Indexing & vector store：把 embedding 加 metadata 存入向量庫，常用 .similarity_search(query, k=4) 取 top-k。相似度度量有 cosine、dot product、L2。原型用 FAISS、生產用 Milvus / pgvector。

具體例子。 把一份 PDF 用 RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=80) 切塊，經 NVIDIAEmbeddings 轉向量存入 FAISS，查詢時 as_retriever(search_kwargs={"k": 4}) 取 4 段。

常見陷阱。 chunk 過大導致 top-k 充斥無關內容、稀釋訊號；overlap 設 0 使句子被腰斬；query 與 document 用不同 embedding model 導致向量空間不一致；忘了存 metadata 而無法過濾或引用來源。

常考點：chunk 200–800 tokens、overlap 10–20%、RecursiveCharacterTextSplitter 為預設、相似度度量 cosine/dot/L2、FAISS 原型 vs Milvus/pgvector 生產、query 與 doc 須用同一 embedding model

Hybrid retrieval and reranking

定義。 Hybrid retrieval 結合稀疏的 BM25（關鍵字）與稠密的 dense 向量檢索；Reranking 在初步檢索後用 cross-encoder 重新排序，提升 precision@k。

原理。 Dense retrieval 擅長語意相似但對罕見關鍵字、專有名詞或 out-of-distribution 查詢較弱；BM25 則精準命中字面關鍵字。Hybrid（BM25 + dense） 兩者互補，官方稱其「對罕見關鍵字或 OOD 查詢更穩健」，LangChain 用 EnsembleRetriever 實作。Reranking 的動機是：bi-encoder（dense 檢索用）各自編碼 query 與 doc 再比相似度，速度快但精度有限；cross-encoder 把 query 與候選 doc 一起輸入評分，精度高但慢，故只用在「先用快速檢索取較多候選、再 rerank 取前幾名」的兩階段流程——官方指出 reranking 能「顯著提升 precision@k」。LangChain 用 ContextualCompressionRetriever 包裝 rerank。

具體例子。 技術文件問答中夾雜大量型號代碼（如 GH200），純 dense 檢索常漏；加 BM25 hybrid 後字面命中型號，再用 cross-encoder reranker 把最相關段落推到前 3 名餵給 LLM。

常見陷阱。 把 cross-encoder 當第一階段檢索器跑全庫（太慢、不可行，它只能 rerank 少量候選）；以為 hybrid 一定要兩套基礎設施而放棄（EnsembleRetriever 已封裝）；reranker 取的 k 太小反而漏掉正解。

常考點：hybrid = BM25(稀疏) + dense(稠密)、對罕見關鍵字/OOD 更穩健、cross-encoder reranker 提升 precision@k、bi-encoder vs cross-encoder（快但糙 vs 慢但準）、reranker 用於兩階段重排而非全庫檢索

Agents & Tool Use

Tool use, function calling, and agents

定義。 Tool use / function calling 讓 LLM 呼叫外部函式（DB 查詢、API、計算）；Agent 則是用 loop 讓模型反覆「思考→行動→觀察」以完成多步驟任務，典型為 ReAct 或 LangGraph。

原理。 Function calling 流程：定義 tool schema（名稱、參數、說明）綁定到模型（model.bind_tools([...])），模型在 AIMessage 中回傳 tool_calls，應用執行後把結果以 ToolMessage 餵回，模型再決定下一步。ReAct loop 交錯 Thought（reasoning）、Action（tool call）、Observation（tool result），直到產出最終答案。LangGraph 把它建成 message 上的狀態機，支援分支（tool call vs final answer）、循環（失敗後 re-plan）與持久化（checkpoint）。官方反覆強調安全紀律：把 agent 工具當成 web route 對待——auth、rate limit、audit；別讓 agent 在沒有 scoped credentials 下呼叫 shell 或 DB；並 bound the loop（max iterations、timeout）。

具體例子。 LangChain 用 @tool 裝飾 get_weather(city)，create_agent(model, tools, prompt) 回傳一個 runnable，loop：呼叫 LLM → 有 tool_calls 就執行並 append ToolMessage → 直到產出最終答案。

常見陷阱。 不設 max iterations 或 timeout 導致 agent 無限迴圈/燒錢；給 agent 過寬的 DB/shell 權限；tool schema 說明寫不清楚使模型亂呼叫；以為 function calling 模型會自己執行（仍需應用執行並回傳）。

常考點：function calling 流程（schema→tool_calls→執行→ToolMessage 回傳）、ReAct = Thought/Action/Observation 交錯、LangGraph 狀態機（分支/循環/persistence）、bound the loop（max iter/timeout/scoped creds）、把 agent 工具當 web route（auth/rate limit/audit）

Frameworks: LangChain, LlamaIndex, NeMo

定義。 這些是加速 LLM 應用開發的框架。LangChain 標準化 LLM 供應商與周邊工具的介面；LlamaIndex 專注資料索引與檢索；NeMo（含 NeMo Retriever、NeMo Guardrails）是 NVIDIA 的生態。官方競能也要求「知道何時該放棄框架」。

原理。 LangChain 以一組 core primitives 組裝應用：Chat Models、Messages（System/Human/AI/Tool）、Prompt Templates、Output Parsers、Embeddings、Vector Stores、Retrievers、Document Loaders/Splitters、Tools、Agents。串接靠 LCEL（LangChain Expression Language），用 | 把元件接起來——chain = prompt | model | StrOutputParser()，免費獲得 .batch()、.stream()、.ainvoke()。其抽象階層由高到低為 Deep Agents → LangChain Agents（create_agent()）→ LangGraph，配 LangSmith 做 tracing/eval。設計教訓：vendor lock-in 可避免（把 ChatOpenAI 換成 ChatNVIDIA 不必改 chain）；生產 RAG 一定要附引用；沒有 trace 幾乎無法 debug agent；而框架會綁住你——能加速就用，需要精細控制時就果斷捨棄。

具體例子。 標準 RAG 用 LCEL：{"context": retriever, "question": RunnablePassthrough()} | prompt | ChatOpenAI() | StrOutputParser()，要換成自架模型只需把 ChatOpenAI() 換 ChatNVIDIA()。

常見陷阱。 為了用框架而硬套，反而增加複雜度（該捨棄時不捨棄）；不接 LangSmith 就調 agent，出錯難以追蹤；混淆 LangGraph（低階編排）與 LangChain Agents（中階）的定位；以為換供應商要重寫整條 chain。

常考點：LangChain core primitives、LCEL 用 | 串接並免費取得 batch/stream/async、抽象階層 Deep Agents/LangChain Agents/LangGraph、LangSmith 用於 tracing、換供應商不改 chain（避 lock-in）、「能加速就用框架、需控制就捨棄」

---

依據來源

本科內容依據以下官方/權威來源撰寫，未捏造來源外數據：

• docs/official/nvidia-nca-genl/scope/01-exam-blueprint.md（Software Development 占 24%）
• docs/official/nvidia-nca-genl/scope/02-study-guide.md（Domain 2 競能清單）
• docs/official/nvidia-nca-genl/guides/dli-04-prompt-engineering.md
• docs/official/nvidia-nca-genl/guides/dli-05-rapid-llm-apps.md
• docs/official/nvidia-nca-genl/guides/blog-02-rag.md
• docs/official/nvidia-nca-genl/books/langchain-concepts.md
• docs/official/nvidia-nca-genl/guides/video-01-fast-path-llms.md
• docs/official/nvidia-nca-genl/guides/video-02-running-own-llm.md