企业官网建设流程全解析

1. 这不是简单的“切一刀”，而是让文档真正听你的话

“文档处理与文本切分”这八个字，最近在技术圈、内容运营圈、甚至教培机构的内部培训材料里高频出现。但很多人一看到这个词，下意识就想到“用Python写个for循环把长文章按标点拆成列表”——这就像买了一台顶级咖啡机，却只用来烧开水。我带过不少刚接触NLP或自动化办公的学员，他们第一次尝试做合同条款提取、会议纪要结构化、或者课件知识点自动归类时，卡住的地方从来不是模型调用，而是原始文档根本没被正确“读懂”：PDF里的表格变成乱码堆叠，扫描件里的手写批注直接消失，Word里嵌套的文本框和页眉页脚混进正文，甚至同一份PDF在不同电脑上打开，文字顺序都可能错位。这些不是bug，是文档处理的第一道真实门槛。

所谓“文本切分”，本质是在保留语义完整性的前提下，为后续任务（检索、向量化、摘要、问答）准备高质量输入单元。它不是机械断句，而是一场精细的语义手术——切得太碎，上下文断裂，模型无法理解“甲方应在收到发票后30日内付款”中的“甲方”指谁；切得太粗，单块文本超长，向量模型显存爆掉，或者检索时返回整页合同而非具体条款。我去年帮某高校实验室处理一批古籍OCR校对稿，原始扫描PDF有2000多页，每页含大量朱批、夹注、行间小字。如果直接按换行符切分，一条“校勘记”会被切成七八段，而相邻两页的同一人物传记又因排版差异被割裂。最后我们构建了一套三级切分策略：先用版面分析模型识别图文区域，再按段落逻辑合并跨页连续文本，最后在句子级插入语义锚点（如“【人物生平】”“【事件考证】”）。实测下来，后续的实体识别F1值从0.61提升到0.87，这才是切分该有的样子。

适合谁看？如果你正被这些问题困扰：

• 每次处理PDF都要手动复制粘贴，格式错乱到想砸键盘；
• 用现成的RAG工具跑自己的资料库，提问“第三章第二节讲了什么”，结果返回整本手册；
• 写爬虫抓取网页说明书，发现关键参数表总被当作文本丢进向量库；
• 或者只是想让AI助手准确引用你上传的会议录音转写稿里的某句话。
  那么这篇就是为你写的。它不讲抽象理论，只拆解真实场景中怎么选工具、怎么调参数、怎么避坑——所有结论都来自我过去三年在17个不同行业项目里的实操记录，包括法律文书、医疗报告、工业设备手册、电商商品描述等典型文档类型。

2. 文档处理不是“读取”，而是“重建”：从原始载体到语义结构的全链路解析

2.1 为什么90%的文本切分失败，根源在第一步就错了？

很多人把文档处理简化为“PDF转文本”或“Word读取”，这是最危险的认知偏差。文档的本质是结构化信息容器，而文本只是它最表层的呈现。一份标准的PDF文件包含至少五层信息：

• 物理层：像素坐标、字体大小、颜色、线条位置（扫描件只有这一层）；
• 逻辑层：段落、标题、列表、表格、页眉页脚（原生PDF才有）；
• 语义层：章节层级、引用关系、公式编号、脚注关联（需人工标注或高级解析）；
• 元数据层：作者、创建时间、关键词、文档属性（常被忽略）；
• 交互层：超链接、书签、表单域（影响内容导航）。

当你说“切分文本”，实际是在哪一层操作？如果用pdfplumber直接提取字符流，你拿到的是物理层的碎片——表格单元格内容按坐标排序，但行列关系丢失；页眉文字和正文混在一起；中文标点“。”和英文句号“.”被当作不同字符处理。我曾调试一个招标文件解析系统，客户提供的PDF里，技术参数表用虚线分隔，tabula默认识别为无边框表格，结果把“CPU型号”和“内存容量”两列数据完全错位。后来改用pdfminer的LAParams参数精细控制字符间距容忍度，并手动注入表格线检测逻辑，才解决这个问题。

提示：没有万能解析器。PDF解析效果取决于文档生成方式：由Word导出的PDF通常逻辑层完整；LaTeX生成的PDF结构清晰但数学公式复杂；扫描件必须先OCR；而某些财务软件导出的PDF会加密文本层，只留图像——这时你得先破解（合法授权前提下）或重走OCR流程。

