Prompt链工程：构建可追溯、可审计的AI文档处理流水线

1. 项目概述：从“读不完的文档”到一键提取核心信息的实战路径

你有没有过这种体验：邮箱里躺着一份87页的行业白皮书PDF，会议前30分钟才收到；客户甩来一个200MB的会议录音转文字稿，要求“提炼出所有技术风险点”；或者手头有一堆零散的调研访谈记录，需要在下午两点前交出一份带结论的简报——而你现在连第一页都没看完。这不是时间管理问题，是信息处理能力的结构性瓶颈。我做技术文档自动化处理项目整整七年，经手过金融尽调报告、医疗临床试验摘要、政府招标文件、科研论文综述等上百类长文本场景，发现一个铁律：真正卡住效率的，从来不是模型能不能 summarize，而是“让模型知道该 summarize 什么”这件事本身，比写 summary 还难十倍。这个项目，就是我用三年时间踩坑、重构、再验证后沉淀下来的整套工程化方法论。它不叫“AI summarizer”，我管它叫“Summarizer Almighty”——不是因为它多强大，而是因为它能像老练的编辑一样，先判断文本类型、再识别用户真实意图、再动态拆解任务链、最后组合输出。核心关键词Chatgpt在这里不是指某个具体模型API，而是代表一类具备强推理与指令遵循能力的大语言模型，我们把它当作可编程的“认知协作者”，而非黑箱工具。整套方案完全基于公开可用的开源模型与标准Web技术栈实现，不依赖任何闭源服务或特殊算力，一台16GB内存的MacBook Pro就能跑通全流程。适合三类人直接抄作业：需要快速处理业务文档的非技术岗（如产品经理、咨询顾问、法务）；想把AI能力嵌入现有工作流的开发者；以及正在设计AI原生应用的产品经理。它解决的不是“怎么调API”，而是“怎么让AI真正听懂人话，并且不犯低级错误”。

2. 整体架构设计与Prompt链工程原理拆解

2.1 为什么必须放弃“单Prompt打天下”的幻想？

刚接触大模型时，我试过最朴素的方案：把整篇《2024年全球半导体产业政策分析报告》（PDF共142页，纯文本约32万字）直接喂给模型，加一句“请用300字总结核心观点”。结果？模型确实输出了300字，但内容全是报告前言里泛泛而谈的“技术发展日新月异”，完全漏掉了第三章表格里列出的7项关键出口管制清单变更——而这恰恰是客户最关心的风险点。问题出在哪？不是模型能力不足，而是我们犯了典型的“认知错配”：人类阅读长文档是分层扫描的——先看标题结构判断价值，再跳读小节标题定位重点，最后精读关键段落验证细节；而单Prompt模式强行要求模型一次性完成“全局理解+重点识别+逻辑压缩+语言重述”四重高阶认知操作，相当于让一个没看过菜单的人直接给你点一桌满汉全席。这就像让一个刚学会加减法的小学生，立刻解一道微分方程。Prompt链的本质，是把人类专家的思维过程显性化、模块化、可调度。我们不是在教模型“怎么总结”，而是在构建一条“认知流水线”：上游模块负责“侦查”（识别文档类型、提取结构化元数据），中游模块负责“研判”（根据用户问题动态生成检索策略），下游模块负责“执行”（精准提取、对比、归纳）。每个环节只承担单一认知负荷，错误率自然下降。

2.2 四层Prompt链架构：从文档解析到答案生成

整个系统严格划分为四个逻辑层，每层对应一个独立的Prompt模块，通过结构化中间产物传递信息，彻底规避“上下文污染”。这个设计经过23个真实业务场景压力测试，平均任务成功率从单Prompt的41%提升至92.7%。下面逐层拆解其不可替代性：

第一层：Document Profiler（文档画像师）
输入：原始文本（支持PDF/DOCX/TXT，经预处理为纯文本流）
输出：JSON格式的文档结构画像，包含5个强制字段：

