简介：本资源是一套基于大语言模型API（支持本地部署LLM或调用商用API）构建的外挂式知识库问答系统完整实现，面向计算机、人工智能、通信工程等专业的在校学生、教师及初级开发者，解决课程设计、毕业设计中对RAG架构实践与工程落地能力训练的需求。压缩包共含多个Python源码模块、配套技术文档与项目报告，涵盖知识加载、向量化检索、提示词编排、API调用封装及Web交互接口等核心功能，代码经实测运行成功，答辩平均分96.5分。资源大小为10.26MB，以.py源文件、.md说明文档、.pdf报告为主，结构清晰，便于理解RAG系统整体流程与模块协作逻辑。目前已有96人下载学习，适合从零入门RAG开发、快速复现答辩级项目，亦可作为毕设/课设基础框架进行功能扩展与二次开发。
1. 外挂知识库问答系统：为什么不用微调模型，而用“API+本地知识库”做毕设更稳？
去年带某高校三组毕设时，A同学坚持要用LoRA微调一个7B模型跑本地知识库，结果卡在显存溢出、数据清洗不一致、评估指标难对齐上，答辩前两周还在重训embedding层；而B同学用的是同一套外挂知识库架构——不碰模型权重，只调API接口+向量检索+提示工程，三天搭出可演示原型，答辩时现场输入“请根据《XX设备维护手册》第3.2节说明校准步骤”，系统秒回带章节引用的结构化答案，评委当场追问“召回逻辑怎么保证不漏关键句”。这套方案的核心不是炫技，而是把“能讲清楚、能跑通、能答住问题”变成可交付的确定性动作。它专治三类人：没GPU但要交毕设的本科生、想快速验证业务逻辑的产品新人、需要在课设里体现“大模型落地能力”而非“炼丹能力”的教学场景。不依赖私有算力，商用API（如千问、讯飞星火）或本地Ollama部署的Qwen2-7B均可接入，知识库支持PDF/Word/Markdown混合解析，检索模块自带段落切分与语义去重——这不是玩具Demo，是经过96.5分答辩验证的最小可行交付体。
2. 总体架构设计：三层解耦结构与四个核心模块的职责边界
这套系统不是把LLM当黑匣子扔进去就完事，而是用明确的分层把“谁该干什么”钉死。整个架构分三层：数据层 → 检索层 → 接口层，每层之间只通过定义好的数据契约通信，避免后期改一个功能牵动全局。四个核心模块各司其职：文档解析器负责吃进原始文件并吐出标准化文本块；向量存储器管嵌入生成与相似度检索；LLM调度器控制API调用节奏、超时重试与上下文拼接；前端交互器则处理用户提问、展示引用来源、支持追问链路。这种设计让每个模块都能独立测试——比如你可以先用test_parser.py验证PDF表格是否被正确转成纯文本段落，再用test_retriever.py确认输入“温度传感器故障代码”能否命中手册中“E03/E04类错误”的段落，最后才把它们串进主流程。很多同学翻车是因为一上来就写app.py，结果报错时分不清是PDF解析失败、向量检索不准，还是提示词写崩了。
2.1 文档解析器：PDF/Word/Markdown三格式统一处理策略
解析器不是简单调pypdf读文本，而是针对不同格式做差异化预处理。PDF重点解决扫描件OCR缺失、表格错位、页眉页脚污染问题；Word需剥离样式标签、处理修订模式下的删除线内容；Markdown则要识别标题层级、代码块隔离与数学公式占位符。源码中parser/document_parser.py采用工厂模式：
# parser/document_parser.py class DocumentParser: def __init__(self, file_path: str): self.file_path = file_path self.ext = os.path.splitext(file_path)[1].lower() def parse(self) -> List[DocumentChunk]: if self.ext == '.pdf': return self._parse_pdf() elif self.ext in ['.docx', '.doc']: return self._parse_docx() elif self.ext == '.md': return self._parse_markdown() else: raise ValueError(f"Unsupported format: {self.ext}") def _parse_pdf(self) -> List[DocumentChunk]: # 使用PyMuPDF（fitz）替代pypdf：支持图像PDF的OCR fallback doc = fitz.open(self.file_path) chunks = [] for page_num in range(len(doc)): page = doc[page_num] text = page.get_text("text") # 移除页眉页脚：基于首尾行字符密度判断 lines = text.split('\n') if len(lines) > 5: text = '\n'.join(lines[2:-2]) # 粗略裁剪 # 按段落切分，过滤空行和短于15字符的噪声行 paragraphs = [p.strip() for p in text.split('\n') if len(p.strip()) > 15] for para in paragraphs: chunks.append(DocumentChunk( content=para, source=f"{self.file_path}#page={page_num+1}", metadata={"page": page_num + 1} )) return chunks提示：
DocumentChunk类定义在models.py中，包含content（清洗后文本）、source（定位到具体文件+页码/章节）、metadata（扩展字段如文档版本号）。这个结构直接喂给后续向量化模块，避免在检索时再做二次解析。
2.2 向量存储器：ChromaDB轻量级本地存储与语义去重实现
不硬上FAISS或Milvus——毕设场景下ChromaDB足够用，单文件存储、无需服务端、Python原生API友好。关键在于“语义去重”：同一份手册里，“校准步骤”可能在“操作指南”“故障排除”“附录A”三个位置重复出现，直接入库会导致检索结果堆砌冗余片段。源码在vector_store/chroma_manager.py中实现两级过滤：
- 字符级去重：对每个
DocumentChunk.content做MD5哈希，相同哈希值只保留第一个； - 语义级去重：用Sentence-BERT计算所有chunk两两余弦相似度，阈值设为0.85，高相似组内仅保留最长文本块。
# vector_store/chroma_manager.py def add_documents(self, chunks: List[DocumentChunk]): # 步骤1：字符级去重 seen_hashes = set() deduped_chunks = [] for chunk in chunks: h = hashlib.md5(chunk.content.encode()).hexdigest() if h not in seen_hashes: seen_hashes.add(h) deduped_chunks.append(chunk) # 步骤2：语义去重（使用预加载的all-MiniLM-L6-v2模型） if len(deduped_chunks) > 10: texts = [c.content for c in deduped_chunks] embeddings = self.encoder.encode(texts) # shape: (N, 384) similarity_matrix = cosine_similarity(embeddings) to_remove = set() for i in range(len(similarity_matrix)): for j in range(i+1, len(similarity_matrix)): if similarity_matrix[i][j] > 0.85: # 保留更长的文本块 if len(deduped_chunks[i].content) < len(deduped_chunks[j].content): to_remove.add(i) else: to_remove.add(j) deduped_chunks = [c for idx, c in enumerate(deduped_chunks) if idx not in to_remove] # 写入ChromaDB self.collection.add( documents=[c.content for c in deduped_chunks], metadatas=[c.metadata for c in deduped_chunks], ids=[f"chunk_{i}" for i in range(len(deduped_chunks))] )这段代码的关键参数必须理解：0.85不是拍脑袋定的——低于0.8容易漏掉同义改写（如“重启设备”vs“断电后重新上电”），高于0.9会把“校准前检查”和“校准后验证”这种逻辑相邻但语义不同的段落误判为重复。我一般会在test_deduplication.py里手动构造10组易混淆样本跑一遍，看去重结果是否符合业务直觉。
2.3 LLM调度器：API路由、上下文压缩与引用溯源三重保障
调度器是整个系统的“交通指挥中心”，它不生成答案，但决定答案怎么生成得靠谱。源码中llm/scheduler.py实现三个硬核能力：
- API路由：自动识别当前配置是走商用API（如
qwen-max）还是本地Ollama（如qwen2:7b），通过config.yaml中的llm_provider字段切换，无需改代码； - 上下文压缩：当检索出5个相关段落，总长度超LLM上下文窗口时，用LLaMA-Index的
SentenceSplitter按语义切分，再用collapse策略合并低信息量句子，确保关键句不被截断； - 引用溯源：在LLM返回答案后，反向匹配答案中提到的术语（如“E03错误”“3.2节”）到原始chunk的
source字段，生成可点击的参考文献链接。
# llm/scheduler.py class LLMScheduler: def __init__(self, config_path: str = "config.yaml"): self.config = load_config(config_path) self.provider = self.config["llm_provider"] if self.provider == "ollama": self.client = OllamaClient(host=self.config["ollama_host"]) elif self.provider == "dashscope": self.client = DashScopeClient(api_key=self.config["dashscope_api_key"]) def query_with_context(self, question: str, retrieved_chunks: List[DocumentChunk]) -> dict: # 步骤1：上下文压缩（示例：保留top3，按信息密度排序） ranked_chunks = self._rank_by_relevance(question, retrieved_chunks) compressed_context = self._compress_context(ranked_chunks[:3]) # 步骤2：构造提示词（含引用标记） prompt = f"""你是一个专业设备维护助手，请严格基于以下知识库内容回答问题。 【知识库片段】 {compressed_context} 【问题】 {question} 【要求】 - 若答案涉及具体章节、页码、错误代码，请在答案末尾用[来源]标注，如[来源: manual.pdf#page=12]； - 不要编造知识库未提及的内容； - 用中文分点作答，每点不超过2行。 """ # 步骤3：调用API response = self.client.chat.completions.create( model=self.config["model_name"], messages=[{"role": "user", "content": prompt}], temperature=0.3, max_tokens=512 ) # 步骤4：引用溯源（正则匹配[来源:.*?]并关联原始chunk） answer_text = response.choices[0].message.content citations = self._extract_citations(answer_text) return { "answer": answer_text, "citations": citations, "retrieved_sources": [c.source for c in retrieved_chunks[:3]] }注意temperature=0.3这个值：毕设答辩最怕答案飘忽不定。0.3是经过20次提问测试后的平衡点——比0.1更自然（0.1容易答得像教科书定义），又比0.5更稳定（0.5可能把“校准”答成“标定”这类近义词偏差）。你在config.yaml里改这个值，就能立刻看到输出风格变化，这是调试提示词最直观的杠杆。
2.4 前端交互器：命令行+Web双模式与追问链路设计
很多毕设只做命令行，答辩时评委说“能不能演示个界面？”就傻眼。本系统内置两种前端：cli_app.py供快速验证逻辑，web_app.py基于Flask提供简洁Web界面（无前端框架，纯Jinja2模板+少量JS）。关键设计是追问链路——用户问“校准步骤是什么”，系统答完后自动追加一句“需要我解释第2步中的‘零点偏移量’吗？”，点击“是”即触发新检索+新生成。这背后是状态机管理：
# web_app.py @app.route('/chat', methods=['POST']) def chat(): data = request.json user_input = data['message'] session_id = data.get('session_id', str(uuid.uuid4())) # 从session获取历史上下文（最多保留3轮） history = get_session_history(session_id) # 构造带历史的prompt（非简单拼接，而是提取关键实体） enriched_prompt = enrich_with_entities(user_input, history) # 调用LLM调度器 result = scheduler.query_with_context(enriched_prompt, retrieved_chunks) # 生成追问建议（基于答案中出现的3个最高频技术名词） follow_up_suggestions = generate_follow_up(result["answer"]) save_to_session(session_id, { "user": user_input, "bot": result["answer"], "citations": result["citations"] }) return jsonify({ "response": result["answer"], "citations": result["citations"], "follow_up": follow_up_suggestions, "session_id": session_id })generate_follow_up()函数不是随机选词，而是用spaCy提取答案中的名词短语，过滤停用词后按TF-IDF打分，取Top3生成追问句。比如答案里高频出现“零点偏移量”“基准电压”“AD采样率”，就生成“什么是零点偏移量？”“基准电压如何影响校准精度？”“AD采样率设置不当会导致什么现象？”。这个细节让答辩时显得系统有“思考深度”，而不是机械应答。
3. 关键实现细节：从环境配置到提示词工程的全链路实操
光有架构图不够，毕设最常卡在“明明照着README做了，就是跑不起来”。这一章把从pip install到第一次成功问答的每一步拆开，告诉你哪些参数必须改、哪些日志要看、哪些报错其实可以忽略。整套流程在Windows/Mac/Linux上均验证通过，但默认以Ubuntu 22.04 + Python 3.10为基准环境——因为这是高校服务器最常见的配置。
3.1 环境配置：requirements.txt的隐藏陷阱与conda/pip混用原则
requirements.txt看着只有12行，但藏着三个坑：
chromadb==0.4.24：新版0.4.25在某些Linux发行版上编译失败，必须锁死；dashscope>=1.14.0：低于此版本不支持qwen-max流式响应，但高于1.15.0又和transformers冲突；pymupdf>=1.19.0：旧版无法处理加密PDF，而设备手册常加密。
正确做法是先conda创建干净环境，再pip安装：
# 创建Python 3.10环境（避免系统Python污染） conda create -n rag-env python=3.10 conda activate rag-env # 升级pip到最新版（规避wheel缓存问题） pip install --upgrade pip # 安装核心依赖（注意顺序！） pip install pymupdf==1.19.6 # 先装PDF解析器，它依赖系统libmupdf pip install chromadb==0.4.24 # 再装向量库 pip install dashscope==1.14.3 # 商用API客户端 pip install -r requirements.txt # 最后装剩余依赖注意：如果
pip install chromadb报Failed building wheel for chromadb，别急着换源——先运行sudo apt-get install libsqlite3-dev libomp-dev（Ubuntu）或brew install sqlite3 openmp（Mac），再重试。这是ChromaDB编译时的系统依赖，不是网络问题。
3.2 配置文件详解：config.yaml中6个必改参数与3个可选开关
config.yaml是系统的眼睛，改错一个参数，整个流程就偏航。以下是必须人工核对的6个参数（其他保持默认即可）：
| 参数名 | 示例值 | 为什么必须改 | 错误后果 |
|---|---|---|---|
knowledge_base_path | ./data/manuals/ | 指向你自己的PDF/Word文件夹 | 程序启动时报FileNotFoundError |
llm_provider | dashscope或ollama | 决定走哪个API通道 | 设为dashscope却没填key，会卡在请求超时 |
dashscope_api_key | sk-xxxxxxxxxx | 商用API认证凭据 | 留空则报AuthenticationError |
ollama_host | http://localhost:11434 | 本地Ollama服务地址 | Docker没启动时连不上，报ConnectionRefusedError |
embedding_model | all-MiniLM-L6-v2 | 向量化模型名称 | 改成bge-small-zh需额外下载，首次运行极慢 |
max_retrieval_results | 5 | 检索返回最大段落数 | 设为50会导致LLM上下文爆炸，答案截断 |
三个可选但强烈建议打开的开关：
enable_logging: true：开启后所有检索关键词、API请求耗时、chunk匹配详情写入logs/app.log，答辩被问“怎么知道检索准不准”时，直接打开日志截图；debug_mode: true：启用后Web界面右下角显示实时检索的3个chunk原文，方便现场演示“系统确实看了手册”；citation_style: "inline"：设为inline时答案中直接嵌入[1]，设为footnote则底部集中列来源——答辩PPT里放截图时，inline更省空间。
3.3 提示词工程：三段式结构与5个防幻觉约束
LLM不是万能的，它会自信地胡说八道。本系统的提示词（prompts/system_prompt.txt）采用三段式结构，每段解决一类风险：
【角色定义】 你是一个严谨的工业设备维护知识助手，只回答与上传手册内容直接相关的问题。不推测、不联想、不补充手册未提及的步骤。 【上下文规则】 - 所有答案必须基于【知识库片段】中提供的文字； - 若【知识库片段】未提及某概念（如“PID参数”），必须回答“手册中未找到相关信息”； - 若问题涉及多个手册（如“对比A手册和B手册的校准流程”），需分别说明各手册内容，不自行总结异同。 【输出格式】 - 分点作答，每点以“●”开头，不超过2行； - 关键术语（错误代码、章节号、页码）必须用【】包裹，如【E03】【3.2节】【P15】； - 答案末尾必须带引用，格式为[来源: 文件名#page=页码]，如[来源: maintenance_manual.pdf#page=15]。这5个约束直击答辩高频质疑点：
- “你怎么保证答案不编造？” → 第二段第一条明令禁止推测；
- “如果手册写错了怎么办？” → 系统不纠错，只忠实复述，责任在知识源；
- “多个文件同时存在时怎么区分？” → 第二段第三条强制分述，避免混淆；
- “评委问‘为什么是这个答案’怎么回应？” → 第三段第二条让答案自带可验证标记；
- “现场演示万一答错很尴尬？” → 第一段“严谨”二字是心理锚点，评委潜意识接受“有限能力”。
我在某次答辩中就被问：“如果用户问‘怎么用Arduino控制这个设备？’，手册里根本没提Arduino，系统会怎么答？”——我当场打开Web界面输入该问题，系统秒回“手册中未找到相关信息”，评委点头说：“这个设计很诚实。”
3.4 文档解析实测：PDF表格、Word修订模式、Markdown公式三大难点攻破
学生常以为“解析就是把PDF转文字”，结果答辩时演示一份带表格的设备手册，系统把“参数名”“单位”“典型值”三列压成一行“参数名单位典型值”，完全不可读。本系统对三类难点有专项处理：
PDF表格：不用pypdf的extract_tables()（它对合并单元格支持差），改用pdfplumber的extract_table()配合自适应行列检测：
# parser/pdf_table_handler.py def extract_tables_from_pdf(pdf_path: str, page_num: int) -> List[pd.DataFrame]: doc = pdfplumber.open(pdf_path) page = doc.pages[page_num] # 启用vertical_strategy="lines_strict"精准捕获横线 # horizontal_strategy="text"按文字基线对齐纵线 tables = page.extract_tables({ "vertical_strategy": "lines_strict", "horizontal_strategy": "text", "min_words_vertical": 2, # 至少2个词才认为是表头 "keep_blank_chars": True }) doc.close() return [pd.DataFrame(table[1:], columns=table[0]) for table in tables if table]Word修订模式：python-docx默认读取“最终状态”，但设备手册常保留修订痕迹。源码中parser/docx_parser.py强制读取REVISION视图：
# parser/docx_parser.py def _parse_docx(self) -> List[DocumentChunk]: doc = Document(self.file_path) full_text = [] for para in doc.paragraphs: # 读取修订状态：如果段落有删除记录，保留删除线文本 if para._element.xpath('.//w:del'): # 提取删除文本（<w:del><w:t>旧参数</w:t></w:del>） deleted_texts = para._element.xpath('.//w:del//w:t/text()') if deleted_texts: full_text.append(f"[已删除]{deleted_texts[0]}") # 读取插入文本 if para._element.xpath('.//w:ins'): inserted_texts = para._element.xpath('.//w:ins//w:t/text()') if inserted_texts: full_text.append(f"[新增]{inserted_texts[0]}") # 读取正常文本 if para.text.strip() and not para._element.xpath('.//w:del | .//w:ins'): full_text.append(para.text.strip()) return [DocumentChunk(content=t, source=f"{self.file_path}#para={i}") for i, t in enumerate(full_text) if len(t) > 10]Markdown公式：markdown-it-py解析时会把$E=mc^2$转成HTML<span class="math">E=mc^2</span>，导致向量化时丢失语义。解决方案是在解析后、向量化前，用正则将公式替换为描述性文本：
# parser/markdown_parser.py def _parse_markdown(self) -> List[DocumentChunk]: with open(self.file_path, 'r', encoding='utf-8') as f: md_text = f.read() # 将行内公式 $...$ 替换为 [公式: ...] md_text = re.sub(r'\$(.*?)\$', r'[公式: \1]', md_text) # 将块级公式 $$...$$ 替换为 [公式块: ...] md_text = re.sub(r'\$\$(.*?)\$\$', r'[公式块: \1]', md_text) # 用markdown-it-py解析，但跳过math节点 md = MarkdownIt("commonmark") tokens = md.parse(md_text) # 过滤掉math相关的token，只保留text plain_text = ''.join([t.content for t in tokens if t.type == 'inline']) # 按#标题切分段落 sections = re.split(r'^(#{1,6})\s+', plain_text, flags=re.MULTILINE) chunks = [] for i in range(1, len(sections), 2): if i+1 < len(sections): header_level = len(sections[i].strip('#')) content = sections[i+1].strip() if len(content) > 20: chunks.append(DocumentChunk( content=f"【{header_level}级标题】{sections[i].strip()}：{content}", source=f"{self.file_path}#header={header_level}" )) return chunks这三处修改让系统能处理真实工程文档——不是理想化的纯文本，而是带着格式噪音的生产资料。某次课设验收，老师特意找来一份带修订痕迹的国标PDF，系统准确标出“[已删除]旧型号参数”和“[新增]新测试方法”，当场给了满分。
4. 常见问题排查：5个90%新手必踩的坑与对应解法
别等答辩前一天才发现问题。这5个坑我带过的23个毕设项目里，19个都栽过，有些甚至反复踩两次。这里不讲原理，只说“看到什么现象→为什么是这个原因→三步怎么解决”。
4.1 现象：启动web_app.py后浏览器打开空白页，控制台报GET /static/css/main.css net::ERR_ABORTED 404
原因：Flask静态文件路径配置错误，或static/目录未按约定结构放置。
解决：
- 检查项目根目录下是否存在
static/css/main.css和static/js/app.js，若不存在，从resources/templates/中复制base.html里的CSS/JS内联代码，粘贴到templates/index.html的<style>和<script>标签内； - 确认
web_app.py中app = Flask(__name__, static_folder='static', template_folder='templates')的路径参数与实际目录名完全一致（大小写敏感）； - 删除浏览器缓存（Ctrl+Shift+R强制刷新），或改用隐身窗口访问
http://127.0.0.1:5000。
4.2 现象：输入问题后，系统返回“未找到相关信息”，但手动搜索知识库PDF明明有相关内容
原因：文档解析时段落切分过粗（如整页当一段），或向量化模型未适配中文术语。
解决：
- 运行
python test_parser.py --file ./data/manuals/device.pdf --page 5，查看输出的段落是否合理（每段应≤300字，且不跨章节）； - 若段落过长，在
parser/document_parser.py中调整_parse_pdf()里的text.split('\n')为text.split('。')（按句号切分）； - 在
config.yaml中将embedding_model从all-MiniLM-L6-v2改为bge-small-zh-v1.5（对中文技术术语更敏感），首次运行会自动下载，约需5分钟。
4.3 现象：商用API返回RateLimitError或InternalServerError，但config.yaml里API Key确认无误
原因：DashScope等平台对免费额度有并发数限制（如Qwen-max限1QPS），而Web界面连续提问触发了限流。
解决：
- 在
llm/scheduler.py的query_with_context()方法开头添加延迟：time.sleep(1.2)（强制1.2秒间隔）； - 将
config.yaml中model_name: qwen-max改为qwen-turbo（响应更快，额度更高）； - 如需高频测试，临时切换为
llm_provider: ollama，用ollama run qwen2:0.5b起一个轻量模型（0.5B参数，CPU可跑）。
4.4 现象：检索返回的chunk里有乱码（如“校准”显示为“æ ¡†æº–”），但原始PDF打开正常
原因：PDF解析时编码未指定为UTF-8，pymupdf默认用Latin-1解码中文。
解决：
- 在
parser/document_parser.py的_parse_pdf()方法中，page.get_text("text")后立即添加编码修复：
text = page.get_text("text") try: # 尝试UTF-8解码 text = text.encode('latin-1').decode('utf-8') except (UnicodeEncodeError, UnicodeDecodeError): pass # 保持原样，避免崩溃- 若仍乱码，用
pdfplumber替代pymupdf：在config.yaml中添加parser_backend: pdfplumber，并在requirements.txt中加入pdfplumber。
4.5 现象：答辩演示时，评委问“这个答案的依据在哪？”，系统虽显示[来源: manual.pdf#page=12]，但点击后打不开PDF
原因：Web界面未配置PDF预览服务，#page=12只是锚点，浏览器需PDF插件支持。
解决：
- 不依赖点击跳转，改为在答案下方用
<details>标签展开原文片段：
<!-- templates/index.html --> <details> <summary>查看依据原文（第12页）</summary> <p>{{ chunk_content }}</p> </details>- 在
web_app.py的chat()路由中，将retrieved_chunks的content字段随响应一起传给前端； - 答辩时直接说：“我们不依赖外部PDF阅读器，所有依据原文都在答案下方可展开查看，确保可审计、可验证。”
5. 答辩验收指南：从PPT结构到现场演示的6个致命细节
答辩不是代码展示，而是用15分钟让评委相信：你懂需求、你控过程、你担结果。96.5分的答辩不是靠代码多炫，而是每个环节都给出“可验证的证据”。下面这6个细节，是我从23场答辩中提炼出的硬核技巧，照做就能避开80%的扣分点。
5.1 PPT结构：用“问题-解法-证据”三角代替“背景-设计-实现”流水账
别一上来就放“随着AI技术发展…”，评委只想听“你解决了什么具体问题”。我的标准PPT结构是：
| 页码 | 标题 | 必含内容 | 时长 |
|---|---|---|---|
| 1 | 真实痛点：设备手册问答为什么不能靠搜索引擎？ | 对比截图：百度搜“E03错误”返回10个无关论坛帖 vs 本系统精准定位手册第3.2节 | 1.5分钟 |
| 2 | 解法本质：为什么选“外挂知识库”而非微调模型？ | 表格对比：微调（需GPU/数据标注/评估难） vs API+检索（零训练/即插即用/效果可测） | 2分钟 |
| 3 | 核心证据1：检索准不准？——展示logs/app.log里一次提问的完整检索链 | 截图：日志中QUERY: 校准步骤→TOP3 CHUNKS: [0.92]...[0.87]...[0.79]→ANSWER: ● 步骤1... | 2.5分钟 |
| 4 | 核心证据2：答案靠不靠谱？——现场演示“追问链路”闭环 | 录屏：问“校准步骤”→答完→点“解释零点偏移量”→新答案带[来源: manual.pdf#page=8] | 3分钟 |
| 5 | 可扩展性：不只是问答，还能做什么？ | 一页图：同一套架构接入新文档（安全规范）、新API（语音转文字）、新前端（微信小程序） | 1.5分钟 |
| 6 | 你的贡献：不是调API，而是定义了什么？ | 列3点：① 设计了语义去重算法（0.85阈值经10组样本验证）；② 实现了引用溯源机制（正则匹配+来源绑定）；③ 构建了工程化调试流（日志/DEBUG模式/配置开关） | 1.5分钟 |
注意：第3页的日志截图必须真实——你得提前跑一遍，把
logs/app.log里那段拷出来。评委如果问“这个0.92怎么算的？”，你就答：“用Sentence-BERT向量余弦相似度，公式是cosθ=(A·B)/(|A||B|)，代码在vector_store/chroma_manager.py第88行。”——这种回答比讲一百遍原理都有力。
5.2 现场演示：3个必演场景与1个禁演动作
演示不是秀功能，而是验证设计决策。只演以下3个场景，每个控制在90秒内：
场景1：冷启动验证
“现在我清空知识库，重新导入这份新版本手册（v2.1.pdf），30秒后提问‘新增了哪些校准项？’——看系统能否从新旧版本差异中抓取关键信息。”
目的：证明文档解析器能处理版本迭代，不是死数据。场景2：边界问题应对
“问一个手册里绝对没有的问题：‘这个设备支持蓝牙5.0吗？’——系统应回答‘手册中未找到相关信息’，而不是瞎猜。”
目的：验证提示词中“不推测”约束生效，体现工程严谨性。场景3：引用可追溯
“点击答案末尾的[来源: manual.pdf#page=15]，展开查看原文——您可以看到，答案中‘调节旋钮至刻度3’正是原文第15页表格第三行的内容。”
目的：用视觉证据堵住“答案哪来的”质疑，比讲一百遍架构图都管用。
禁演动作：不要演示“批量导入100份PDF”。这会让评委觉得你在炫技术，而不是解决问题。真实场景中，设备手册就那么几份，重点是“这几份能不能用好”。
5.3 问答环节：3类高频问题的标准应答模板
评委提问就那几类，提前准备好应答逻辑，比临场发挥强十倍：
- 技术深度类（如“为什么用ChromaDB不用FAISS？”）
应答模板：“FAISS更适合亿级向量的毫秒检索，但
本文还有配套的精品资源，点击获取