2.2 四类主流文档的处理策略与工具选型逻辑

不同来源的文档，必须匹配不同的“重建”路径。以下是我在实际项目中验证过的方案：

① 原生可编辑文档（Word、Markdown、纯文本）

• 核心挑战：样式继承混乱（如标题1嵌套在表格内）、自定义样式丢失、中文全角/半角空格混用。
• 推荐工具链：python-docx（Word） +mistune（Markdown） + 正则预处理。
• 关键技巧：不要依赖docx的paragraph.style.name，而应检查paragraph.style.base_style和paragraph.style.priority，因为用户常修改内置样式。我处理某企业知识库时，发现其Word模板里“一级标题”被重命名为“CHAP_TITLE”，但base_style仍指向Heading 1，通过这个属性才稳定识别出章节结构。

② 标准PDF（非扫描件）

• 核心挑战：跨页表格断裂、页眉页脚污染正文、嵌入字体导致编码异常。
• 推荐工具链：pymupdf（快且支持文本定位） +pdfplumber（高精度坐标分析）组合使用。
• 实测对比：对一份50页的医疗器械说明书PDF，pymupdf提取全文耗时1.2秒，但表格识别率仅63%；pdfplumber耗时8.7秒，表格识别率92%，但需额外代码合并跨页表格。最终方案是：用pymupdf快速提取文本框架，用pdfplumber对疑似表格区域做局部高精度解析。

③ 扫描PDF/图片文档

• 核心挑战：OCR错误累积（如“0”和“O”、“1”和“l”混淆）、版面还原失真、手写体识别率低。
• 推荐工具链：PaddleOCR（中文场景首选） +layoutparser（版面分析） + 后处理规则引擎。
• 避坑经验：不要直接用OCR结果切分！必须先做版面分析。某法院案卷扫描件中，原告信息、被告信息、证据列表用不同字体和缩进区分，layoutparser能准确识别三类区域，再分别调用OCR，比全局OCR错误率降低41%。后处理规则示例：将连续三行以“证据”开头的文本合并为一个证据块，避免单条证据被切散。

④ 网页HTML文档

• 核心挑战：广告脚本干扰、动态加载内容缺失、DOM结构嵌套过深。
• 推荐工具链：BeautifulSoup（静态解析） +Playwright（动态渲染） +trafilatura（去噪专用）。
• 关键参数：trafilatura的include_tables=True和no_fallback=False必须同时启用，否则表格内容会被过滤。我爬取某汽车论坛技术帖时，发现用户上传的维修步骤表被JS动态渲染，BeautifulSoup只能抓到空<div>，改用Playwright等待table元素加载完成后再提取，准确率从38%升至96%。

2.3 文本切分的三大黄金原则：语义完整性、上下文连贯性、任务适配性

切分不是技术炫技，而是服务于下游任务。我总结出三条不可妥协的原则：

原则一：语义完整性优先于物理长度

• 错误做法：统一按512字符切分。结果：“根据《民法典》第119条规定，当事人一方不履行合同义务……”被切成两段，后半段失去法律依据。
• 正确做法：以句子为最小单位，用jieba或pkuseg进行中文分句，再按语义块合并。例如：将“甲方应于2024年6月30日前支付首期款。乙方收到款项后启动开发。”视为一个完整交易动作，即使超长也保留为一块。实测显示，在合同条款检索任务中，按语义块切分的召回率比固定长度切分高3.2倍。

原则二：上下文连贯性需主动维护

• 问题场景：会议纪要中，“张经理：我们需要加快进度。李总监：同意，但资源有限。”若按发言者切分，李总监的回应失去前因。
• 解决方案：引入“上下文窗口”机制。我的标准配置是：每个主切分块附加前2句和后1句作为上下文锚点。技术实现上，用滑动窗口遍历句子列表，当前块为中心，前后句子存入context_before和context_after字段。这样检索时，即使只匹配到“资源有限”，也能连带返回“我们需要加快进度”这一关键前提。

原则三：任务适配性决定切分粒度

• 不同任务需要不同“切片厚度”：
  • 问答系统：需细粒度（单个事实陈述，如“服务器响应时间<200ms”）；
  • 摘要生成：需中粒度（完整段落，含论点+论据）；
  • 文档分类：可粗粒度（整章或整节）。
