2. AI / 大模型 / Agent 答辩

按「业务痛点 → 为何引入大模型/Agent → 总体架构（应用层、模型层、工具/知识层）→ 核心能力与效果 → 边界与风险」介绍，强调你独立完成的模块，控制在 2～3 分钟。

1. 开放域理解：自然语言意图多样，规则难穷尽
2. 开发效率：少标注、快速落地问答/摘要/抽取
3. 可扩展：换提示词/工具即可扩展能力

也要诚实说明：可控性、幻觉、成本与延迟是代价，关键业务仍需规则与人工审核兜底。

LLM 以海量文本预训练的 Transformer 模型，擅长生成与理解。传统 NLP 多为任务专用模型（分类、序列标注），需大量标注。LLM 通用能力强，但幻觉与不可解释性更突出，毕设常做应用层封装而非从零训练。

Token 是模型计费与长度单位；上下文窗口限制单次可输入+输出长度。超长文档需切片、摘要或 RAG；提示词过长会挤占回答空间并增加费用。答辩说明你如何截断、分块与限制历史轮数。

通过设计系统提示、角色、约束、示例（few-shot）、输出格式（JSON）引导模型稳定完成任务。好提示=明确目标+边界+格式+反例。项目中提示词应版本管理，勿硬编码散落。

零样本直接下指令；少样本给若干输入输出示例；思维链（CoT）要求分步推理提升复杂题正确率。毕设可按任务难度选用，注意 CoT 会增加 token 与延迟。

幻觉指模型一本正经编造事实。缓解：RAG 检索真实资料约束回答、要求引用出处、降低温度、输出结构化校验、关键结论人工审核、拒答策略（知识库未命中则说明不知道）。

温度高更随机创意，低更确定；Top-p 核采样控制候选集合。问答/抽取宜偏低温（如 0～0.3），创意写作可略高。答辩说明你任务类型与最终参数。

检索增强生成：先检索知识库相关片段，再让模型基于片段生成，降低幻觉、可更新知识、不必微调。适合私有文档问答、制度查询、论文资料助手等毕设场景。

1. 文档解析与清洗
2. 分块（chunk）
3. 向量化写入向量库
4. 用户问题向量检索 TopK
5. （可选）重排序
6. 拼进提示词生成答案
7. 展示引用与反馈

按段落/标题语义切分，控制 chunk 大小（如 300～800 字）与重叠，避免切断关键句。表格、代码单独策略。分块质量直接影响检索命中，是 RAG 核心工程点。

常见：Milvus、Chroma、FAISS、Elasticsearch dense_vector、云厂商向量检索。毕设可用 Chroma/FAISS 快速落地；数据量大、要过滤字段再考虑 Milvus 等。说明维度、距离度量（cosine/L2）与过滤条件。

Embedding 把文本映射为向量用于相似度检索；对话/生成模型负责理解生成。二者常搭配：检索用 embedding 模型，回答用 LLM。不要混用「聊天模型直接当向量」除非接口明确支持。

1. 优化分块与清洗
2. 换更好的 embedding
3. 混合检索（关键词+向量）
4. 重排序 rerank
5. 改写用户问题 Query Rewrite
6. 提高 TopK 后再压缩上下文

用命中率/人工抽检评估，勿只凭感觉。

ChatBot 多轮对话生成文本；Agent 能规划任务、调用工具（搜索、数据库、API、代码），根据观察再决策，形成「思考→行动→观察」循环，更接近自动办事，但也更难控、成本更高。

ReAct：交替推理与行动；Plan-and-Execute：先计划再逐步执行。毕设选一种说清：为何适合你的工具集与延迟要求，如何限制最大步数防止死循环。

工具要：名称清晰、参数 JSON Schema 明确、权限最小、超时与失败返回可读错误。危险操作（删改、支付）需二次确认或禁止。日志记录每次调用入参出参便于排错。

1. 最大步数 / 最大 token
2. 工具白名单
3. 同一工具连续失败熔断
4. 人工确认节点
5. 系统提示明确何时该结束

模型不直接执行代码，而是按约定输出要调用的函数名与参数；应用层解析后真实调用，再把结果回填给模型继续生成。关键是应用层编排与校验，而非「模型自己连库」。

若用过可简述：用统一协议暴露工具/资源给 Agent，便于解耦。没用过可说：毕设采用自研 HTTP 工具接口 + JSON Schema，思想类似「标准化工具描述」。诚实最重要。