• doc_type：自动识别为“技术白皮书”、“法律合同”、“会议纪要”、“学术论文”、“新闻稿”五类之一（基于标题密度、条款编号、引用格式等12个特征）
• key_sections：返回3-5个高价值章节名及起始字符位置（如“[3.2 出口管制清单变更] @char_pos: 12489”）
• entity_density：统计人名、机构名、产品型号、法规编号出现频次（用于后续问题匹配）
• tone_score：0-10分量化文本正式度（基于被动语态占比、长句比例、术语密度）
• risk_indicators：布尔值数组，标记是否含“违约”、“赔偿”、“不可抗力”、“审计”等18类风控关键词

提示：这一层绝不允许输出任何summary或观点！它的唯一使命是“客观描述”，就像法医出具尸检报告。我曾因在Profiler Prompt里加了一句“请简要说明文档主旨”，导致后续所有模块都受其主观引导而偏航——这是新手最容易栽的坑。

第二层：Intent Interpreter（意图翻译官）
输入：用户原始提问（如“这个合同里甲方有哪些免责条款？”） + Document Profiler输出的JSON
输出：结构化任务指令包（Task Spec），含3个核心字段：

• task_type：明确为“条款定位”、“数据提取”、“对比分析”、“因果推断”四类之一（避免模型自由发挥）
• target_section：指向第一层输出的key_sections中的具体章节（如“[4.1 免责条款]”）
• extraction_rules：用自然语言写的精准提取规则（如“仅提取以‘甲方不承担’开头的完整句子，忽略所有条件状语从句”）

这一层的关键在于“约束即自由”。比如用户问“项目风险有哪些？”，我们绝不让它自由列举，而是强制转换为：“在risk_indicators标记为True的章节中，提取所有以‘风险’、‘隐患’、‘挑战’为句首名词的完整句子，每句不超过25字”。实测表明，加入明确的句式约束后，关键信息遗漏率下降63%。

第三层：Contextual Extractor（上下文挖掘机）
输入：Task Spec + 原始文本（按target_section定位后的子文本）
输出：纯文本块列表，每个块严格满足extraction_rules，并附带来源坐标（如“[p12, para3, line2]”）
此模块的核心技巧是“锚点定位法”：先用正则匹配extraction_rules中的关键词（如“甲方不承担”），再向前回溯至最近的句号/换行符，向后延伸至下一个句号/换行符，确保截取的是完整语义单元。我们刻意避免使用“top_k sentences”这类模糊策略，因为模型对“相关性”的判断常与人类预期错位。

第四层：Synthesizer（合成指挥官）
输入：Extractor输出的文本块列表 + Task Spec中的task_type
输出：最终用户可见的答案，格式严格匹配task_type：

• 若task_type为“条款定位”，则输出带原文标注的条款清单（如“① 甲方不承担因乙方擅自修改系统配置导致的数据丢失责任 [p12, para3]”）
• 若为“对比分析”，则强制采用表格形式（左列原文A条款，右列原文B条款，中间列差异说明）
• 若为“因果推断”，则必须包含“前提→机制→结果”三段式结构，且每段引用具体坐标

注意：Synthesizer的Prompt里有一条铁律——“禁止生成任何未在Extractor输出中出现的实体或事实”。这堵住了模型“幻觉”的主要通道。我们宁可输出“未找到符合要求的条款”，也不要一段看似合理实则编造的内容。

2.3 工程化落地的关键取舍：为什么不用RAG？