• 实操案例：为某在线教育平台处理课程视频字幕，问答任务要求按知识点切分，我们用规则+NER识别出“【定义】”“【公式】”“【例题】”等标签，再按标签边界切分；而课程分类任务直接用每集字幕的TF-IDF向量，无需切分。

3. 实操全流程：从一份混乱的PDF说明书到可检索的知识块

3.1 准备工作：环境搭建与依赖确认

所有操作基于Python 3.9+，以下命令一次性安装核心依赖（已测试兼容性）：

pip install pymupdf pdfplumber paddleocr layoutparser jieba pkuseg trafilatura beautifulsoup4 playwright # Playwright需额外下载浏览器 playwright install chromium # PaddleOCR模型下载（首次运行自动触发）

注意：paddleocr默认下载超大模型（约500MB），若网络受限，可指定轻量模型：
ocr = PaddleOCR(use_angle_cls=False, lang="ch", det_model_dir="models/ch_ppocr_server_v2.0_det_infer/", rec_model_dir="models/ch_ppocr_server_v2.0_rec_infer/")
我在边缘设备部署时，用ch_ppocr_mobile_v2.0系列模型，体积压缩至87MB，识别速度提升2.3倍，精度损失仅1.8%。

3.2 步骤一：文档类型智能识别与预处理

不能假设所有PDF都是同一种类型。先写一个诊断函数：

import fitz # PyMuPDF from pdfplumber import PDF def diagnose_pdf(file_path): doc = fitz.open(file_path) page = doc[0] # 检查是否为扫描件：页面图像数量 > 0 且文本密度 < 5% image_count = len(page.get_images()) text_density = len(page.get_text()) / (page.rect.width * page.rect.height) if page.rect.width * page.rect.height > 0 else 0 is_scanned = image_count > 0 and text_density < 0.05 # 检查是否含可选内容（OCG图层，常见于工程图纸） has_ocg = bool(doc.xref_length() > 0 and doc.xref_object(1).get("OCG")) # 检查加密状态 is_encrypted = doc.is_encrypted return { "is_scanned": is_scanned, "has_ocg": has_ocg, "is_encrypted": is_encrypted, "page_count": len(doc), "first_page_text_sample": page.get_text()[:100] } # 示例输出 # {'is_scanned': False, 'has_ocg': False, 'is_encrypted': False, 'page_count': 42, 'first_page_text_sample': '产品说明书\n型号：XYZ-2000\n版本：V3.2'}

这个诊断结果决定后续流程分支。比如is_scanned=True，则跳过PDF解析，直入OCR流程；is_encrypted=True，则需先调用doc.authenticate("password")（密码需业务方提供）。

3.3 步骤二：非扫描PDF的结构化解析（以设备说明书为例）

目标：从42页PDF中精准提取“技术参数”“安全警告”“故障排除”三个章节，每个章节内按子项切分。

第一阶段：目录导航与章节定位
很多PDF自带书签（Bookmarks），这是最可靠的导航源：

def extract_bookmarks(doc): bookmarks = [] for item in doc.get_toc(): # item: [level, title, page_number, ...] if item[0] == 1: # 一级标题 bookmarks.append({ "title": item[1].strip(), "start_page": item[2], "end_page": None # 待计算 }) return bookmarks # 获取书签后，需确定每章结束页。策略：找下一个一级标题的前一页 bookmarks = extract_bookmarks(doc) for i, bm in enumerate(bookmarks): if i < len(bookmarks) - 1: bm["end_page"] = bookmarks[i+1]["start_page"] - 1 else: bm["end_page"] = len(doc) - 1

第二阶段：章节内语义块切分
针对“故障排除”章节（假设在第28-35页），我们不按页切分，而按“问题-原因-解决方案”三元组切分：

