智能问答系统落地：Word文档解析与RAG检索链路实战

简介面向自然语言处理初学者与AI项目开发者的智能问答系统学习资料围绕问题理解、知识获取、答案生成与评估等核心模块系统梳理了智能问答的整体架构与工作流程。内容重点覆盖分词、文本相似度计算等关键算法详细讲解基于词典分词、正向/逆向最大匹配法以及余弦相似度、Jaccard相似度、编辑距离等常见方法并配有可直接运行的代码示例便于从理论到实践的平滑过渡。压缩包为82.01MB的rar格式文档与代码配套既有系统介绍也有算法原理说明适合按章节研读与调试。目前已有383人加入学习读者可借此了解Python、NLTK、Spacy、TensorFlow或PyTorch等工具在问答系统中的应用通过构建语料库、训练模型、优化问答性能切实提升自然语言处理与AI工程实践能力。1. 智能问答项目还没跑起来就被Word卡住这包代码到底在解决什么老板丢给我一个压缩包名字就叫“智能问答项目代码与文档_word 代码”解压之后一半是.py文件一半是Word写的说明文档。这类项目现在很常见公司里有几千份合同、制度、方案全是Word格式员工想查条款得一个个翻文件领导要的是一个能直接回答“验收标准是什么”的智能问答系统。整套系统能不能跑通先看有没有把Word文档干净、有序地读出来而不是先看大模型多聪明。Word不是纯文本里面段落、表格、页眉页脚混在一起直接丢给大模型或检索库结果往往是一团乱麻。我会把链路拆开讲Word解析、切块、向量检索、答案生成以及我踩过的坑。适合手里有存量文档、想私有化部署的团队也适合第一次做RAG的工程师照着复现。2. 智能问答系统先想清楚文档链路选型、目录结构与Word解析方案很多第一次做智能问答系统的人上来就挑大模型把文档解析当成一个“读文件”的小事。实际落地时恰恰相反文档解析决定了下游检索和生成的天花板。常见做法是用LangChain这类框架把读文档、切块、检索串起来复杂一点的用LangGraph做状态编排Java团队会参考langchain4j的开发文档思路都是相通的。我一般不直接用现成的pipeline原因很现实公司文档格式五花八门通用loader处理Word时经常把表格丢掉、把页眉页脚也读进来出了问题是个黑匣子很难定位是解析错还是检索错。自己控制链路之后每一环都能打印中间结果哪个环节烂掉一目了然。2.1 一条问答链路先想清楚解析、切分、向量化、检索、生成智能问答系统的数据流按顺序分成五段。第一段是Word解析把docx转成markdown或纯文本保留标题层级和表格结构第二段是切分按标题和段落边界切成块每块500到800字块与块之间留50到100字重叠第三段是向量化用embedding模型把每个块转成向量存进向量库第四段是检索拿用户问题向量去召回最相似的TopK个块第五段是生成把召回内容拼进提示词交给大模型回答。这里最容易被低估的是第一段。Word本质是一个zip包里面的document.xml把段落、表格、批注、修订记录全混在一起用普通的纯文本提取表格会变成一串连续字符标题层级全部丢失后续切分和检索都会跟着崩。所以文档结构化解析不是可选项是必选项。需要注意的是这五段是相互影响的。标题层级丢了的文档切分就找不到边界切分不合理检索召回的内容就支离破碎召回内容不对再强的生成模型也只能编。我见过太多项目在检索阶段反复调参数最后发现是解析阶段就把顺序搞错了。2.2 解析Word的三个候选方案怎么选python-docx、docx2txt 和 Office 转 HTML处理Word文档通常有三个候选方案它们的定位差异很大。方案能拿到什么依赖适合场景python-docx段落样式、标题层级、表格单元格、页眉页脚python-docx库需要结构化信息是我的默认选择docx2txt纯文本速度快docx2txt库只做全文检索不关心标题层级LibreOffice转HTML保留复杂排版可继续抓取结构外部进程排版极度复杂比如带文本框、公式的文档我一般优先用python-docx因为它对齐了“文档结构化解析”的核心诉求标题在段落样式里能读到表格能逐格读取所有内容可以按文档顺序输出成统一的中间格式。docx2txt虽然快但拿到手的是一坨纯文本表格和正文的顺序关系完全丢失不适合做问答检索。选型时可以先用一个技巧确认docx内部结构用zipfile直接解压看document.xml的节点排列能快速判断这份文档到底是简单段落还是嵌套表格加文本框的复杂排版。这个判断直接影响你后续要不要单独写处理逻辑而不是把时间浪费在试错上。2.3 项目目录怎么规划代码、文档、语料、向量库分开放拿到项目后先别急着写解析代码把目录结构定下来后面能少踩很多坑。我会按“代码、原始文档、中间产物、向量库”四类分开中间产物一定要落盘因为排查问题时可以直接看不用重新跑全流程。project/ ├── docs/ # 原始Word文档和需求文档 │ ├── source/ # 待解析的docx文件 │ └── requirements/ # 需求文档、接口文档 ├── scripts/ # 解析、切分、检索、接口代码 │ ├── parse_docx.py │ ├── split_chunks.py │ ├── build_index.py │ └── api_server.py ├── output/ # 中间产物可人工检查 │ ├── parsed/ # 解析后的markdown文件 │ ├── chunks/ # 切分后的语料块 │ └── faiss_index/ # 向量库索引 └── eval/ # 评估集与回归脚本 ├── eval.jsonl └── run_eval.py每个解析函数都写文档注释docstring里说清楚输入输出、返回什么格式。这个习惯在项目后期特别有用因为切分逻辑改过两轮之后你自己都可能不记得当初为什么这么处理段落边界。output目录下的中间产物建议用统一的命名规则比如按原文档名加页码时间戳方便回溯。需求文档和接口文档放一起也值得养成习惯。业务方改需求是常态今天说只要文本明天说要支持表格后天说要带来源没有一份记录变更的文档你会被来回改到崩溃。3. 把Word拆成能检索的语料解析代码、切分参数与结构化输出这一章是整个智能问答项目的核心工序。前面架构搭得再好解析代码本身写得糙后面全白费。我会给一版能直接跑的解析代码再讲清楚切分参数怎么设、边界情况怎么处理。3.1 用python-docx按文档顺序抽取段落和表格一版能跑通的解析代码先看代码按文档顺序遍历把段落和表格转成markdown格式from docx import Document from docx.table import Table from docx.text.paragraph import Paragraph from docx.oxml.ns import qn def iter_block_items(parent): 按文档顺序遍历段落和表格节点保持原始先后关系 body parent.element.body for child in body.iterchildren(): if child.tag qn(w:p): yield Paragraph(child, parent) elif child.tag qn(w:tbl): yield Table(child, parent) def table_to_markdown(table): 表格转成markdown格式单元格换行替换为空格 rows [] for row in table.rows: cells [c.text.strip().replace(\n, ) for c in row.cells] rows.append(| | .join(cells) |) if rows: col_count rows[0].count(|) - 1 sep | | .join([---] * col_count) | rows.insert(1, sep) return \n.join(rows) def docx_to_markdown(path): docx转markdown标题映射为#级别 doc Document(path) lines [] for block in iter_block_items(doc): if isinstance(block, Paragraph): style block.style.name if block.style else text block.text.strip() if not text: continue if style.startswith(Heading 1): lines.append(f# {text}) elif style.startswith(Heading 2): lines.append(f## {text}) elif style.startswith(Heading 3): lines.append(f### {text}) else: lines.append(text) elif isinstance(block, Table): lines.append(table_to_markdown(block)) return \n.join(lines)这段代码的关键在于遍历doc.element.body的子节点而不是用doc.paragraphs和doc.tables分开拿。doc.paragraphs只返回段落doc.tables只返回表格两者都会丢掉“表格出现在哪两个段落之间”的顺序信息。顺序一旦乱了上下文关系就没了检索结果会变得非常奇怪这是文档结构化解析里最容易翻车的点。table_to_markdown里把单元格内的换行符替换成空格是因为单元格里经常有多行文本不处理会把markdown表格撑跨解析出来的结果没法看。另外我默认每个表格独立成段后续切分时整体保留不对表格内部做切割原因后面会讲。3.2 按标题切块chunk_size、overlap和“标题优先”的取舍解析完Word之后得到的是一份markdown格式的完整文本。接下来要把它切成检索用的chunk切分策略直接影响召回效果。我用的方法是按行扫描以标题行为边界同时控制每块长度和重叠区def is_heading_line(line): return line.startswith(#) def split_by_heading(md_text, max_chars600, overlap60): 按标题切块max_chars控制块长overlap控制重叠区标题开头优先保留 lines md_text.split(\n) chunks [] current [] current_len 0 for line in lines: if current and current_len len(line) max_chars: # 取当前块末尾几行作为重叠区避免上下文被硬切断 tail [] tail_len 0 for l in reversed(current): if tail_len len(l) overlap: break tail.insert(0, l) tail_len len(l) 1 # 重叠区如果以标题开头去掉标题防止标题重复出现 if tail and is_heading_line(tail[0]): tail tail[1:] chunks.append(\n.join(current)) current tail current_len tail_len current.append(line) current_len len(line) 1 if current: chunks.append(\n.join(current)) return chunksmax_chars我一般设600左右中文按字符数算。overlap设60到80作用是让相邻两个chunk之间有上下文衔接检索时不会因为一句话恰好在边界处被切成两半而丢失信息。实际调参时检索效果差先调overlap不要一上来就动max_chars因为块越大向量化后的语义越分散召回准确性反而下降。重叠区以标题开头时要把标题去掉这个细节很多人会漏。否则同一标题出现在多个chunk里检索时会被反复命中回答内容高度重复。另外解析文档时遇到独立表格块我会单独走一个分支不参与上面的字符切分因为表格行被切开后语义基本丢光要么整表为一个chunk要么按表头分组再切。3.3 文档结构化解析的边界图片、扫描件和嵌套表格怎么处理解析Word时最怕的不是段落而是图片、扫描件和嵌套表格这三类边界情况。Word里的图片本身没有文字如果一张流程图里写着关键操作步骤解析完之后这一段就是空白。扫描件更极端整页都是图片纯文本解析出来可能只有几十个字符等于这页白费。常见做法是接OCR识别。图片类和扫描件类文档先走OCR把文字抽出来作为附加文本放回原位置。注意OCR结果会有识别错误直接混入原文会污染检索结果我一般把OCR文本单独标记比如加一行[OCR]前缀检索时看得到来源评估时也能区分效果。嵌套表格是另一个坑。python-docx读取嵌套表格时会被拍平外层表格和里层表格的单元格混在一起多次读取还可能读到重复单元格。处理方式是预处理阶段先把嵌套表格拆开或单独抽取内层表格并做标记。页眉页脚也要注意默认读取不包含但用模板样式时页眉会混进章节标题需要在切块前过滤掉否则检索会命中一堆重复的“公司内部文件”之类字样。4. 从语料到回答向量化、召回重排与问答接口落地的参数细节语料准备好之后进入向量化和检索环节。这个阶段的技术选择很多但核心参数就那几个调明白了系统就稳了一半。这一章讲模型选型、召回参数和接口设计每一处都能直接抄作业。4.1 向量化模型选型中文场景先看检索效果再看速度embedding模型决定的是“语义相似度”准不准。中文场景下常见的选择是BGE、M3E这类针对性优化的中文模型生成侧可以接DeepSeek这类模型。我选型的标准很简单拿自己业务里的50个真实问题先跑一遍召回看答案对应的chunk有没有进TopK再比较维度、推理速度、内存占用。文本清洗这一步不要省。解析出的markdown里经常有空行、全角半角混用、重复段落清洗规则要包含三件事合并连续空行、统一全角半角空格、去掉完全相同的段落。清洗后的语料再切块和向量化检索噪声会小很多。一个容易被忽略的点标题要保留在chunk里而且放在开头。因为向量化时模型看到的是整段文本标题是这段内容最重要的上下文。我见过有人切块后把标题丢弃只留正文结果检索召回的片段语义相似但完全不是想要的位置。embedding模型虽然能理解语义但依赖上下文线索标题越清晰召回越准确。4.2 检索召回TopK、相似度阈值和重排三个参数怎么调向量检索我用FAISS稳定、快、可本地部署。下面是最小可用的检索代码import faiss import numpy as np class VectorStore: def __init__(self, dim): # 内积索引配合向量归一化后等价于余弦相似度 self.index faiss.IndexFlatIP(dim) self.chunks [] def add(self, embeddings, chunks): vectors np.array(embeddings).astype(float32) faiss.normalize_L2(vectors) self.index.add(vectors) self.chunks.extend(chunks) def search(self, query_vec, top_k10): q np.array([query_vec]).astype(float32) faiss.normalize_L2(q) scores, idxs self.index.search(q, top_k) return [(self.chunks[i], float(score)) for i, score in zip(idxs[0], scores[0]) if i 0]IndexFlatIP配合normalize_L2使用内积结果就是余弦相似度中文场景下比L2距离稳定得多因为L2对向量模长敏感而文本向量化后的模长本身没有太多意义。TopK我一般先设10召回后做重排取前3而不是直接把TopK设成3因为重排模型能利用更完整的候选集找到被embedding排名压下去的正确结果。相似度阈值不能照抄网上的经验值。不同embedding模型的分数分布差异很大有的模型不相似的文本也有0.6分有的模型0.3就算接近。正确做法是把一批真实query的检索分数打印出来看分布再定阈值。我通常收集20到30条query跑一遍画出分数区间取“明显区分开”的位置做阈值低于阈值的chunk直接丢弃。重排层建议用交叉编码器它能把query和chunk拼在一起算相关性比embedding的双塔结构更准。重排后只取前3个chunk拼进提示词既能控制上下文长度也能减少无关信息干扰模型生成。4.3 问答接口与接口文档最少要提供哪些字段智能问答系统最终要给业务方用接口设计不能只返回一个答案字符串。我用FastAPI写一个最小可用的问答接口示例代码如下from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class AskRequest(BaseModel): question: str top_k: int 10 class AskResponse(BaseModel): answer: str sources: list app.post(/ask) def ask(req: AskRequest): query_vec embed(req.question) hits store.search(query_vec, top_kreq.top_k) context \n\n.join( f【来源{c.meta[doc]}】\n{c.text} for c, _ in hits ) answer generate(context, req.question) return AskResponse(answeranswer, sources[c.meta for c, _ in hits])接口文档里至少要写清楚四样东西请求参数、响应字段、异常情况、限流策略。请求参数里question必填top_k可选响应里answer是回答文本sources里放来源文档名、标题路径、页码这些元信息。这里特别强调sources必须有业务方拿答案去核对时没有来源的智能问答系统就是给自己埋雷。生成环节如果接了DeepSeek这类在线模型要注意上下文长度的限制TopK取多了会截断。如果本地部署开源模型还要处理并发排队。我一般会先把上面的最小链路跑通再考虑接入LangGraph这类编排框架不要在第一步就把系统搞复杂否则出了问题都分不清是编排层的问题还是底层检索的问题。5. 智能问答落地避坑Word解析和检索质量的5个真实翻车点这一章写的都是实际推进项目时的血泪经验。每一条都按“现象、原因、解决”来写你可以直接对照排查。5.1 表格与正文的顺序被打乱现象解析完的markdown里所有表格都跑到文档末尾正文和表格的对应关系全部错乱。问“设备清单在哪一页”时检索到的chunk里只有表格没有上下文。原因用了doc.paragraphs和doc.tables分别读取先拼接段落再拼接表格表格原本在文档中哪个位置的信息丢了。这个问题在只处理纯文本时看不出来一旦文档里表格占比高检索结果就明显偏离。解决用第3章里的iter_block_items方案按body子节点的出现顺序遍历输出。解析完成后不要急着往下走人工抽查10个位置对比原文确认顺序一致。这个检查用不了两分钟但能避免下游全部白跑。5.2 切分把一句话切成两半答案永远不完整现象问“验收流程分几步”返回的答案只有半句说“根据合同第”然后戛然而止。打开chunk定位发现这句话被一块硬边界从中间劈开了。原因切分直接按字符数硬切没有考虑段落边界。中文字符短600字刚好卡在一句话中间的概率很高尤其是长句多的合同文本。解决切分逻辑改成按行扫描段落足够短就整段保留只有超过max_chars的段落才在标点处断开。同时打开overlap把上一块末尾的60到80字接到下一块开头保证被边界影响的内容能被重复检索到。5.3 检索召回一堆无关内容问A答B现象问“项目延期违约责任”召回的chunk全是“延期”出现过的其他章节内容合同里的违约条款排名反而很低。看起来模型理解了词但没理解问题指向的是合同条款。原因一是chunk里没有标题上下文embedding只看到孤立正文二是没有重排层纯靠向量相似度排序容易跑偏三是相似度阈值设得太低什么内容都放进来。解决切分时把标题拼到chunk开头让“违约责任”这个章节标识参与向量化。加上交叉编码器重排把候选集中语义不对的chunk压下去。最后把真实query的分数分布打出来重新定阈值而不是沿用默认值。5.4 扫描件和图片文档解析出来是空串现象有的制度文档看起来是Word打开后每页都是一张扫描图片。解析结果只有几十个字符检索时根本命不中相关内容。这种情况最容易在文档量大的时候蒙混过关因为统计上看不清单个文件的解析质量。原因Word里根本没有文字层纯文本提取无能为力。这类文档的来源多半是纸质文件扫描后直接转存的docx。解决增加前置检测解析后统计有效文本长度低于阈值的文档自动标记为“疑似扫描件”单独走OCR识别流程。OCR结果建议加[OCR]前缀单独存放避免识别错误污染正常语料。识别后要人工抽检几页确认关键字段没被识别错。5.5 生成模型回答重复或输出符号堆砌现象回答本身通顺但翻来覆去重复同一句话或者输出一堆项目符号和特殊符号业务方看了直接截图来问“这系统是不是坏了”。原因提示词里没给格式约束上下文里重复内容多解码参数没调。模型看到多个chunk里有相似的句子就容易陷入重复循环。解决提示词里明确要求“无法从给定内容中找到答案时直接说明不知道”并限定回答格式比如“分点列出每一点不超过两行”。解码参数上重复出现时先调低temperature再适当加大top_p或者减少chunk重叠区域长度降低重复内容进入上下文的概率。这五个问题如果都排查完还不生效把中间markdown打出来人工读一遍。RAG项目里八成的问题出在语料不在模型。这听起来有点玄学但经验就是这样语料干净了大部分参数不用怎么调就能跑出能看的结果。6. 上线前多做一步答案溯源加评估集让问答结果可验证系统能跑通只是第一步真正让业务方敢用靠的是答案可验证、改动可回归。我上线前必做两件事一件是给答案加来源另一件是建评估集。答案溯源说起来简单把chunk的来源信息包括文档名、标题路径、页码拼进提示词要求模型回答时带上来源描述接口把sources原样返回给前端。这样业务方看到任何回答都能自己去翻原文核对不用问你“这个答案哪来的”。这一步做完整个智能问答系统的可信度会明显上一个台阶。第二件事是评估集回归。从真实业务里挑20到50个问题每个问题标注期望命中的文档编号存成jsonl文件。以后每次改解析逻辑、切分参数或检索策略都跑一遍评估脚本统计期望文档出现在召回TopK里的比例import json hits_count 0 total 0 for line in open(eval.jsonl, encodingutf-8): item json.loads(line) hits store.search(embed(item[question]), top_k5) hit_ids {c.meta[id] for c, _ in hits} if item[expected_id] in hit_ids: hits_count 1 total 1 print(f召回命中率: {hits_count / total:.2%})这个命中率不直接等于回答质量但每次改动后跑一遍能快速判断是变好还是变坏。我一开始偷懒没做这步上线后被业务同事拿一个合同条款问住检索结果完全对不上才回头补评估集。从那以后任何解析或检索的改动都先跑一遍评估再发布再没因为“改好了A又弄坏了B”这种问题熬夜排查。希望帮到你。本文还有配套的精品资源点击获取