很多同行第一反应是上RAG（检索增强生成），但我坚持用纯Prompt链方案，原因很实在：RAG在长文档场景下存在三个硬伤，而我们的业务场景恰好撞在枪口上。第一，RAG依赖向量检索，而法律合同、技术规格书这类文本充满专业缩写（如“FCC Part 15 Subpart B”）、数字编号（“Clause 8.2.1”）、符号组合（“≥99.999% uptime”），传统embedding模型对这些token的语义捕捉极差，检索结果常驴唇不对马嘴。第二，RAG的chunking策略（按固定长度切分）会暴力撕裂关键条款——比如“违约责任”条款常跨两页，chunking后变成两个残缺片段，模型根本无法理解完整逻辑。第三，也是最致命的，RAG的检索结果缺乏可解释性。当客户追问“为什么认定这条是免责条款？”，我们无法像Prompt链这样清晰回溯到“Document Profiler识别出本节标题含‘免责’，Intent Interpreter将问题映射至此，Extractor按‘甲方不承担’锚点精准捕获”。Prompt链的每一次输出都是可审计、可追溯、可修正的认知快照，而RAG给出的是一团概率云。当然，我们并非排斥RAG，在需要跨文档关联的场景（如比对10份不同年份的采购合同），我们会用Prompt链先完成单文档深度解析，再将结构化结果注入RAG进行横向分析——这是混合架构的务实选择。

3. 核心模块实现与关键技术细节

3.1 Document Profiler：如何让模型“读懂”文档类型？

文档类型识别是整个链条的地基，错误识别会导致后续所有环节南辕北辙。我们不用训练专用分类器，而是用一套精心设计的少样本Prompt，配合结构化输出约束。关键在于特征工程前置到Prompt中，而非依赖模型隐式学习。以下是实际部署的Prompt核心片段（已脱敏）：

你是一个专业的文档分析师，任务是为上传的文本生成精确的结构画像。请严格按以下JSON Schema输出，不得添加任何额外字段或解释： { "doc_type": "string enum: 技术白皮书|法律合同|会议纪要|学术论文|新闻稿", "key_sections": [ { "section_name": "string, 精确匹配原文小节标题（含编号）", "char_position": "integer, 该标题在全文中的起始字符位置" } ], "entity_density": { "person_names": "integer count", "org_names": "integer count", "product_codes": "integer count", "regulation_refs": "integer count" }, "tone_score": "float 0.0-10.0", "risk_indicators": ["string array of 18 predefined terms"] } 【分析依据】 - 技术白皮书：标题含“白皮书”“技术规范”“Implementation Guide”，含大量“Figure X.Y”“Table X.Y”引用 - 法律合同：含“甲方/乙方”“第X条”“本协议”“生效日期”“签字页”，条款编号格式为“X.X.X” - 会议纪要：含“参会人员：”“会议时间：”“决议事项：”“待办事项：”，时间戳格式为“YYYY-MM-DD HH:MM” - 学术论文：含“Abstract”“Introduction”“Methodology”“References”，参考文献格式为“[1] Author, Title...” - 新闻稿：含“本报讯”“据XX报道”“记者XXX”，导语含“谁在何时何地做了什么” 【强制规则】 1. 若文档含超过3处“第X条”且含“甲方/乙方”，无论其他特征，doc_type必须为“法律合同” 2. 若文档含“References”章节且参考文献数量≥15，doc_type必须为“学术论文” 3. section_name必须完全复制原文标题（包括空格和标点），不得改写

这个Prompt的威力在于把领域知识编码为硬性规则。比如“强制规则1”就封死了模型把一份带条款编号的采购订单误判为“技术白皮书”的可能。实测在500份混合文档测试集上，类型识别准确率达98.2%，远超微调BERT模型的91.5%。更关键的是，它不需要训练数据——新出现的文档类型（如“ESG可持续发展报告”），只需在Prompt里补充几行特征描述，当天就能上线。

3.2 Intent Interpreter：从模糊提问到可执行指令的翻译艺术

用户提问天然带有歧义，比如“帮我看看这个合同有什么问题？”。这根本不是有效指令，而是情绪宣泄。我们的解决方案是双阶段意图澄清：第一阶段用轻量级Prompt做初步分类，第二阶段用交互式追问补全关键约束。整个流程在Web前端无缝完成，用户无感知。

第一阶段Prompt（轻量级分类）：
输入：用户原始提问 + Document Profiler输出的doc_type
输出：task_type+confidence_score（0-1）
Prompt核心逻辑是穷举高频歧义模式：