import re from pdfplumber.page import Page def split_troubleshooting_section(pdf_path, start_page, end_page): with PDF(pdf_path) as pdf: blocks = [] for page_num in range(start_page, end_page + 1): page = pdf.pages[page_num] # 提取所有文本块（按视觉区块） for obj in page.chars: # 过滤页眉页脚：y坐标在顶部10%或底部5%的文本 if obj["y0"] < page.height * 0.1 or obj["y1"] > page.height * 0.95: continue # 按字体大小聚类，识别标题（字号>14）和正文（字号<12） font_sizes = [char["size"] for char in page.chars] title_size = max(font_sizes) if font_sizes else 12 body_size = min([s for s in font_sizes if s < title_size], default=10) # 提取所有文本行 lines = page.extract_text_lines() for line in lines: text = line["text"].strip() if not text: continue # 匹配故障条目模式：以数字+点开头，或“Q:”“问题：”等 if re.match(r'^\d+\.\s+|^[Qq][:：]\s+|^[问][题][:：]\s+', text): blocks.append({"type": "issue", "content": text, "page": page_num}) elif re.match(r'^[原][因][:：]\s+|^[Cc][a][u][s][e][:：]\s+', text): blocks.append({"type": "cause", "content": text, "page": page_num}) elif re.match(r'^[解][决][:：]\s+|^[Ss][o][l][u][t][i][o][n][:：]\s+', text): blocks.append({"type": "solution", "content": text, "page": page_num}) else: # 归入上一个块的正文 if blocks and blocks[-1]["type"] in ["issue", "cause", "solution"]: blocks[-1]["content"] += "\n" + text return blocks # 输出示例： # [ # {"type": "issue", "content": "1. 设备无法启动\n电源指示灯不亮", "page": 28}, # {"type": "cause", "content": "原因：电源线未连接或插座无电", "page": 28}, # {"type": "solution", "content": "解决方案：检查电源线连接，用万用表测试插座电压", "page": 28} # ]

第三阶段：后处理与标准化
将上述块清洗为标准JSON格式，供后续系统使用：

import json def standardize_blocks(blocks): standardized = [] current_issue = None for block in blocks: if block["type"] == "issue": if current_issue: standardized.append(current_issue) current_issue = { "id": f"issue_{len(standardized)+1}", "question": block["content"], "cause": "", "solution": "", "source_page": block["page"] } elif block["type"] == "cause" and current_issue: current_issue["cause"] = block["content"] elif block["type"] == "solution" and current_issue: current_issue["solution"] = block["content"] if current_issue: standardized.append(current_issue) return standardized # 最终输出符合RAG系统要求的结构化数据 with open("troubleshooting_knowledge.json", "w", encoding="utf-8") as f: json.dump(standardize_blocks(blocks), f, ensure_ascii=False, indent=2)

3.4 步骤三：扫描PDF的OCR增强切分（以手写审批单为例）

某政务系统需处理扫描的纸质审批单，含印刷体表头和手写签名栏。难点在于：手写部分OCR错误率高，但又是关键信息。

第一阶段：版面分割（Layout Analysis）
用layoutparser识别不同区域：

import layoutparser as lp import cv2 # 加载预训练模型（中文文档优化版） model = lp.Detectron2LayoutModel( config_path="lp://PubLayNet/mask_rcnn_X_101_32x8d_FPN_3x/config", label_map={0: "Text", 1: "Title", 2: "List", 3: "Table", 4: "Figure"}, extra_config=["MODEL.ROI_HEADS.SCORE_THRESH_TEST", 0.8] ) # 读取扫描件 image = cv2.imread("approval_form.jpg") layout = model.detect(image) # 可视化版面结果（调试用） lp.draw_box(image, layout, box_width=3) # 提取关键区域：表头（Title）、申请人信息（Text）、审批意见（Text）、签名（Figure） header_region = None applicant_region = None opinion_region = None signature_region = None for block in layout: if block.type == "Title" and "审批单" in block.text: header_region = block elif block.type == "Text" and "申请人" in block.text: applicant_region = block elif block.type == "Text" and ("审批意见" in block.text or "领导批示" in block.text): opinion_region = block elif block.type == "Figure" and block.score > 0.9: signature_region = block

第二阶段：区域化OCR与置信度加权
对不同区域用不同OCR策略：

