接到“招标文件智能解析系统”这个需求时我第一反应是这不就是做一个文档信息抽取工具吗等把客户提供的几十份招标文件样例翻完我发现自己想简单了。招标文件不是普通文档它里面既有大段自然语言又有大量表格、盖章件、扫描件甚至还会出现“详见招标文件第五章”这种引用性表述人工翻阅都需要一定的业务经验普通抽取脚本根本招架不住。最终交付的这套系统把文件解析、规则匹配和大模型语义抽取串成了一条流水线能自动输出项目名称、预算金额、资质要求、评分办法、关键时间点等结构化字段并保留原文位置用于人工复核。这套系统适合投标部门、招标代理机构或者任何想用大模型做复杂文档结构化处理的人参考。1. 整体设计先想清楚哪些字段该让AI抽做这类系统最容易犯的错是拿到文件就直接丢给大模型让它“把所有关键信息提取出来”。这个思路听起来很美但落地的时候会发现两个问题一是输出格式不稳定今天返回JSON明天返回Markdown到了业务侧根本没法接二是大模型对数字的精确回忆能力并没有想象中强预算金额这种关键字段一旦被它“脑补”错一位数整个系统就没人敢用了。所以我在设计阶段花了很多时间梳理字段边界和抽取策略。1.1 招标文件里到底需要抽哪些东西我翻阅了客户提供的招标文件把它们归纳成四类字段这四类字段基本覆盖了投标人员日常需要从文件里手工整理的信息。第一类是标识类字段包括项目名称、项目编号、招标人、招标代理机构、采购方式等这些字段通常出现在文件封面和前几页格式相对固定但不同地区模板差异很大。第二类是资格要求类字段包括投标人资质等级、业绩要求、财务状态要求、项目负责人资格、联合体要求等这部分是投标人判断“我能不能投”的核心内容往往散布在资格条件章节和评标办法里。第三类是商务与参数类字段包括预算金额、最高限价、投标保证金、履约保证金、付款方式、质保期、交付期等这些字段对数字精确性要求极高。第四类是规则类字段包括评分标准、评分细则、否决投标条款、无效标情形、开标时间、投标截止时间等这类字段直接决定标书能不能通过评审。把字段分好类之后我才开始考虑用什么技术去抽。这里有个关键认知不同类型字段的最优解法是完全不一样的不能靠一套模型打天下。1.2 规则引擎和大模型的分工边界我最终确定的核心设计原则是确定性字段交给规则引擎语义性字段交给大模型两者交叉验证。这么设计的原因是预算金额、保证金、日期这类字段在原文里一定存在某种数字模式比如“人民币伍佰万元整”或“¥5,000,000.00”用正则表达式和金额识别算法可以做到近乎100%的准确率而且速度极快。但如果让大模型去抽它可能会把“预算金额”和“最高限价”搞混或者把金额的中文大写转成错误的数字这种错误一旦发生校验成本比人工录入还高。反过来看资质要求、评分标准、否决条款这类字段几乎没有固定模式每份文件的表达方式都不一样。比如有的文件写“具备建筑工程施工总承包壹级及以上资质”有的写“须具有建设行政主管部门颁发的建筑工程施工总承包资质且资质等级为一级及以上”这种语义层面的等价关系用正则去穷举不现实必须要靠大模型做语义理解。所以我把解析流程设计成三层文件解析层负责把PDF和Word变成带位置信息的结构化文本规则引擎层负责抓确定性字段大模型层负责抽语义字段。三层的结果进入校验模块统一处理。1.3 技术栈选型与选型理由选型直接决定了项目后面要填多少坑这块我得提一下具体方案。后端语言我选了Python 3.11原因不是它性能最强而是文档解析、OCR、大模型调用这些生态都在Python这边写起来最顺手。API框架用FastAPI自带OpenAPI文档和异步支持方便前端对接。任务队列用Celery加Redis因为解析任务通常要跑几十秒到几分钟不能放在同步请求里等。文件解析部分PDF用PdfPlumber加PyMuPDF扫描件用PaddleOCR做兜底Word文件用python-docx。大模型走的OpenAI兼容协议用的是通义千问系列模型为什么用国产模型而不是GPT系列主要考虑数据安全招标文件在开标前属于敏感资料客户明确要求不能出域所以模型通过私有化网关接入数据不出内网。前端部分我用了Vue 3搭配qui框架真实原因不是qui有什么碾压性优势而是团队里有人对这套组件库熟悉能快速把结果审核界面搭出来。在实际开发中qui的表格、分页、标签页组件确实够用尤其是解析结果页需要大量复用表格展示字段值、置信度和原文位置qui的ProTable组件改改配置就能用省了不少事。向量检索用Qdrant主要用来做章节定位也就是把“评分标准”这个提问映射到文件里的具体章节后续应该讲。2. 从PDF到结构化字段核心细节逐个拆系统的地基是解析层这层要是没做好后面所有逻辑都会跟着遭殃。我见过太多团队在这个地方省事结果到了测试阶段发现文本乱序、表格错位、扫描件空白不得不返工重做。这里我把我们拆过的细节和踩过的坑详细说一说。2.1 文件解析层文本、表格和扫描件分开处理对于文本型PDFPdfPlumber能直接提取文字和坐标但直接用extract_text会有两个隐患一是双栏排版情况下文字顺序会乱左右栏内容交错二是页眉页脚会混进正文影响后续章节匹配。我的做法是拿page对象里的chars坐标信息先按x坐标聚类判断是单栏还是双栏再按y坐标从上到下排序最后把页眉页脚里的固定文字过滤掉。这一步看起来简单其实对后续所有字段的准确率影响很大。举个例子如果页眉里的“招标编号”和正文里的“项目编号”混在一起规则引擎匹配时很容易抽错。表格抽取是另一个大坑。招标文件里的表格经常跨页比如“资格要求一览表”可能延续两三页PdfPlumber的extract_table一次只能处理单页跨页表格会被截断成多张表而且表头不一定每页都有。我用了一个相对取巧的办法先把单页表格全部抽出来然后判断每张表的第一列特征如果上一页最后一行和下一页第一行的内容属于同一逻辑行就把它们拼接起来。这个方法不完美遇到合并单元格还是会出错但可以解决80%的跨页问题剩余的靠人工复核兜底。扫描件的情况更麻烦有些招标文件是投标方上传的扫描版PDF里面全是图片一点文字都抽不出来。这种情况只能走OCR我用PaddleOCR做中文识别默认开启表格识别模型。这里有个经验OCR不是越高级越好对于清晰扫描件PaddleOCR默认的文本检测加识别就够了但要注意输出里的坐标信息一定要保留因为后续需要把识别出的“评分项”定位到原文区域。Word文件的处理相对简单python-docx能读取段落和表格但要注意很多招标文件的Word文档里用了“变量域”功能比如插入“项目名称”域控件读取时可能拿不到实际值这种情况需要额外处理域代码。2.2 大模型Prompt设计先定位章节再抽字段在LLM抽取环节我一开始踩过一个典型坑把整个招标文件塞给大模型让它一次抽完所有字段结果模型出现幻觉、字段遗漏、输出格式不稳定。后来我调整成两段式任务第一段做章节定位第二段做字段抽取。章节定位的目的是找到每一类字段对应的原文段落而不是让模型从全文里大海捞针。实现方式是把文件按标题层级切分成若干片段然后通过一个轻量级提示让模型输出每个目标字段对应的章节标题或片段编号。比如输入是“请根据以下文件目录找到包含‘投标人资格要求’、‘评分标准’、‘投标人须知前附表’的章节标题”模型就能返回“第三章 评标办法”这样的结果。拿到章节位置后我再用另一个更精细的Prompt针对片段做字段抽取。字段抽取的Prompt我打磨了很久最终保持这样的结构先声明任务背景和目标再给一个输出格式约束然后是Few-shot示例最后是待解析文本。下面是一个精简版的示例。def build_extract_prompt(section_text, target_fields): field_desc .join([f{f[label]}{f[rule]} for f in target_fields]) prompt f你是一名招标文件解析助手。请从下面的文本中抽取指定字段并严格按照JSON格式输出。 字段说明{field_desc}。 输出格式要求{{fields:[{{field_key:项目名称,value:xx,confidence:0.9,source_text:原文句子}}]}} 参考示例 文本本项目预算金额为人民币伍佰万元整¥5,000,000.00投标保证金为人民币壹拾万元。 输出{{fields:[{{field_key:预算金额,value:5000000.00,confidence:0.98,source_text:预算金额为人民币伍佰万元整¥5,000,000.00}}]}} 待解析文本 {section_text} return promptPrompt里最关键的一点是要求模型在输出的每个字段上附带source_text也就是原文支持句。这不仅仅是给人工复核用更重要的是我能拿到这个句子去做二次校验。举个例子模型说预算金额是5000000.00同时引用了原文“预算金额为人民币伍佰万元整”我就能用金额解析规则去验证“伍佰万元整”是不是等于5000000.00如果能对上置信度就拉高对不上就把这条记录标记为低置信度转人工。模型温度我设成了0关闭所有随机性保证同一份文件重复解析的结果完全一致。2.3 置信度打分和人工复核机制解析结果不能直接给业务方用这是必须承认的事实。大模型抽字段再准也免不了出现理解偏差。我设计了一套置信度打分规则把字段分成两类第一类是规则引擎抽出来的确定性字段比如日期、金额、编号它们通过正则匹配得到置信度打分逻辑很简单正则匹配成功得基础分0.9如果能通过金额大写转换校验或日期合法性校验再加0.1。第二类是大模型抽出来的语义字段置信度需要综合三个指标模型自评confidence、原文引用校验分、字段间的逻辑一致性分。模型自评分数打个五折因为它自己往往过于自信原文引用校验用正则验证引文里是否包含该字段的必要成分比如抽“资质等级”时检查引文里是否有“资质”“壹级”“二级”等关键词逻辑一致性则是看多个字段是否互相矛盾。所有综合置信度低于0.85的字段前端页面会标黄显示并自动进入人工复核队列。复核界面的交互设计借鉴了标注平台的做法左边是PDF原文右边是解析字段表格点击字段会自动滚动定位到原文位置审核员确认或修改后点击保存。这套机制虽然增加了人工成本但让系统从一个“自动化玩具”变成了业务方能放心上手的工具。实际测试下来大约60%到70%的文件可以不经过人工修改直接出结果剩下的字段人工修正后整体数据准确率能达到99%以上。3. 落地实现从Pipeline到前端审核台方案定了之后剩下的就是把每一层逻辑变成能跑的代码。这一节我会把数据库设计、核心Pipeline、前端交互和API设计都过一遍方便你照着自己的业务去落地。3.1 数据库表结构与任务状态机表格设计上我用了三张核心表解析任务表、字段结果表、人工复核记录表。解析任务表用来存每一次上传文件的解析状态和文件信息字段结果表存抽取出来的字段每个字段一行这是为了方便按字段筛选和排序人工复核记录表则记录审核员改了哪些字段、原始值是多少方便追溯。字段结果表是核心我最终定的结构是这样的字段名类型说明idbigint主键task_idvarchar关联任务IDdoc_idint文件页码IDfield_keyvarchar字段标识如budget_amountfield_labelvarchar字段中文名field_valuetext解析后的值raw_valuetext原始文本source_pageint原文页码source_recttext原文位置坐标confidencefloat综合置信度statusvarcharPENDING/PASS/FAILEDcreated_atdatetime创建时间updated_atdatetime更新时间状态机我设置了五态流转PENDING上传成功待解析→ PARSING解析中→ VERIFY待人工复核→ DONE已确认和 FAILED解析失败。需要注意的是当所有字段置信度都高于阈值时任务可以直接跳转到DONE不需要经过VERIFY。FAILED状态专门留给解析异常的情况比如文件密码保护、PDF损坏、OCR识别结果为空白等这些情况不需要硬撑直接返回错误信息比卡在队列里反复重试更好。3.2 核心Pipeline代码实现核心解析流程可以浓缩成一个Python函数用伪代码展示如下。这个函数把文件解析、章节定位、规则抽取、LLM抽取和结果合并串联起来是整个系统的核心路径。def parse_document(task_id, file_path, fields_config): # 1. 文件解析层根据后缀名选择解析器 doc load_document(file_path) # 返回Document对象包含pages和tables # 2. 规则引擎层先抽确定性字段 rule_results {} for field in fields_config[rule_fields]: for page in doc.pages: match field.regex.search(page.text) if match: rule_results[field.key] { value: field.parse(match.group()), confidence: 1.0, source_page: page.page_num, source_text: match.group() } break # 3. 章节定位向量检索出目标章节 sections doc.get_sections() target_sections locate_sections(sections, fields_config[semantic_fields]) # 4. LLM抽取层逐章节抽取语义字段 llm_results {} for section in target_sections: prompt build_extract_prompt(section.text, section.fields) response llm_client.chat(prompt, temperature0) parsed json.loads(response) for field in parsed[fields]: llm_results[field[field_key]] { value: field[value], confidence: compute_confidence(field), source_page: section.page_num, source_text: field[source_text] } # 5. 结果合并与落库 merged merge_results(rule_results, llm_results) save_fields(task_id, merged) update_task_status(task_id, VERIFY if needs_review(merged) else DONE)这段代码虽然简单但有几个细节是关键load_document返回的Document对象里每一段文本最好都带上页码和坐标信息后面的source_page和source_rect都是在这里产生的。locate_sections我用的是Qdrant向量相似度检索把“评分标准”“资格要求”这类语义表述转成向量在章节标题向量库里找最相似的那几个章节实测下来比关键词匹配稳定很多。因为有的文件目录叫“评标方法”有的叫“综合评分法”表达完全不一样但向量语义能对齐。并发控制也要提一下招标文件经常有几十页甚至上百页LLM逐章节调用速度太慢。我用Celery把一个解析任务拆成多个子任务按章节并行调用LLM同时对并发的最大数量做了限制默认是5个并发防止把模型服务的限流打爆。设置并发数的时候要多做几次压测不同模型的并发上限差异很大过大的并发会导致响应变慢甚至超时反而拖慢整批任务。3.3 前端结果审核界面用qui框架快速搭建前端页面我基于Vue 3和qui框架开发核心就三个页面上传页、任务列表页、解析结果审核页。上传页没什么好说的就是一个大拖拽区加一个上传按钮用qui的Upload组件改改就能用。任务列表页就是一张表格加状态筛选qui的Table组件自带分页和排序省了不少时间。解析结果审核页是前端开发的重点。左侧嵌入了PDF预览组件右侧是字段列表上方显示整体通过率。字段列表用卡片形式展示每个卡片里包含字段名、解析值、置信度和修改按钮置信度低于阈值的卡片背景是淡黄色一眼就能看到哪些需要重点确认。点击卡片时左侧PDF会自动滚动到对应的source_rect位置并用红色边框高亮圈出原文区域。这个交互的代码其实不多但效果非常好审核员不需要来回翻页找原文操作效率提升了不止一倍。另一个前端细节是修改留痕。审核员改完某个字段后页面会把原始值、修改值、修改人、修改时间都记录到人工复核表里这个功能不是为了监管而是为了避免后续业务侧问“这个数据到底是谁改的”时说不清。qui的Form表单组件支持直接绑定对象配合自定义校验规则几分钟就能把修改表单做完。3.4 API设计、部署形态与性能优化后端接口我设计了四个核心API前端和外部系统都通过这些接口对接。上传接口用multipart/form-data接收文件同时接收fields_config参数返回task_id查询任务状态接口返回进度百分比、当前阶段和失败原因查询字段接口返回该任务所有字段的解析结果支持按置信度排序修改字段接口接收字段ID和新值写入复核记录并更新字段表。部署形态上由于客户内网环境复杂我没有采用Docker Compose一把梭的方式而是把服务拆成了三个进程API服务、Worker进程、定时调度。API服务跑FastAPI开16个workerWorker进程跑Celery消费者负责解析、OCR和LLM调用定时调度用来清理超时任务。OCR服务单独部署成GPU实例其他服务全部CPU部署。这个拆分的好处是资源瓶颈在哪个环节就单独扩容哪一块比如项目上线初期扫描件特别多只把OCR实例扩到两倍即可不用整体扩容。性能优化方面一个值得提的点是文件解析的缓存。招标文件经常出现同一文件被反复解析的情况比如业务人员测参数时反复上传同一个PDF每次都跑一遍完整流程既慢又浪费算力。我加了文件指纹缓存用MD5加文件大小生成指纹解析完成的结果直接缓存起来再次上传相同文件直接返回缓存结果。这一招上线后业务侧的用户明显感觉“第二次上传快多了”。4. 实战中踩过的坑问题排查与经验速查最后这部分我把开发和试运行阶段遇到的典型问题整理出来有些是技术问题有些是流程问题但都会在真实项目中反复出现。写出来供大家参考。4.1 PDF文本顺序乱序和表格截断现象是双栏排版文件里正文的左右栏内容交错比如“投标人应当具备/以下资格条件”被解析成“投标人应当具备第/一标段资格条件要求”。排查时我一开始以为是PdfPlumber的问题后来发现是自己没有做栏序判断。解决方法是抽取每行文字的x坐标统计x坐标分布如果两栏的中心x坐标间隔明显就按栏分开排序先左后右拼接。跨页表格截断的问题在资格一览表里最常见解决办法是识别表头的关键词比如“序号”“资质等级”“业绩要求”当下一页的第一列不包含这些关键词时就尝试把上一页的最后一行和下一页的第一行合并合并前还要检查两行的项目名称是否一致。4.2 大模型抽金额字段出现幻觉最头疼的问题是模型把“最高限价”和“预算金额”混着抽或者把“伍佰万元整”转换成50000000.00多了个零。这类字段一旦出错丢的是客户信任。我最终的应对措施分两层第一层是在Prompt里明确告诉模型遇到金额字段必须返回中文大写和阿拉伯数字两个版本方便程序校验第二层是金额校验模块拿到模型返回的阿拉伯数字后用数字转换库反推中文大写如果对不上就直接把该字段标记为低置信度转人工。这个方案上线后金额字段的准确率从92%提升到98.5%剩下的1.5%基本是极其复杂的条件金额描述比如“预算金额超过100万元的部分按80%计算”这类特殊情况。4.3 大文件上传和解析超时客户上传过一份98页、200多MB的扫描版标书整个OCR加LLM流程跑了将近15分钟中间还因为内存不够崩溃了一次。排查后发现两个瓶颈一是PaddleOCR在处理超大PDF时默认会把整个文件读入内存导致内存峰值过高二是LLM章节并发量设置过大把模型网关的限流打爆大量请求排队。解决方法是PDF按页切片OCR逐页处理边读边释放内存LLM并发数从10降到4同时给每次调用加上一个明确的重试机制超时时间设成120秒失败重试3次退避间隔递增。大文件超时的问题是这类系统上线初期必踩的坑最好的方式是在上传接口就限制单文件大小不能超过100MB超过的提示客户拆分后再上传。4.4 业务侧对准确率的期望管理在这个项目上线评审时业务领导问的第一个问题是“准确率有多少”。我当时觉得抽字段准确率能做到95%以上可以宣称系统很可靠。但真正使用后才发现业务侧关心的不是字段准确率而是“能不能全自动免检”。只要系统还需要人工复核他们就会觉得这是个半成品。后来我换了个思路把汇报重点从“准确率”变成“复核率”系统自动通过且无需人工修改的文件占比是多少。这个指标对业务侧更有体感。同时我建议他们先在一个项目组试运行两周等复核率稳定在70%以上再全面推广。试运行期间积累的人工修正记录反过来又用于优化Prompt和规则形成了正向循环。4.5 常见问题速查表问题现象可能原因排查方法解决方案双栏PDF文本乱序未做栏序判断检查chars坐标x分布按x坐标聚类排序表格跨页被截断单页表格抽取逻辑检查跨页行内容一致性按首列特征拼接扫描件识别空白OCR模型未启用表格识别检查OCR返回结果开启PaddleOCR表格模型金额字段多一位零LLM数字转换错误对比中文大写和数值金额双向校验字段引用“详见XX章节”模型抽取的不是最终值查看source_text内容递归解析引用章节大文件内存溢出PDF整体加载查看内存监控按页切片处理重复文件重复解析未做缓存检查任务列表文件指纹加缓存模型输出格式不稳定Prompt约束不足查看模型原始输出加Few-shot示例和JSON Schema约束这个速查表我在项目交付文档里也留了一份后面接手维护的同事反馈说排查问题基本只需要五分钟定位不用再从头读代码。我建议任何一个做类似系统的团队在项目收尾时都整理一份这样的排查表它比几千行技术文档有用得多。最后再分享一点个人体会。做这类“AI文档解析”的落地项目最难的地方其实不在模型选型也不在算法调优而在于让业务方敢把真实数据交给系统处理。这套系统的核心价值不是把人工变成了零而是把人工从逐行阅读招标文件这种高消耗低产出的工作里解放出来让有经验的人只审核机器判断不准的少量字段。项目上线后团队里最资深的一位投标经理说了一句话我觉得很到位“以前一天最多看三份文件现在能看十份眼睛不花心里也更有底。”对我来说这就够了。
招标文件智能解析系统：大模型+规则引擎实现复杂文档结构化
接到“招标文件智能解析系统”这个需求时我第一反应是这不就是做一个文档信息抽取工具吗等把客户提供的几十份招标文件样例翻完我发现自己想简单了。招标文件不是普通文档它里面既有大段自然语言又有大量表格、盖章件、扫描件甚至还会出现“详见招标文件第五章”这种引用性表述人工翻阅都需要一定的业务经验普通抽取脚本根本招架不住。最终交付的这套系统把文件解析、规则匹配和大模型语义抽取串成了一条流水线能自动输出项目名称、预算金额、资质要求、评分办法、关键时间点等结构化字段并保留原文位置用于人工复核。这套系统适合投标部门、招标代理机构或者任何想用大模型做复杂文档结构化处理的人参考。1. 整体设计先想清楚哪些字段该让AI抽做这类系统最容易犯的错是拿到文件就直接丢给大模型让它“把所有关键信息提取出来”。这个思路听起来很美但落地的时候会发现两个问题一是输出格式不稳定今天返回JSON明天返回Markdown到了业务侧根本没法接二是大模型对数字的精确回忆能力并没有想象中强预算金额这种关键字段一旦被它“脑补”错一位数整个系统就没人敢用了。所以我在设计阶段花了很多时间梳理字段边界和抽取策略。1.1 招标文件里到底需要抽哪些东西我翻阅了客户提供的招标文件把它们归纳成四类字段这四类字段基本覆盖了投标人员日常需要从文件里手工整理的信息。第一类是标识类字段包括项目名称、项目编号、招标人、招标代理机构、采购方式等这些字段通常出现在文件封面和前几页格式相对固定但不同地区模板差异很大。第二类是资格要求类字段包括投标人资质等级、业绩要求、财务状态要求、项目负责人资格、联合体要求等这部分是投标人判断“我能不能投”的核心内容往往散布在资格条件章节和评标办法里。第三类是商务与参数类字段包括预算金额、最高限价、投标保证金、履约保证金、付款方式、质保期、交付期等这些字段对数字精确性要求极高。第四类是规则类字段包括评分标准、评分细则、否决投标条款、无效标情形、开标时间、投标截止时间等这类字段直接决定标书能不能通过评审。把字段分好类之后我才开始考虑用什么技术去抽。这里有个关键认知不同类型字段的最优解法是完全不一样的不能靠一套模型打天下。1.2 规则引擎和大模型的分工边界我最终确定的核心设计原则是确定性字段交给规则引擎语义性字段交给大模型两者交叉验证。这么设计的原因是预算金额、保证金、日期这类字段在原文里一定存在某种数字模式比如“人民币伍佰万元整”或“¥5,000,000.00”用正则表达式和金额识别算法可以做到近乎100%的准确率而且速度极快。但如果让大模型去抽它可能会把“预算金额”和“最高限价”搞混或者把金额的中文大写转成错误的数字这种错误一旦发生校验成本比人工录入还高。反过来看资质要求、评分标准、否决条款这类字段几乎没有固定模式每份文件的表达方式都不一样。比如有的文件写“具备建筑工程施工总承包壹级及以上资质”有的写“须具有建设行政主管部门颁发的建筑工程施工总承包资质且资质等级为一级及以上”这种语义层面的等价关系用正则去穷举不现实必须要靠大模型做语义理解。所以我把解析流程设计成三层文件解析层负责把PDF和Word变成带位置信息的结构化文本规则引擎层负责抓确定性字段大模型层负责抽语义字段。三层的结果进入校验模块统一处理。1.3 技术栈选型与选型理由选型直接决定了项目后面要填多少坑这块我得提一下具体方案。后端语言我选了Python 3.11原因不是它性能最强而是文档解析、OCR、大模型调用这些生态都在Python这边写起来最顺手。API框架用FastAPI自带OpenAPI文档和异步支持方便前端对接。任务队列用Celery加Redis因为解析任务通常要跑几十秒到几分钟不能放在同步请求里等。文件解析部分PDF用PdfPlumber加PyMuPDF扫描件用PaddleOCR做兜底Word文件用python-docx。大模型走的OpenAI兼容协议用的是通义千问系列模型为什么用国产模型而不是GPT系列主要考虑数据安全招标文件在开标前属于敏感资料客户明确要求不能出域所以模型通过私有化网关接入数据不出内网。前端部分我用了Vue 3搭配qui框架真实原因不是qui有什么碾压性优势而是团队里有人对这套组件库熟悉能快速把结果审核界面搭出来。在实际开发中qui的表格、分页、标签页组件确实够用尤其是解析结果页需要大量复用表格展示字段值、置信度和原文位置qui的ProTable组件改改配置就能用省了不少事。向量检索用Qdrant主要用来做章节定位也就是把“评分标准”这个提问映射到文件里的具体章节后续应该讲。2. 从PDF到结构化字段核心细节逐个拆系统的地基是解析层这层要是没做好后面所有逻辑都会跟着遭殃。我见过太多团队在这个地方省事结果到了测试阶段发现文本乱序、表格错位、扫描件空白不得不返工重做。这里我把我们拆过的细节和踩过的坑详细说一说。2.1 文件解析层文本、表格和扫描件分开处理对于文本型PDFPdfPlumber能直接提取文字和坐标但直接用extract_text会有两个隐患一是双栏排版情况下文字顺序会乱左右栏内容交错二是页眉页脚会混进正文影响后续章节匹配。我的做法是拿page对象里的chars坐标信息先按x坐标聚类判断是单栏还是双栏再按y坐标从上到下排序最后把页眉页脚里的固定文字过滤掉。这一步看起来简单其实对后续所有字段的准确率影响很大。举个例子如果页眉里的“招标编号”和正文里的“项目编号”混在一起规则引擎匹配时很容易抽错。表格抽取是另一个大坑。招标文件里的表格经常跨页比如“资格要求一览表”可能延续两三页PdfPlumber的extract_table一次只能处理单页跨页表格会被截断成多张表而且表头不一定每页都有。我用了一个相对取巧的办法先把单页表格全部抽出来然后判断每张表的第一列特征如果上一页最后一行和下一页第一行的内容属于同一逻辑行就把它们拼接起来。这个方法不完美遇到合并单元格还是会出错但可以解决80%的跨页问题剩余的靠人工复核兜底。扫描件的情况更麻烦有些招标文件是投标方上传的扫描版PDF里面全是图片一点文字都抽不出来。这种情况只能走OCR我用PaddleOCR做中文识别默认开启表格识别模型。这里有个经验OCR不是越高级越好对于清晰扫描件PaddleOCR默认的文本检测加识别就够了但要注意输出里的坐标信息一定要保留因为后续需要把识别出的“评分项”定位到原文区域。Word文件的处理相对简单python-docx能读取段落和表格但要注意很多招标文件的Word文档里用了“变量域”功能比如插入“项目名称”域控件读取时可能拿不到实际值这种情况需要额外处理域代码。2.2 大模型Prompt设计先定位章节再抽字段在LLM抽取环节我一开始踩过一个典型坑把整个招标文件塞给大模型让它一次抽完所有字段结果模型出现幻觉、字段遗漏、输出格式不稳定。后来我调整成两段式任务第一段做章节定位第二段做字段抽取。章节定位的目的是找到每一类字段对应的原文段落而不是让模型从全文里大海捞针。实现方式是把文件按标题层级切分成若干片段然后通过一个轻量级提示让模型输出每个目标字段对应的章节标题或片段编号。比如输入是“请根据以下文件目录找到包含‘投标人资格要求’、‘评分标准’、‘投标人须知前附表’的章节标题”模型就能返回“第三章 评标办法”这样的结果。拿到章节位置后我再用另一个更精细的Prompt针对片段做字段抽取。字段抽取的Prompt我打磨了很久最终保持这样的结构先声明任务背景和目标再给一个输出格式约束然后是Few-shot示例最后是待解析文本。下面是一个精简版的示例。def build_extract_prompt(section_text, target_fields): field_desc .join([f{f[label]}{f[rule]} for f in target_fields]) prompt f你是一名招标文件解析助手。请从下面的文本中抽取指定字段并严格按照JSON格式输出。 字段说明{field_desc}。 输出格式要求{{fields:[{{field_key:项目名称,value:xx,confidence:0.9,source_text:原文句子}}]}} 参考示例 文本本项目预算金额为人民币伍佰万元整¥5,000,000.00投标保证金为人民币壹拾万元。 输出{{fields:[{{field_key:预算金额,value:5000000.00,confidence:0.98,source_text:预算金额为人民币伍佰万元整¥5,000,000.00}}]}} 待解析文本 {section_text} return promptPrompt里最关键的一点是要求模型在输出的每个字段上附带source_text也就是原文支持句。这不仅仅是给人工复核用更重要的是我能拿到这个句子去做二次校验。举个例子模型说预算金额是5000000.00同时引用了原文“预算金额为人民币伍佰万元整”我就能用金额解析规则去验证“伍佰万元整”是不是等于5000000.00如果能对上置信度就拉高对不上就把这条记录标记为低置信度转人工。模型温度我设成了0关闭所有随机性保证同一份文件重复解析的结果完全一致。2.3 置信度打分和人工复核机制解析结果不能直接给业务方用这是必须承认的事实。大模型抽字段再准也免不了出现理解偏差。我设计了一套置信度打分规则把字段分成两类第一类是规则引擎抽出来的确定性字段比如日期、金额、编号它们通过正则匹配得到置信度打分逻辑很简单正则匹配成功得基础分0.9如果能通过金额大写转换校验或日期合法性校验再加0.1。第二类是大模型抽出来的语义字段置信度需要综合三个指标模型自评confidence、原文引用校验分、字段间的逻辑一致性分。模型自评分数打个五折因为它自己往往过于自信原文引用校验用正则验证引文里是否包含该字段的必要成分比如抽“资质等级”时检查引文里是否有“资质”“壹级”“二级”等关键词逻辑一致性则是看多个字段是否互相矛盾。所有综合置信度低于0.85的字段前端页面会标黄显示并自动进入人工复核队列。复核界面的交互设计借鉴了标注平台的做法左边是PDF原文右边是解析字段表格点击字段会自动滚动定位到原文位置审核员确认或修改后点击保存。这套机制虽然增加了人工成本但让系统从一个“自动化玩具”变成了业务方能放心上手的工具。实际测试下来大约60%到70%的文件可以不经过人工修改直接出结果剩下的字段人工修正后整体数据准确率能达到99%以上。3. 落地实现从Pipeline到前端审核台方案定了之后剩下的就是把每一层逻辑变成能跑的代码。这一节我会把数据库设计、核心Pipeline、前端交互和API设计都过一遍方便你照着自己的业务去落地。3.1 数据库表结构与任务状态机表格设计上我用了三张核心表解析任务表、字段结果表、人工复核记录表。解析任务表用来存每一次上传文件的解析状态和文件信息字段结果表存抽取出来的字段每个字段一行这是为了方便按字段筛选和排序人工复核记录表则记录审核员改了哪些字段、原始值是多少方便追溯。字段结果表是核心我最终定的结构是这样的字段名类型说明idbigint主键task_idvarchar关联任务IDdoc_idint文件页码IDfield_keyvarchar字段标识如budget_amountfield_labelvarchar字段中文名field_valuetext解析后的值raw_valuetext原始文本source_pageint原文页码source_recttext原文位置坐标confidencefloat综合置信度statusvarcharPENDING/PASS/FAILEDcreated_atdatetime创建时间updated_atdatetime更新时间状态机我设置了五态流转PENDING上传成功待解析→ PARSING解析中→ VERIFY待人工复核→ DONE已确认和 FAILED解析失败。需要注意的是当所有字段置信度都高于阈值时任务可以直接跳转到DONE不需要经过VERIFY。FAILED状态专门留给解析异常的情况比如文件密码保护、PDF损坏、OCR识别结果为空白等这些情况不需要硬撑直接返回错误信息比卡在队列里反复重试更好。3.2 核心Pipeline代码实现核心解析流程可以浓缩成一个Python函数用伪代码展示如下。这个函数把文件解析、章节定位、规则抽取、LLM抽取和结果合并串联起来是整个系统的核心路径。def parse_document(task_id, file_path, fields_config): # 1. 文件解析层根据后缀名选择解析器 doc load_document(file_path) # 返回Document对象包含pages和tables # 2. 规则引擎层先抽确定性字段 rule_results {} for field in fields_config[rule_fields]: for page in doc.pages: match field.regex.search(page.text) if match: rule_results[field.key] { value: field.parse(match.group()), confidence: 1.0, source_page: page.page_num, source_text: match.group() } break # 3. 章节定位向量检索出目标章节 sections doc.get_sections() target_sections locate_sections(sections, fields_config[semantic_fields]) # 4. LLM抽取层逐章节抽取语义字段 llm_results {} for section in target_sections: prompt build_extract_prompt(section.text, section.fields) response llm_client.chat(prompt, temperature0) parsed json.loads(response) for field in parsed[fields]: llm_results[field[field_key]] { value: field[value], confidence: compute_confidence(field), source_page: section.page_num, source_text: field[source_text] } # 5. 结果合并与落库 merged merge_results(rule_results, llm_results) save_fields(task_id, merged) update_task_status(task_id, VERIFY if needs_review(merged) else DONE)这段代码虽然简单但有几个细节是关键load_document返回的Document对象里每一段文本最好都带上页码和坐标信息后面的source_page和source_rect都是在这里产生的。locate_sections我用的是Qdrant向量相似度检索把“评分标准”“资格要求”这类语义表述转成向量在章节标题向量库里找最相似的那几个章节实测下来比关键词匹配稳定很多。因为有的文件目录叫“评标方法”有的叫“综合评分法”表达完全不一样但向量语义能对齐。并发控制也要提一下招标文件经常有几十页甚至上百页LLM逐章节调用速度太慢。我用Celery把一个解析任务拆成多个子任务按章节并行调用LLM同时对并发的最大数量做了限制默认是5个并发防止把模型服务的限流打爆。设置并发数的时候要多做几次压测不同模型的并发上限差异很大过大的并发会导致响应变慢甚至超时反而拖慢整批任务。3.3 前端结果审核界面用qui框架快速搭建前端页面我基于Vue 3和qui框架开发核心就三个页面上传页、任务列表页、解析结果审核页。上传页没什么好说的就是一个大拖拽区加一个上传按钮用qui的Upload组件改改就能用。任务列表页就是一张表格加状态筛选qui的Table组件自带分页和排序省了不少时间。解析结果审核页是前端开发的重点。左侧嵌入了PDF预览组件右侧是字段列表上方显示整体通过率。字段列表用卡片形式展示每个卡片里包含字段名、解析值、置信度和修改按钮置信度低于阈值的卡片背景是淡黄色一眼就能看到哪些需要重点确认。点击卡片时左侧PDF会自动滚动到对应的source_rect位置并用红色边框高亮圈出原文区域。这个交互的代码其实不多但效果非常好审核员不需要来回翻页找原文操作效率提升了不止一倍。另一个前端细节是修改留痕。审核员改完某个字段后页面会把原始值、修改值、修改人、修改时间都记录到人工复核表里这个功能不是为了监管而是为了避免后续业务侧问“这个数据到底是谁改的”时说不清。qui的Form表单组件支持直接绑定对象配合自定义校验规则几分钟就能把修改表单做完。3.4 API设计、部署形态与性能优化后端接口我设计了四个核心API前端和外部系统都通过这些接口对接。上传接口用multipart/form-data接收文件同时接收fields_config参数返回task_id查询任务状态接口返回进度百分比、当前阶段和失败原因查询字段接口返回该任务所有字段的解析结果支持按置信度排序修改字段接口接收字段ID和新值写入复核记录并更新字段表。部署形态上由于客户内网环境复杂我没有采用Docker Compose一把梭的方式而是把服务拆成了三个进程API服务、Worker进程、定时调度。API服务跑FastAPI开16个workerWorker进程跑Celery消费者负责解析、OCR和LLM调用定时调度用来清理超时任务。OCR服务单独部署成GPU实例其他服务全部CPU部署。这个拆分的好处是资源瓶颈在哪个环节就单独扩容哪一块比如项目上线初期扫描件特别多只把OCR实例扩到两倍即可不用整体扩容。性能优化方面一个值得提的点是文件解析的缓存。招标文件经常出现同一文件被反复解析的情况比如业务人员测参数时反复上传同一个PDF每次都跑一遍完整流程既慢又浪费算力。我加了文件指纹缓存用MD5加文件大小生成指纹解析完成的结果直接缓存起来再次上传相同文件直接返回缓存结果。这一招上线后业务侧的用户明显感觉“第二次上传快多了”。4. 实战中踩过的坑问题排查与经验速查最后这部分我把开发和试运行阶段遇到的典型问题整理出来有些是技术问题有些是流程问题但都会在真实项目中反复出现。写出来供大家参考。4.1 PDF文本顺序乱序和表格截断现象是双栏排版文件里正文的左右栏内容交错比如“投标人应当具备/以下资格条件”被解析成“投标人应当具备第/一标段资格条件要求”。排查时我一开始以为是PdfPlumber的问题后来发现是自己没有做栏序判断。解决方法是抽取每行文字的x坐标统计x坐标分布如果两栏的中心x坐标间隔明显就按栏分开排序先左后右拼接。跨页表格截断的问题在资格一览表里最常见解决办法是识别表头的关键词比如“序号”“资质等级”“业绩要求”当下一页的第一列不包含这些关键词时就尝试把上一页的最后一行和下一页的第一行合并合并前还要检查两行的项目名称是否一致。4.2 大模型抽金额字段出现幻觉最头疼的问题是模型把“最高限价”和“预算金额”混着抽或者把“伍佰万元整”转换成50000000.00多了个零。这类字段一旦出错丢的是客户信任。我最终的应对措施分两层第一层是在Prompt里明确告诉模型遇到金额字段必须返回中文大写和阿拉伯数字两个版本方便程序校验第二层是金额校验模块拿到模型返回的阿拉伯数字后用数字转换库反推中文大写如果对不上就直接把该字段标记为低置信度转人工。这个方案上线后金额字段的准确率从92%提升到98.5%剩下的1.5%基本是极其复杂的条件金额描述比如“预算金额超过100万元的部分按80%计算”这类特殊情况。4.3 大文件上传和解析超时客户上传过一份98页、200多MB的扫描版标书整个OCR加LLM流程跑了将近15分钟中间还因为内存不够崩溃了一次。排查后发现两个瓶颈一是PaddleOCR在处理超大PDF时默认会把整个文件读入内存导致内存峰值过高二是LLM章节并发量设置过大把模型网关的限流打爆大量请求排队。解决方法是PDF按页切片OCR逐页处理边读边释放内存LLM并发数从10降到4同时给每次调用加上一个明确的重试机制超时时间设成120秒失败重试3次退避间隔递增。大文件超时的问题是这类系统上线初期必踩的坑最好的方式是在上传接口就限制单文件大小不能超过100MB超过的提示客户拆分后再上传。4.4 业务侧对准确率的期望管理在这个项目上线评审时业务领导问的第一个问题是“准确率有多少”。我当时觉得抽字段准确率能做到95%以上可以宣称系统很可靠。但真正使用后才发现业务侧关心的不是字段准确率而是“能不能全自动免检”。只要系统还需要人工复核他们就会觉得这是个半成品。后来我换了个思路把汇报重点从“准确率”变成“复核率”系统自动通过且无需人工修改的文件占比是多少。这个指标对业务侧更有体感。同时我建议他们先在一个项目组试运行两周等复核率稳定在70%以上再全面推广。试运行期间积累的人工修正记录反过来又用于优化Prompt和规则形成了正向循环。4.5 常见问题速查表问题现象可能原因排查方法解决方案双栏PDF文本乱序未做栏序判断检查chars坐标x分布按x坐标聚类排序表格跨页被截断单页表格抽取逻辑检查跨页行内容一致性按首列特征拼接扫描件识别空白OCR模型未启用表格识别检查OCR返回结果开启PaddleOCR表格模型金额字段多一位零LLM数字转换错误对比中文大写和数值金额双向校验字段引用“详见XX章节”模型抽取的不是最终值查看source_text内容递归解析引用章节大文件内存溢出PDF整体加载查看内存监控按页切片处理重复文件重复解析未做缓存检查任务列表文件指纹加缓存模型输出格式不稳定Prompt约束不足查看模型原始输出加Few-shot示例和JSON Schema约束这个速查表我在项目交付文档里也留了一份后面接手维护的同事反馈说排查问题基本只需要五分钟定位不用再从头读代码。我建议任何一个做类似系统的团队在项目收尾时都整理一份这样的排查表它比几千行技术文档有用得多。最后再分享一点个人体会。做这类“AI文档解析”的落地项目最难的地方其实不在模型选型也不在算法调优而在于让业务方敢把真实数据交给系统处理。这套系统的核心价值不是把人工变成了零而是把人工从逐行阅读招标文件这种高消耗低产出的工作里解放出来让有经验的人只审核机器判断不准的少量字段。项目上线后团队里最资深的一位投标经理说了一句话我觉得很到位“以前一天最多看三份文件现在能看十份眼睛不花心里也更有底。”对我来说这就够了。