• 若提问含“风险”“隐患”“漏洞”“问题”，且doc_type为“法律合同”，则task_type="条款风险扫描"
• 若提问含“总结”“概括”“要点”，且doc_type为“会议纪要”，则task_type="决议事项提取"
• 若提问含“对比”“差异”“相同点”，则强制进入第二阶段

第二阶段（交互式澄清）：
当confidence_score< 0.85 或task_type为“对比分析”时，前端自动弹出3个选项式追问：

1. “您想对比哪两部分内容？（请选择）
   □ 合同版本A与版本B
   □ 甲方义务条款与乙方义务条款
   □ 当前条款与行业标准模板”
2. “对比维度侧重哪些方面？（可多选）
   □ 权利义务分配
   □ 违约责任设定
   □ 争议解决方式”
3. “是否需要标注具体条款位置？”（是/否）

这个设计源于一个血泪教训：曾有客户提问“这个技术方案和竞品有什么区别？”，我们按常规理解去对比功能参数，结果交付后被告知他真正想比的是“两家公司的专利布局覆盖度”。交互式澄清不是增加步骤，而是把用户脑中模糊的“需求图谱”显性化为可执行的坐标。所有追问选项都来自我们积累的217个真实失败案例，确保覆盖99.3%的歧义场景。

3.3 Contextual Extractor：锚点定位法的工程实现

Extractor模块的成败取决于能否在噪声文本中精准捕获目标语义单元。我们放弃通用NLP库（如spaCy的句子分割），自研了一套基于正则与上下文窗口的锚点定位引擎。核心算法如下：

def extract_by_anchor(text: str, anchor_pattern: str, context_window: int = 150) -> List[str]: """ anchor_pattern: 如 r'甲方不承担.*?[^。！？；]*[。！？；]' context_window: 向前/向后扩展的最大字符数 """ results = [] # 第一步：用正则找到所有anchor匹配位置 for match in re.finditer(anchor_pattern, text, re.DOTALL): start, end = match.span() # 第二步：向前找最近的句子边界（句号/换行/冒号后空格） sentence_start = start for i in range(max(0, start - context_window), start): if text[i] in '。！？；\n' or (i > 0 and text[i-1:i+1] == ': '): sentence_start = i + 1 break # 第三步：向后找最近的句子边界 sentence_end = end for i in range(end, min(len(text), end + context_window)): if text[i] in '。！？；\n': sentence_end = i + 1 break # 第四步：截取并清洗（去除首尾空白、合并多余空格） sentence = text[sentence_start:sentence_end].strip() if len(sentence) > 10: # 过滤过短碎片 results.append(sentence) return results

这个算法的精妙之处在于用正则锚定语义核心，用上下文窗口保障语义完整。比如匹配“甲方不承担”，正则r'甲方不承担.*?[^。！？；]*[。！？；]'确保捕获到句末标点，而context_window=150防止跨段落误抓。我们测试过，对法律条款这类高密度文本，准确率94.7%，而直接用LLM提取的准确率仅68.3%（模型常把“甲方不承担”和后面“但乙方应保证...”连成一句，扭曲原意）。更重要的是，这套算法完全不依赖模型，纯Python实现，响应速度<50ms，可作为预处理服务独立部署。

3.4 Synthesizer：结构化输出的强制约束机制

Synthesizer模块的Prompt设计贯彻一个原则：用输出格式反向控制生成逻辑。我们不告诉模型“该怎么想”，而是用JSON Schema定义“必须产出什么”。以下是“条款定位”任务的Synthesizer Prompt核心：

你是一个严谨的法律文书助理，任务是将Extractor提供的条款文本块，按指定格式合成最终答案。请严格遵守： 1. 输出必须是纯Markdown，无任何解释性文字 2. 每个条款必须编号（① ② ③...），编号后紧跟原文，原文后紧跟来源坐标 3. 坐标格式必须为 [pX, paraY, lineZ]，其中X=页码，Y=段落序号，Z=行号（均从1开始） 4. 若Extractor返回空列表，输出“未在文档中找到符合要求的条款” 【输入】 - Task Type: 条款定位 - Extractor Output: ["甲方不承担因乙方擅自修改系统配置导致的数据丢失责任", "甲方不承担非因甲方原因造成的第三方服务中断责任"] - Source Coordinates: ["[p12, para3, line2]", "[p15, para1, line5]"] 【输出示例】 ① 甲方不承担因乙方擅自修改系统配置导致的数据丢失责任 [p12, para3, line2] ② 甲方不承担非因甲方原因造成的第三方服务中断责任 [p15, para1, line5]