from paddleocr import PaddleOCR # 初始化OCR引擎 ocr = PaddleOCR(use_angle_cls=True, lang="ch") def ocr_by_region(image, region, region_name): # 裁剪区域 x1, y1, x2, y2 = int(region.block.x_1), int(region.block.y_1), int(region.block.x_2), int(region.block.y_2) cropped = image[y1:y2, x1:x2] if region_name == "signature": # 签名区域：关闭角度分类，专注笔画识别 result = ocr.ocr(cropped, cls=False, det=True) else: # 其他区域：启用角度分类 result = ocr.ocr(cropped, cls=True, det=True) # 提取文本并计算平均置信度 texts = [] confidences = [] for line in result: if line and len(line) > 1: text, confidence = line[1] texts.append(text) confidences.append(confidence) avg_conf = sum(confidences) / len(confidences) if confidences else 0 return "".join(texts), avg_conf # 分别OCR各区域 header_text, header_conf = ocr_by_region(image, header_region, "header") applicant_text, applicant_conf = ocr_by_region(image, applicant_region, "applicant") opinion_text, opinion_conf = ocr_by_region(image, opinion_region, "opinion") signature_text, signature_conf = ocr_by_region(image, signature_region, "signature") # 关键决策：签名区域置信度<0.6时，标记为“需人工复核” if signature_conf < 0.6: print(f"警告：签名区域识别置信度{signature_conf:.2f}，建议人工审核")

第三阶段：语义切分与结构化输出
将OCR结果按业务字段切分：

def parse_approval_form(header, applicant, opinion, signature): # 用正则提取关键字段 fields = {} # 提取申请日期（格式：2024年06月15日） date_match = re.search(r'(\d{4}年\d{1,2}月\d{1,2}日)', applicant) fields["apply_date"] = date_match.group(1) if date_match else "" # 提取申请人姓名（在“申请人：”后） name_match = re.search(r'申请人[:：]\s*([\u4e00-\u9fa5]{2,4})', applicant) fields["applicant_name"] = name_match.group(1) if name_match else "" # 审批意见切分：按换行和分号分割，过滤空行 opinions = [op.strip() for op in opinion.split('\n') if op.strip()] if opinions: fields["approval_opinions"] = opinions else: fields["approval_opinions"] = [opinion] # 退化为单条 fields["signature"] = signature fields["signature_confidence"] = signature_conf return fields result = parse_approval_form(header_text, applicant_text, opinion_text, signature_text) print(json.dumps(result, ensure_ascii=False, indent=2)) # 输出： # { # "apply_date": "2024年06月15日", # "applicant_name": "张伟", # "approval_opinions": ["同意办理", "请财务部配合"], # "signature": "李明", # "signature_confidence": 0.87 # }

4. 那些没人告诉你的坑：12个真实踩过的雷与独家解决方案

4.1 PDF解析类问题排查速查表

实操心得：遇到表格错位，别急着换库。先用pdfplumber的page.to_image().save("debug.png")保存页面图像，再用cv2画出page.find_tables()识别的表格线，肉眼确认是识别不准还是PDF本身排版缺陷。我处理某银行对账单时，发现是PDF生成时用了微小的字体偏移制造“伪表格线”，最终用cv2.HoughLinesP检测真实线条，准确率提升至99.2%。

4.2 OCR识别类问题避坑指南

坑一：扫描分辨率陷阱

• 现象：OCR识别率忽高忽低，同一份文档在不同扫描仪上结果差异大。
• 真相：PaddleOCR最佳输入分辨率为300-600 DPI。低于300 DPI，笔画粘连；高于600 DPI，噪声放大。某政务大厅用200 DPI扫描仪，导致“0”和“O”错误率达37%。
• 解法：扫描前统一设置DPI为400，并在OCR前用cv2.resize插值到标准尺寸：

  # 将图像缩放到宽度1200px（保持宽高比） h, w = img.shape[:2] scale = 1200 / w resized = cv2.resize(img, (1200, int(h * scale)), interpolation=cv2.INTER_AREA)

坑二：手写体“伪OCR”幻觉

• 现象：OCR对签名区域返回看似合理的汉字，但实际是随机组合（如把潦草签名识成“王小明”）。
• 真相：PaddleOCR的识别模型在训练时见过大量印刷体，对手写体缺乏判别力，会强行匹配最接近的字。
• 解法：引入“手写体置信度过滤”+“字频校验”。我的方案：
  1. 对签名区域OCR结果，要求每个字的置信度>0.7；
  2. 检查结果是否在《通用规范汉字表》前3500字内；
  3. 若不满足，标记为“UNKNOWN_SIGNATURE”，强制人工审核。
     实测将误识别率从28%降至0.3%。

坑三：PDF加密的隐形墙

• 现象：pymupdf报错ValueError: Document is encrypted，但用Adobe Reader能正常打开。
• 真相：PDF可能启用了“权限密码”（限制复制/打印），而非“打开密码”。pymupdf默认拒绝处理。
• 解法：用fitz.open()时传入空密码尝试解锁：

  try: doc = fitz.open(file_path) except Exception as e: if "encrypted" in str(e).lower(): doc = fitz.open(file_path, "") # 传入空字符串尝试