拆分角色（规划、检索、写作、审核）降低单提示复杂度，提升专业化。代价是延迟、费用、调试难度上升。毕设单体 Agent + 工具往往够用，勿为炫技上多 Agent。

优先提示词与 RAG：成本低、可更新知识；数据稳定、格式固定、要改风格/领域用语再考虑微调或 LoRA。本科毕设多数不做全量微调，能说清取舍即可。

低秩适配：在冻结主模型上训练少量增量参数，降低微调成本。若未做，可说明了解概念，本项目以应用层为主。

1. 人工抽检正确率/满意度
2. RAG 检索命中率
3. 任务成功率（Agent 是否完成）
4. 延迟与成本
5. 安全拒答率

准备 10～20 条测试集比空口「效果很好」更有说服力。

边生成边返回，降低首字等待、体验更好。前端用 fetch/EventSource 渲染；注意中断、错误帧与完整结果落库。结合毕设说明是否做了打字机效果。

1. 压缩提示与历史轮数
2. 能 RAG 引用短片段就不要塞全文
3. 缓存相同问题
4. 小模型做分类/路由，大模型做生成
5. 限流与配额

用户通过恶意输入诱导模型忽略系统指令或套出隐藏提示。防护：输入过滤、工具权限隔离、不把密钥放提示词、关键操作不唯模型决定、输出再校验。

用户隐私脱敏、日志不落敏感原文、内容安全审核、版权与训练数据说明、明确「仅供参考」、高风险领域加人工审核。答辩准备免责声明文案。

说明厂商与型号、中文能力、价格、速率、是否支持工具调用/长上下文、国内访问稳定性。对比过备选方案更好；强调可替换设计（适配层），避免绑死一家。

统一 Chat/Embedding 接口，配置 API Key、base URL、模型名；差异（流式、工具格式）在适配器消化。毕设展示配置文件切换即可加分。

增量解析→分块→向量化→写入/更新索引；删除文档要同步删向量。可建文档版本号。说明你是否支持重新导入与失败重试。

保存近期消息窗口；超长则摘要压缩；用户长期偏好可结构化存储。勿无限追加历史。结合毕设：会话表字段与最大轮数。

返回答案同时返回 chunk 的文档名、页码/段落、相似度；前端角标可点击预览原文。提升可信度，也方便老师核验。

不要让模型直接拼 SQL。应：预置安全查询工具、参数化、只读账号、行级权限、结果行数限制。写操作必须人工确认。

如实列举：如检索知识库、查询订单接口、天气、计算器等。说明每个工具输入输出、失败处理，并现场演示 1～2 个调用链路。

超时重试、降级（规则回复/缓存答案）、熔断、友好提示「AI 暂不可用」。核心业务流程不应强依赖模型。

单元测工具与解析；集成测提示词+假接口；用固定测试集回归；对 JSON 输出做 schema 校验。随机性导致断言难，可测「结构合法+关键词命中」。

1. 流式输出改善体验
2. 缩小上下文
3. 并行检索
4. 换更快模型做简单任务
5. 缓存

可用 Ollama、vLLM 等本地推理，利：数据私有、无按次费；弊：机器要求、运维复杂、效果可能弱于商业 API。毕设用云 API 也可，说清数据是否出域。

维度由模型决定；常用余弦相似度，值越大越相近。检索取 TopK 后再交 LLM。注意不同 embedding 模型不可混用同一向量空间。

向量语义检索 + BM25/关键词检索融合，兼顾同义词与专有名词精确匹配。可用 Reciprocal Rank Fusion 等融合策略，适合专有术语多的领域知识库。

展示：自有知识库与引用、工具调用日志、后端编排代码、提示词版本、评测集、权限与会话落库。强调工程链路与业务结合，而非聊天窗口搬运。

业务场景定制（领域知识库）、Agent 工具与流程编排、评测与拒答策略、成本/延迟优化、人机协同审核。避免空讲「用了 GPT」本身当创新。

不足：幻觉未完全消除、评测集偏小、多模态未做、Agent 工具覆盖有限。展望：重排序、混合检索、人工反馈 RLHF/标注、可观测性仪表盘、更细权限。

承认模型可能有偏见与错误；产品定位辅助而非替代专业结论；用户知情同意；敏感场景人工复核。态度诚实、边界清晰。