这个设计的威力在于把模型的创造性转化为格式服从性。我们测试过，当去掉“必须编号”“必须坐标”等硬约束时，模型有37%概率自行添加解释性语句（如“以上条款明确了甲方的责任边界”），而这恰恰是客户最反感的“AI废话”。强制结构化输出后，不仅结果干净，还天然支持前端自动解析——坐标信息可直接链接到PDF原文高亮，形成闭环体验。

4. Web应用开发与端到端实操流程

4.1 技术栈选型：为什么选择Flask而非FastAPI？

在框架选型上，我们放弃当前更热门的FastAPI，坚定选择Flask，原因直指业务本质：我们的核心复杂度不在API性能，而在前端交互逻辑与状态管理。FastAPI的异步优势在文档解析这类IO密集型任务中收益甚微（瓶颈在PDF解析和模型调用），反而增加了调试难度。而Flask的轻量级和灵活性，让我们能深度定制请求生命周期。比如，我们实现了“渐进式响应”中间件：当用户上传PDF后，后端不是等待全部处理完成才返回，而是分三阶段推送事件：

1. {"status": "parsing", "progress": 35}（PDF文本提取中）
2. {"status": "profiling", "progress": 72}（Document Profiler运行中）
3. {"status": "ready", "result_url": "/result/abc123"}（最终结果就绪）

这个中间件用Flask的stream_with_context轻松实现，而FastAPI的StreamingResponse在处理多阶段状态推送时需额外引入WebSocket，徒增复杂度。另一个关键考量是部署成本：Flask应用打包成Docker镜像仅87MB，而同等功能的FastAPI镜像因依赖更多异步库达210MB，在边缘计算节点（如客户私有云）部署时，启动时间相差4.2秒——这对追求“秒级响应”的用户体验至关重要。

4.2 前端交互设计：降低用户认知负荷的三大实践

Web界面的设计哲学是“让用户感觉不到AI的存在”。我们砍掉了所有炫技元素，聚焦三个核心交互点：

第一，智能文件预览区
用户上传PDF后，前端不显示原始二进制，而是调用PDF.js即时渲染首屏，并叠加一层半透明蒙版，上面用SVG绘制出Document Profiler识别出的key_sections位置热区（如“[3.2 出口管制清单变更]”区域高亮为蓝色）。用户鼠标悬停热区，即显示该章节的entity_density摘要（如“含7个法规编号，3个产品型号”）。这解决了用户最大困惑：“这个文档到底讲什么？值得花时间看吗？”

第二，意图引导式提问框
取代传统搜索框，我们设计了一个带上下文感知的提问助手。当用户聚焦输入框时，自动弹出提示：

• 若doc_type为“法律合同”：“试试问：甲方有哪些免责条款？乙方的付款义务是什么？”
• 若doc_type为“会议纪要”：“试试问：会议确定了哪些待办事项？谁负责跟进？”
• 若doc_type为“技术白皮书”：“试试问：核心架构图在哪里？关键性能指标有哪些？”
  这些提示词全部来自真实用户提问日志的TOP100，确保100%命中用户真实需求场景。

第三，结果卡片的“溯源穿透”设计
每条输出结果下方，固定显示一行小字：← 查看原文 | 编辑提取规则 | 反馈错误。点击“查看原文”直接滚动到PDF对应位置并高亮；点击“编辑提取规则”弹出Intent Interpreter的澄清面板，允许用户实时调整extraction_rules（如把“甲方不承担”改为“甲方免除”）；点击“反馈错误”则收集错误样本用于模型迭代。这个设计让AI不再是黑箱，而是可对话、可修正的协作者。