4.3 切分逻辑类致命错误

错误一：用英文分词逻辑切中文

• 典型表现：nltk.word_tokenize或spaCy直接处理中文，把“人工智能”切成“人工”“智能”，破坏语义。
• 正确姿势：中文必须用专业分词器。我的选择优先级：
  1. pkuseg（北大开源，领域自适应强，支持金融、法律等专业词典）；
  2. jieba（速度快，但需手动添加专业词：jieba.add_word("违约金", freq=1000)）；
  3. hanlp（功能全，但内存占用高）。
• 血泪教训：某合同审查项目初期用spaCy，导致“定金”和“订金”被切散，无法识别法律效力差异，返工3天。

错误二：忽视标点符号的语义权重

• 问题：简单用。！？；切分句子，但中文里“…”“——”“（）”同样承载语义。例如：“系统支持API调用（需申请密钥）。”若按句号切分，括号内关键条件丢失。
• 解决方案：用正则构建智能分句模式：

  import re def smart_split_sentences(text): # 匹配句末标点，但排除括号、引号内的标点 pattern = r'(?<!\w\.\w.)(?<![A-Z][a-z]\.)(?<=\.|\!|\?|。|！|？|；|;)\s' sentences = re.split(pattern, text) return [s.strip() for s in sentences if s.strip()]

  并在切分后，用re.search(r'\(([^)]+)\)', sentence)提取括号内补充说明，作为该句子的context字段。

错误三：跨文档一致性灾难

• 场景：处理100份不同部门提交的报销单，格式各异。
• 陷阱：为每份单定制切分规则，导致维护成本爆炸。
• 破局点：建立“文档指纹”体系。我的实践：
  1. 提取每份文档的3个特征：页数、平均行数/页、标题字体大小方差；
  2. 聚类相似文档（K-means，K=5）；
  3. 为每个簇训练专属OCR后处理规则。
     结果：规则数量从100套减至5套，准确率反而提升12%。

5. 进阶思考：当切分遇上大模型，如何让AI真正理解你的文档

5.1 切分粒度与Embedding模型的隐式耦合

很多人以为“切得越细越好”，但Embedding模型（如bge-m3、text2vec）有其固有“感受野”。我做过一组对照实验：用同一份5000字技术文档，分别按128/256/512/1024字符切分，输入bge-m3生成向量，再计算所有向量的平均余弦相似度：

关键发现：512字符是bge-m3的甜蜜点。小于512，语义碎片化，向量无法表达完整概念；大于512，模型注意力分散，关键信息被稀释。这解释了为什么很多RAG项目调优时卡在“切分长度”这个参数上——它不是任意值，而是模型能力的镜像。

5.2 动态切分：让切分逻辑随内容自适应

静态规则总有盲区。我设计了一个“动态切分器”，根据文本内容实时调整策略：

def dynamic_chunker(text, base_size=512): # 步骤1：检测文本类型 if re.search(r'第[零一二三四五六七八九十\d]+[章条]', text[:200]): return split_by_chapter(text) # 按章节切 elif re.search(r'Q\d+[:：]|问题[:：]', text[:100]): return split_by_qa(text) # 按问答对切 elif len(re.findall(r'[，。！？；：""''（）\[\]{}]', text)) / len(text) > 0.05: return split_by_sentence(text, max_len=base_size) # 高标点密度→按句切 else: return [text[i:i+base_size] for i in range(0, len(text), base_size)] # 默认切 # 在RAG系统中，每块文本附带"chunk_strategy"字段，便于后续分析 chunks = dynamic_chunker(full_text) for i, chunk in enumerate(chunks): chunks[i] = { "content": chunk, "strategy": "chapter" if "第" in chunk[:50] else "sentence", "length": len(chunk) }

这个设计让系统在处理混合文档（如带附录的合同）时，主文按条款切，附录按段落切，不再“一刀切”。

5.3 切分质量的量化评估：不只是看准确率

我定义了三个可落地的评估维度：

① 语义连贯性得分（SCS）
计算每块文本内，相邻句子的BERTScore相似度均值。SCS > 0.65为合格。某法律文档切分后SCS仅0.42，追查发现是把“本协议自双方签字盖章之日起