1. 项目概述当ChatGPT遇上文档信息提取最近在做一个项目需要从一堆五花八门的PDF、Word文档里自动提取关键信息比如合同里的甲乙双方、金额、日期或者简历里的姓名、电话、工作经历。手动处理光是想想就头大。就在我琢磨着怎么用传统OCR加规则引擎来搞的时候一个叫brandonrobertz/chatgpt-document-extraction的开源项目进入了我的视野。这个项目的核心思路非常直接它不跟你玩复杂的模板匹配或者写一堆正则表达式而是直接把文档内容“喂”给像ChatGPT这样的大型语言模型然后通过精心设计的提示词让AI模型自己理解文档并把我们需要的结构化信息给“吐”出来。简单来说就是把文档理解这个难题外包给了目前地球上最聪明的“大脑”之一。这解决了什么痛点呢传统的信息提取无论是用开源工具如Apache Tika解析文本还是用商业OCR服务识别扫描件最后都得面对一个混乱的文本“毛坯房”。你需要自己写代码去“装修”——定位字段、清洗格式、处理异常。文档格式一变或者遇到从来没见过的版式代码就得跟着改维护成本极高。而这个项目提供了一种声明式的解决方案你只需要告诉AI“从这份文档里找出所有日期和金额”它就能在各种格式的文档中以惊人的准确率完成任务。它非常适合以下几类人需要处理大量非结构化文档的数据工程师或分析师希望为内部系统添加智能文档处理能力的开发者以及任何厌倦了手动复制粘贴、渴望自动化工作流的办公室人员。即使你对AI和编程了解不深这个项目清晰的接口和示例也能让你快速上手。2. 核心架构与工作流拆解这个项目的魅力不在于代码量有多大而在于它巧妙地组合了几个成熟的技术栈构建了一条高效、清晰的流水线。理解这条流水线是灵活运用和二次开发的关键。2.1 从文档到文本预处理层AI模型不能直接“吃”PDF或图片它需要纯文本。所以第一步是文档解析与文本提取。本地解析引擎项目通常会集成像PyPDF2、pdfplumber或python-docx这样的库来处理本地文件。pdfplumber在提取带格式的文本尤其是表格时表现更佳因为它能获取字符的坐标信息。云服务集成对于更复杂的场景如扫描版PDF图片格式就需要OCR能力。项目可能会支持接入像Azure AI Document Intelligence、Google Cloud Vision OCR或Amazon Textract这样的云服务。这些服务不仅能识别文字还能理解文档结构如段落、标题、表格、键值对输出带有布局信息的JSON为后续处理提供极大便利。注意使用云服务通常会产生费用并且需要处理网络请求和API密钥管理。在架构设计时需要考虑离线部署和成本控制之间的平衡。2.2 与AI模型对话提示工程层这是项目的灵魂所在。提取出文本后并不是一股脑全塞给GPT。这里涉及两个核心动作文本分块和提示词构建。文本分块一篇上百页的文档很可能超过GPT模型的上下文窗口限制例如GPT-3.5-turbo通常是16K tokens。因此需要将长文档按语义切割成大小合适的片段Chunks。简单的做法是按固定字符数切割但更优的策略是按段落、章节或标记进行分割以保证语义的完整性。提示词构建这是决定提取准确性的关键。一个优秀的提示词Prompt需要包含角色定义你是一个专业的文档信息提取助手。任务指令请从以下文本中提取所有提到的“公司名称”、“合同金额”和“生效日期”。输出格式约束请以JSON格式输出包含以下字段company_names列表 contract_amount字符串带货币单位 effective_date字符串YYYY-MM-DD格式。示例Few-Shot Learning提供一两个输入文本和对应输出JSON的例子能极大提升模型在复杂任务上的表现。待处理的文本块将分块后的文本放入提示词中。项目源码中会有一个或多个预设的提示词模板开发者可以根据自己的文档类型和字段进行定制。2.3 模型调用与结果合成执行与后处理层模型调用项目通过OpenAI API或其他兼容API如Azure OpenAI、LM Studio本地模型发送HTTP请求。这里需要管理API密钥、处理请求超时、重试和速率限制。结果合成如果文档被分成了多个块那么每个块都会返回一个提取结果可能是JSON。后处理需要将这些结果合并和去重。例如同一家公司名称可能在多个块中出现需要合并为一个对于金额和日期可能需要根据上下文判断哪个是最主要的或最终的。置信度处理高级用法中可以要求模型返回它对每个提取字段的置信度评分或者提供提取值的原文出处。这对于构建高可靠性的生产系统非常重要可以设置一个阈值只采纳高置信度的结果低置信度的交由人工复核。整个工作流可以概括为文档输入 - 解析为文本 - 智能分块 - 构建提示词 - 调用LLM - 解析并合成结果 - 结构化数据输出。这个流程清晰地将文档处理的“脏活累活”解析、分块与需要“智能”的活理解、提取解耦使得系统既健壮又灵活。3. 关键技术细节与实操要点理解了宏观架构我们深入到代码层面看看几个必须搞清楚的细节。这些细节决定了你的提取任务是“勉强能用”还是“精准高效”。3.1 文档解析器的选择与陷阱选择哪种方式把文档变成文本是第一步也是坑最多的一步。纯文本PDF如果确定PDF是文本型可以从Acrobat里直接复制文字PyPDF2轻量快速是首选。但它的提取结果可能丢失空格或换行导致单词粘连。pdfplumber更强大能保留视觉布局对于有复杂排版或表格的文档是更好的选择。# 使用 pdfplumber 提取文本并保留布局 import pdfplumber with pdfplumber.open(contract.pdf) as pdf: full_text for page in pdf.pages: # extract_text 方法保留了基本的布局信息 page_text page.extract_text(layoutTrue) full_text page_text \n扫描件/图片PDF必须使用OCR。本地方案可以尝试Tesseract但安装和语言包配置比较麻烦且对复杂版面如多栏、表格识别效果一般。对于生产环境强烈建议使用云OCR服务。以Azure Document Intelligence为例它返回的不仅是文字还有每个词的边界框、阅读顺序、以及文档结构如“这是一个标题”、“这是一个表格单元格”。实操心得即使文档大部分是文本也偶尔会嵌入扫描的签名页或盖章页。一个稳健的策略是先用PyPDF2尝试提取如果提取出的文本长度极短比如少于文档页数*100个字符则判定可能为扫描件自动切换到OCR流程。3.2 提示词设计的艺术提示词是你与AI模型沟通的“合同”。写得越清晰结果越好。字段定义要无歧义不要说“提取日期”而要说“提取文档的签署日期格式为YYYY-MM-DD”。如果文档中有多个日期如生效日、到期日、签署日必须明确指定。利用上下文和指令如果处理的是发票可以在提示词开头加一句“你正在分析一张商业发票。” 这能给模型一个强大的领域暗示。处理“未找到”的情况明确告诉模型如果找不到某个字段该怎么办。例如“如果未找到‘折扣金额’则该字段输出为空字符串或null。” 避免模型胡编乱造。输出格式严格限定要求输出严格的JSON并给出一个完整的示例。这能极大减少模型返回非结构化文本的概率。prompt_template 你是一个合同分析专家。请从下面的合同文本片段中提取信息。 ## 输出要求 请严格输出一个JSON对象且只包含这个JSON对象不要有任何其他解释。 JSON必须包含以下字段 - party_a (字符串): 甲方公司全称。 - party_b (字符串): 乙方公司全称。 - total_amount (字符串): 合同总金额包含货币符号例如“人民币壹佰万元整”或“1,000,000”。 - sign_date (字符串): 合同签署日期格式为YYYY-MM-DD。如果文本中有多个日期请提取最可能作为签署日的那个。 ## 示例 输入文本“本合同由北京云智科技有限公司甲方与上海数据智能有限公司乙方于2023年10月26日签订总金额为人民币伍拾万元整。” 输出{party_a: 北京云智科技有限公司, party_b: 上海数据智能有限公司, total_amount: 人民币伍拾万元整, sign_date: 2023-10-26} ## 待分析的合同文本 {text_chunk} ## 你的提取结果仅JSON 3.3 文本分块与上下文管理如何切分文档直接影响模型能否看到完整的上下文信息。重叠分块这是防止信息在块边界被切断的关键技巧。例如块大小设为1000字符步长重叠设为200字符。这样即使一个关键信息如“合同金额1,000,000”恰好在第999-1006个字符的位置它也能在第一个块的末尾和第二个块的开头都出现确保至少有一个块能包含完整信息。语义分块更高级的方法是使用嵌入模型如OpenAI的text-embedding-3-small计算句子向量然后根据向量相似度进行聚类或分割。或者利用OCR服务返回的段落/章节边界进行分块。这能保证每个块在语义上尽可能完整。关键信息优先对于合同、发票标题、签署区域、总金额所在区域通常是信息密度最高的地方。可以考虑在分块前先用简单的规则或布局分析定位这些区域优先提取或给予更高权重。4. 完整实现流程与代码解析让我们抛开抽象概念动手搭建一个最小可行版本。假设我们要从一份采购合同中提取几个核心字段。4.1 环境准备与依赖安装首先创建一个干净的Python环境并安装核心依赖。# 创建并激活虚拟环境可选但推荐 python -m venv venv source venv/bin/activate # Linux/Mac # venv\Scripts\activate # Windows # 安装依赖 pip install openai pdfplumber python-dotenv这里我们选择openai: 官方库用于调用ChatGPT API。pdfplumber: 强大的PDF文本提取库对表格支持好。python-dotenv: 管理环境变量安全地存储API密钥。在项目根目录创建.env文件填入你的OpenAI API密钥OPENAI_API_KEYsk-your-secret-key-here4.2 构建核心提取函数接下来我们编写一个核心函数extract_from_pdf它完成从文件路径到结构化数据的整个过程。import os import json import pdfplumber from openai import OpenAI from dotenv import load_dotenv import logging # 加载环境变量 load_dotenv() # 配置日志 logging.basicConfig(levellogging.INFO) logger logging.getLogger(__name__) class DocumentExtractor: def __init__(self, modelgpt-3.5-turbo): self.client OpenAI(api_keyos.getenv(OPENAI_API_KEY)) self.model model def extract_text_from_pdf(self, pdf_path): 使用 pdfplumber 提取PDF文本并分块。 full_text try: with pdfplumber.open(pdf_path) as pdf: for page_num, page in enumerate(pdf.pages): text page.extract_text(layoutTrue) if text: full_text f--- Page {page_num 1} ---\n{text}\n else: logger.warning(fPage {page_num 1} 可能为扫描页或空白页。) except Exception as e: logger.error(f解析PDF失败: {e}) raise return full_text def chunk_text(self, text, chunk_size3000, overlap500): 将长文本按字符数分块带有重叠。 chunks [] start 0 text_length len(text) while start text_length: end start chunk_size # 确保不截断一个完整的句子简单实现在句号、换行处截断 if end text_length: # 查找最近的句号或换行符作为截断点 while end start and text[end] not in (。, ., \n, , ;): end - 1 if end start: # 没找到就硬截断 end start chunk_size chunk text[start:end] chunks.append(chunk) start end - overlap # 设置重叠 return chunks def create_extraction_prompt(self, text_chunk, fields_definition): 构建信息提取提示词。 prompt f 你是一个专业的文档信息提取助手。你的任务是从用户提供的文本中精确提取指定的结构化信息。 ## 需要提取的字段及说明 {fields_definition} ## 重要规则 1. 只提取文本中明确出现的信息。不要推断、猜测或编造任何内容。 2. 如果某个字段在文本中找不到将其值设置为 null。 3. 输出必须是一个纯净的JSON对象不要有任何额外的解释、标记或文本。 4. 金额字段请保留原始文本中的数字和单位如“人民币100万元”、“1,200.50”。 5. 日期字段请统一格式化为“YYYY-MM-DD”。 ## 待分析的文本 {text_chunk} ## 请输出提取结果的JSON return prompt def call_llm_for_extraction(self, prompt): 调用OpenAI API进行信息提取。 try: response self.client.chat.completions.create( modelself.model, messages[ {role: system, content: 你是一个精确的JSON数据提取器。只返回有效的JSON。}, {role: user, content: prompt} ], temperature0.1, # 低温度保证输出稳定性 response_format{type: json_object} # 强制JSON输出格式 ) result_json response.choices[0].message.content return json.loads(result_json) except json.JSONDecodeError as e: logger.error(fAPI返回的不是有效JSON: {result_json}. 错误: {e}) return None except Exception as e: logger.error(f调用API失败: {e}) return None def merge_results(self, results_list): 合并从多个文本块中提取的结果。简单策略以非null值优先或去重合并列表。 merged {} for result in results_list: if not result: continue for key, value in result.items(): if value is None or value : continue # 如果字段是列表如“参与方”则合并去重 if isinstance(value, list): merged.setdefault(key, []) merged[key].extend([v for v in value if v not in merged[key]]) # 如果是单一值且当前merged中为空或为null则覆盖 elif key not in merged or merged[key] is None: merged[key] value # 如果已经有值可以选择保留更长的可能更完整或记录冲突 # 这里采用简单策略保留第一个非空值 return merged def extract_from_pdf(self, pdf_path, fields_definition): 主函数从PDF提取信息。 logger.info(f开始处理文档: {pdf_path}) # 1. 提取文本 text self.extract_text_from_pdf(pdf_path) if not text: logger.error(未能从PDF提取出任何文本。) return {} # 2. 分块 chunks self.chunk_text(text) logger.info(f文档被分为 {len(chunks)} 个块。) # 3. 逐块提取 all_results [] for i, chunk in enumerate(chunks): logger.info(f正在处理第 {i1}/{len(chunks)} 块...) prompt self.create_extraction_prompt(chunk, fields_definition) result self.call_llm_for_extraction(prompt) if result: all_results.append(result) # 4. 合并结果 final_result self.merge_results(all_results) logger.info(信息提取完成。) return final_result # 字段定义示例可由用户动态配置 FIELDS_DEF - contract_title (字符串): 合同标题或名称。 - parties (列表): 合同涉及的所有参与方名称公司或个人。 - total_amount (字符串): 合同涉及的总金额带货币单位。 - effective_date (字符串): 合同生效日期格式YYYY-MM-DD。 - signing_parties (列表): 合同末尾的签署方名称。 # 使用示例 if __name__ __main__: extractor DocumentExtractor() result extractor.extract_from_pdf(sample_contract.pdf, FIELDS_DEF) print(json.dumps(result, indent2, ensure_asciiFalse))这个实现包含了从文本提取、分块、提示词构建、API调用到结果合并的完整链路。fields_definition参数让用户可以灵活定义需要提取的字段而无需修改代码。4.3 配置与运行优化模型选择gpt-3.5-turbo性价比高适合大多数信息提取任务。对于极其复杂或需要深度推理的文档如法律条款分析可以考虑gpt-4或gpt-4-turbo但成本会显著增加。温度参数temperature0.1设置为接近0的值是为了让模型的输出尽可能确定和一致避免创造性发挥这对于数据提取任务至关重要。错误处理与重试生产环境中必须在API调用处添加重试逻辑例如使用tenacity库以应对网络抖动或API限流。同时要记录每次调用的输入和输出便于后续分析和调试。成本控制监控API的token使用量。可以通过tiktoken库估算提示词和文本的token数量。对于超长文档需要权衡分块大小和API调用次数。5. 常见问题、排查技巧与进阶优化在实际使用中你一定会遇到各种问题。下面是我踩过坑后总结的一些经验和进阶思路。5.1 典型问题与解决方案问题现象可能原因排查与解决思路提取结果为空或全是null1. 文本提取失败扫描件。2. 提示词指令不清晰或字段定义有歧义。3. 文本分块过大关键信息被稀释。1. 检查提取的原始文本确认是否可读。考虑集成OCR。2. 简化提示词先尝试提取一个最明确的字段如文档标题。在提示词中加入明确的示例。3. 减小分块大小增加重叠区域。模型返回非JSON文本1. 提示词中未强制要求JSON格式。2. 系统指令system message不够强。1. 在提示词中明确要求“只输出JSON”并使用response_format{type: json_object}参数OpenAI API支持。2. 在系统消息中强调“你是一个JSON输出机器”。提取值不准确如日期格式错误1. 模型理解偏差。2. 原文表述模糊。1. 在字段说明中给出更严格的格式示例如“必须格式化为YYYY-MM-DD”。2. 使用后处理正则表达式对提取结果进行清洗和验证。例如用正则\d{4}-\d{2}-\d{2}匹配并修正日期。处理速度慢1. 串行调用API。2. 文档分块过多。1. 使用异步IOasyncio/aiohttp并发调用API可以大幅缩短处理时间。2. 优化分块策略在保证信息完整的前提下尽量减少块数。对于简单文档可以尝试不分块直接处理。API调用频繁失败或超时1. 网络问题。2. OpenAI API速率限制。1. 实现指数退避的重试机制。2. 根据你的API等级免费、付费层控制请求频率必要时添加延迟。5.2 进阶优化策略当基本流程跑通后可以考虑以下优化向生产级系统迈进混合提取策略不要完全依赖LLM。对于格式非常固定、位置明确的字段如发票右上角的发票号码可以先用正则表达式或基于坐标的规则如果使用云OCR获取了坐标进行提取。LLM只用来处理规则难以覆盖的、需要语义理解的字段。这能降低成本并提高速度。验证与修正回路设计一个两阶段提取流程。第一阶段LLM快速提取。第二阶段将提取出的结构化信息如{date: 2023-10-26, amount: 10000元}和原文片段一起交给另一个LLM调用进行验证。提示词可以是“请核对以下提取信息是否与原文一致。如果一致回复‘一致’如果不一致请给出正确的值。” 这能有效减少幻觉。领域微调如果你处理的是某一类高度专业化的文档如医疗报告、法律判决书可以考虑用这些文档的样本文本片段和对应的标注结果对开源模型如Llama 3、Qwen进行微调。微调后的模型在该领域内的提取准确率会远超通用模型且长期成本更低。向量检索增强对于超长文档如几百页的报告可以先为整个文档建立向量索引。当用户要提取特定信息时如“找出所有关于风险评估的段落”先用问题在向量库中进行语义搜索找到最相关的几个片段再将这几个片段连同问题一起发给LLM进行精准提取。这避免了让LLM阅读全文极大提升了效率和精度。5.3 成本估算与选型建议成本是必须考虑的因素。以处理一份10页、约2万汉字的合同为例约合4万tokens。纯GPT方案假设分4个块每个块提示词文本共3000 tokens输出500 tokens。总输入tokens约12000输出tokens约2000。按gpt-3.5-turbo-0125价格输入$0.0005/1K tokens输出$0.0015/1K tokens计算单次处理成本约为(12 * 0.0005) (2 * 0.0015) 0.006 0.003 $0.009不到1美分。如果用gpt-4成本可能上升10-20倍。混合方案用本地正则提取60%的字段剩下40%用GPT-3.5处理成本可以降低一半以上。选型建议原型验证/低频使用直接使用gpt-3.5-turbo快速验证想法。生产环境/高频使用采用混合策略规则LLM并积极考虑对开源模型进行微调以控制长期成本。对数据隐私要求极高部署本地开源模型如通过Ollama部署Llama 3虽然效果可能略逊于GPT-4但数据完全不出内网。这个项目的核心思想——用自然语言指令驱动强大的预训练模型来解决复杂的格式解析问题——代表了一种范式转变。它降低了传统文档自动化的技术门槛将开发者的精力从编写脆弱的解析规则转移到了设计精准的“人机对话”指令上。随着多模态大模型的发展未来甚至可以直接向模型输入PDF文件图片让它同时完成OCR和信息提取流程将进一步简化。