4.3 端到端实操：从上传PDF到获取结构化答案

下面以一份真实的《某云计算服务商SLA协议（2024版）》为例，演示完整流程。该PDF共48页，含127处“可用性”相关表述，用户提问：“协议中定义的各服务等级指标（SLI）及其对应的可用性承诺（SLO）是什么？”

Step 1：PDF解析与文本流生成
后端调用PyMuPDF（fitz）提取文本，关键优化：

• 启用textpage = page.get_textpage()而非page.get_text()，保留原始排版结构
• 对表格区域单独处理：page.find_tables()提取为CSV，再转为Markdown表格嵌入文本流
• 过滤页眉页脚：基于字体大小和位置阈值（字号<8pt且y坐标<50px的文本块）
  耗时：2.3秒（MacBook Pro M1）

Step 2：Document Profiler执行
输入文本流，输出JSON画像：

{ "doc_type": "法律合同", "key_sections": [ {"section_name": "3.2 服务等级指标（SLI）", "char_position": 12489}, {"section_name": "3.3 可用性承诺（SLO）", "char_position": 15672} ], "entity_density": {"regulation_refs": 0, "product_codes": 12, "org_names": 2}, "tone_score": 8.7, "risk_indicators": ["违约", "赔偿", "审计"] }

耗时：1.8秒（调用Chatgpt API，temperature=0.1）

Step 3：Intent Interpreter执行
输入用户提问+上述JSON，输出Task Spec：

{ "task_type": "数据提取", "target_section": "3.2 服务等级指标（SLI）", "extraction_rules": "提取所有形如'SLI名称：[名称]，测量方式：[方式]，目标值：[值]'的完整句子，忽略所有注释性文字" }

耗时：0.9秒

Step 4：Contextual Extractor执行
在target_section文本中执行锚点定位，返回：

• "SLI名称：API响应延迟，测量方式：P95延迟，目标值：≤200ms"
• "SLI名称：数据持久性，测量方式：对象存储损坏率，目标值：≤0.0000001%"
• "SLI名称：网络吞吐量，测量方式：峰值带宽，目标值：≥10Gbps"
  耗时：0.3秒（纯Python）

Step 5：Synthesizer执行
按JSON Schema生成最终输出：

① SLI名称：API响应延迟，测量方式：P95延迟，目标值：≤200ms [p12, para2, line1] ② SLI名称：数据持久性，测量方式：对象存储损坏率，目标值：≤0.0000001% [p13, para1, line4] ③ SLI名称：网络吞吐量，测量方式：峰值带宽，目标值：≥10Gbps [p14, para3, line2]

耗时：0.7秒

总耗时：6.0秒，全程用户可见进度条，无卡顿感。关键是，每一步的输出都可独立验证——用户可点击任意结果的坐标，瞬间跳转到PDF原文，亲眼确认提取无误。这种“所见即所得”的信任感，是任何黑箱AI应用无法替代的核心价值。

5. 实战避坑指南与常见问题排查

5.1 文档预处理的五大隐形杀手

即使Prompt链设计完美，糟糕的文本预处理也会让一切归零。我们在200+文档测试中总结出必须规避的五大陷阱：

陷阱1：PDF文本层错位（发生率38%）
现象：OCR识别的PDF中，文字顺序与视觉顺序不一致（如表格中“价格”列文字跑到“产品”列下方）。
解决方案：启用PyMuPDF的sort=True参数，强制按y坐标排序；对疑似表格区域，改用page.find_tables()提取结构化数据，而非依赖文本流。

实操心得：我们专门写了检测脚本，对每个PDF计算“文本坐标混乱度”（相邻字符y坐标差值的标准差），>5.0即触发表格专用解析流程。

陷阱2：Unicode编码污染（发生率22%）
现象：中文PDF中混入零宽空格（U+200B）、软连字符（U+00AD）等不可见字符，导致正则匹配失败。
解决方案：预处理时统一执行text.replace('\u200b', '').replace('\u00ad', '')，并用unicodedata.normalize('NFKC', text)标准化全角标点。

踩过的坑：曾因一个U+FEFF（BOM）字符，导致Document Profiler把整篇合同误判为“乱码文档”，排查耗时3小时。

陷阱3：页眉页脚入侵正文（发生率19%）
现象：页眉“CONFIDENTIAL”被提取为正文首词，污染doc_type识别。
解决方案：在PyMuPDF提取后，用正则r'^[A-Z\s]{3,20}$'匹配纯大写字母行，结合位置（y<50px）过滤。

小技巧：对法律合同，我们额外检查首行是否含“本协议”“甲方/乙方”，若否，强制重试并加大页眉过滤阈值。

陷阱4：数学公式与代码块失真（发生率12%）
现象：LaTeX公式被转为乱码（如\frac{a}{b}→“a/b”），代码块缩进丢失。
解决方案：对含$...$或\begin{equation}的PDF，改用pdf2image+OCR（PaddleOCR）提取，牺牲速度保精度。

经验：技术白皮书若含公式，预处理耗时增加400%，但准确率从51%升至96%，值得。

陷阱5：加密PDF的静默失败（发生率8%）
现象：PyMuPDF不报错，但get_text()返回空字符串。
解决方案：预处理时先调用doc.needs_pass()检测，若为True，立即返回错误提示“文档受密码保护，请先解密”。

重要提醒：绝不能让加密PDF进入Prompt链！这会导致后续所有模块基于空文本运行，输出完全不可信。

5.2 Prompt链调试的黄金三原则

调试Prompt链不是调参，而是“认知对齐”。我们总结出三条铁律：

原则一：永远先验证上游，再调试下游
新手常犯错误：Synthesizer输出错误，就疯狂改Synthesizer Prompt。正确做法是：拿到错误结果后，第一步打开Document Profiler的原始输出JSON，确认doc_type和key_sections是否正确；若错误，则问题在Profiler，与Synthesizer无关。我们设计了调试模式：在URL加?debug=true，后端返回每层的完整输入输出JSON，方便逐层溯源。

原则二：用“最小可行输入”隔离问题
当某层Prompt表现异常，不要用整篇文档测试。而是提取出该层的最小输入样本。例如，若Intent Interpreter对“这个合同里甲方有哪些免责条款？”返回错误target_section，就只把这句话+Profiler的JSON片段（删掉90%无关字段）喂给它，观察输出。这能快速排除文本长度、噪声等干扰。

原则三：人工标注比模型评估更可靠
不要依赖BLEU、ROUGE等指标评估Prompt效果。我们的标准是：随机抽100个真实用户提问，由3位领域专家（律师/工程师/研究员）独立标注“理想输出”，再与模型输出比对。只有当3位专家一致认为“模型输出与理想输出在关键事实、坐标引用、格式上完全一致”才算通过。这个严苛标准让我们淘汰了7个看似指标漂亮的Prompt变体。

5.3 常见问题速查表（基于217个真实case）

5.4 性能优化：如何让100页PDF在10秒内交付？

面对超长文档，我们采用“分治+缓存”双策略：

分治策略：

• 将Document Profiler拆为“粗筛”+“精筛”两阶段：粗筛用轻量Prompt（仅识别doc_type和key_sections），耗时<1秒；精筛仅对Profiler标记的key_sections执行，跳过无关章节。
• Contextual Extractor启用“增量式锚点匹配”：先用高频锚点（如“甲方”“乙方”）快速定位，再用低频锚点（如“不可抗力”）在局部区域精搜。

缓存策略：

• 对同一PDF的Document Profiler输出，按MD5哈希缓存7天（Redis）。实测83%的重复文档访问直接命中缓存。
• 对常用task_type（如“条款定位”）的Synthesizer Prompt，预编译为Jinja2模板，避免每次渲染开销。

最终效果：在AWS t3.xlarge实例（4vCPU/16GB）上，处理100页PDF的P95耗时稳定在