企业官网建设流程全解析

1. 这次到底在解决什么问题

先聊聊我为什么要折腾这么一套东西。前阵子公司内部群里又有人问“报销流程怎么走”，我翻了半天企业内部网盘，找了一份落灰的PDF，打开一看还是上个季度的旧版本。这事儿不算大，但隔三差五就来一次，行政同事每天光回复“你去看文档”就耗掉半个钟头。后来我琢磨，与其继续打口水仗，不如搞一个能自动回答这些重复问题的玩意儿。

看了下市面上的方案，大模型API已经挺便宜了，但直接让模型回答企业内部问题，它满嘴跑火车——因为模型根本没见过你公司的报销制度、请假规则、设备申领流程。这时候就得靠RAG，也就是检索增强生成。

RAG这个技术名字听着唬人，说白了就是先让系统在内部资料里“查资料”，再把查到的内容连同问题一起丢给大模型，让它照着资料作答。整个过程管这个叫“三分钟搭建”，其实是指代码层面不复杂——如果你只是想在局域网里跑通一个Demo级的FAQ问答，一个Python文件、几十行代码真的够了。但“能跑”和“能用”之间隔着一堆细节，这篇文章就是把两边都讲透。

适合谁来参考？两类人。一类是公司IT或运维，想用最低成本给内部做个知识库问答工具；另一类是刚开始接触RAG的开发者，想理解检索、向量、嵌入这些概念到底是怎么串起来的。不涉及复杂的分布式系统，也不搞微调，一切从简，但该讲清楚的原理我会尽量讲清楚。

2. 选型：四样东西定生死

2.1 为什么不用微调，非要用RAG

如果问大模型“我们公司年假制度是什么”，它大概率会给你编一个常见的劳动法条款，但未必是你们公司内部的规定。要让模型学会特定领域知识，有两条路：微调和RAG。

微调相当于给模型“补课”，但它学的是通用规律，你不一定能精确控制它记住某条具体制度。就算你喂了十万个问答对，它也可能把去年和今年的报销额度混在一起。而且微调成本高，每次制度变更都要重来一轮。

RAG的思路完全不同，它不试图让模型记住任何东西，只在每一次提问的时候，临时去文档库里找出最相关的几段内容，塞进提示词里。你可以把模型想象成一个特别听话但没记忆力的实习生，你给他一份资料，他只按资料回答，资料之外的事绝不瞎掺和。制度改了？把新文档传上去就行，模型不需要重新训练。

这就是RAG在企业FAQ场景里最大的优势——知识更新快、幻觉率低、成本可控。内部文档量级在几百篇以内时，一台普通电脑就能扛住建索引和检索的负载。

2.2 核心组件的选择与权衡

RAG实战需要四样核心组件：文档加载器、文本分割器、向量库、大模型API。每一样都有多种选择，但这次做的是“最简单版本”，我直接给出最优路径。

文档加载器处理PDF、Word、Markdown这类格式。如果公司资料主要是Word和PDF，建议统一转成纯文本再处理，省得加载器各自为政。我用的是Python的pypdf库，遇到扫描版PDF就先用OCR，但这一步不是必须的——大部分内部制度文档都是电子版。

文本分割器决定你检索的“颗粒度”。按固定字数切（比如每500字一段）是最简单的，但容易把一句话从中间砍断。经验做法是按章节或段落切，再结合一个最大长度限制。

向量库的选择决定了检索速度和后续维护成本。本地开发用FAISS最省事儿，它没有服务端，就是一个本地索引文件；如果想多台机器访问或在运维上更规范，用Chroma或pgvector也行。这篇文章先按FAISS讲，因为对新手最友好。

大模型API这块，国内基本就是几家主流的通用大模型，选一个便宜的对话模型即可。关键是调用方式得兼容OpenAI接口风格，后面写代码会省很多事。

提示：嵌入模型和对话模型不是一回事。嵌入模型把文本变成一串数字向量，对话模型负责生成回答。不要用对话模型去做文本转向量的工作，也不能指望嵌入模型给你生成回复。

3. 数据准备：FAQ系统的地基

3.1 原始文档的收集与清洗

做FAQ系统第一步不是写代码，而是把散落在各处的资料收集起来。行政的制度文件、IT的操作指南、HR的流程说明，先全部拉到同一个文件夹，然后按模块分分类。

这时候最容易踩的坑是：把几千页全量文档一股脑塞进去。其实企业内部FAQ的答案往往集中在几十份核心文档里，比如员工手册、报销指引、IT帮助文档。资料越聚焦，检索准确率越高。我之前试过把公司三年的公告全塞进去，结果问“打印机怎么连”时，检索出来的却是三年前的搬迁通知，因为那段文本里也出现了“打印机”三个字。

文档清洗的步骤很简单：过滤掉图片、页码、页眉页脚；去掉表格里那些变成乱码的符号；如果文档里有“待更新”“以最新为准”这类废弃提示，直接删掉相关段。剩下的纯文本内容统一保存为Markdown或TXT，每份文件一个独立文件，文件名起得规范一点，比如“报销流程-2024版.md”。

实操中我建议把资料按三种用途分开：第一类是问答对已有的现成FAQ，格式为“问：xxx 答：xxx”，这类最珍贵，直接用于构建问答库；第二类是制度原文和操作手册，需要后续切分；第三类是补充参考，比如常见问题汇总表。三类资料准备好之后，后面所有处理都是流水线作业。

3.2 问答库的构建策略

数据准备有个核心原则：文档切分方式要跟你的问答方式对齐。如果你打算让员工用自然语言提问（“出差报销需要什么”），那检索单元就不能是一整个Word文档，而应该是一段一段的语义块。

我采用两层策略。第一层是按章节切分，把Markdown里的每个二级标题作为一段，这一段内部如果超过1000字再按句子边界二次切分。第二层是给每个切分出来的块自动生成一个“摘要标题”，这个摘要其实就是从段首提取关键词，方便有时候直接展示给前端。

切分时有个经验参数：块长度在300到800字之间比较合适。太短语义不完整，太长检索时命中一堆无关的上下文。固定字数切分时重叠部分建议设在50到100字，避免一句话被杠在两段之间。下面是我实际使用的切分逻辑：

def split_text(text, chunk_size=500, overlap=80): if len(text) <= chunk_size: return [text] chunks = [] start = 0 while start < len(text): end = start + chunk_size # 找最近的换行符作为切点点 if end < len(text): newline_pos = text.rfind('\n', start, end) if newline_pos != -1 and newline_pos - start > chunk_size * 0.5: end = newline_pos chunks.append(text[start:end]) start = end - overlap if end < len(text) else len(text) return chunks

这段代码的关键不是算法本身，而是注释里那一行“找最近换行符”——按语义边界切分比硬切效果好得多，这是我在多次检索不准之后才悟出来的。

4. 核心实现：从索引到问答的完整链路

4.1 环境准备与依赖安装

开始写代码之前，先把Python环境准备好。我用的是Python 3.10，虚拟环境是必须的，别直接往系统环境里装依赖，避免跟其他项目打架。

依赖安装就一句话：

pip install pypdf langchain langchain-community faiss-cpu openai tiktoken flask

简单解释一下每个包的作用。pypdf用来解析PDF，langchain是一个把所有AI组件串起来的框架，faiss-cpu是向量检索库（CPU版，对个人电脑完全够用），openai是调用大模型API的SDK，tiktoken负责统计token数量，flask用来搭一个最轻量的HTTP接口。这些装完总共不到三百兆，三分钟部署是现实的。

如果公司网络环境没法直接访问外部API，后面可以换成本地部署的模型，但思路完全一样。为了演示方便，我默认还是走云端大模型API。注意调用前在环境变量里配好密钥，可别把密钥硬编码进代码里。

4.2 文本嵌入与向量化存储

文本嵌入是整个系统的核心，它的作用就是把一段自然语言变成一串浮点数数组。两个句子如果语义相近，算出来的两个向量在高维空间里挨得也近。“报销单怎么填”和“报销单填写步骤”这两句话字面不同，但向量距离会很近，这正是RAG能理解问题的关键。

嵌入我用的模型是text-embedding-3-small，它把文本编码成约1500维的向量，在效果与性能之间比较平衡。调用方式如下：

from openai import OpenAI client = OpenAI() resp = client.embeddings.create( model="text-embedding-3-small", input="报销需要什么材料" ) vector = resp.data[0].embedding

有了向量，接下来要把所有文档块的向量都算出来，然后存进FAISS索引。这一步相当于给全部资料做了一张语义地图。FAISS索引创建核心代码如下：

from langchain.embeddings import OpenAIEmbeddings from langchain.vectorstores import FAISS from langchain.schema import Document docs = [Document(page_content=chunk, metadata={"source": file_name}) for chunk in all_chunks] embeddings = OpenAIEmbeddings() vectorstore = FAISS.from_documents(docs, embeddings) vectorstore.save_local("faiss_index")

这里创建的vectorstore对象不仅存了向量，还保存了原始文本和来源信息。后续问答时需要把原始文本取出来，塞给大模型当参考资料，所以这一步不能省。保存成本地索引文件之后，下次启动系统就不用重新计算向量，直接加载即可。

4.3 检索与生成的完整整合

FAISS检索的核心是余弦相似度，查询语句先转成向量，然后在向量空间里找最相近的若干条。k值我通常设为5，同时要求返回的每条结果至少要超过一个相似度阈值，比如0.7，否则说明文档里根本没有相关内容，就不要硬凑答案。

接下来是整合成一个问答函数。这个函数做了三件事：接收用户问题、把问题向量化并检索相关文档块、拼好提示词后调用大模型生成回答。具体代码如下：

def ask(question): # 1. 检索 retriever = vectorstore.as_retriever(search_kwargs={"k": 5}) hits = retriever.get_relevant_documents(question) # 2. 拼装上下文 context = "\n\n".join([ f"[来源文件: {h.metadata['source']}]\n{h.page_content}" for h in hits ]) # 3. 调用大模型 prompt = f"""你是一名公司内部助手，请严格按照提供的资料回答用户问题。 资料如下： {context} 用户问题：{question} 要求： - 只能使用资料中的信息，不要自行发挥 - 如果资料中没有答案，请明确回复"未找到相关信息" - 回答尽量简洁清晰，用口语化的中文 """ resp = client.chat.completions.create( model="gpt-4o-mini", messages=[{"role": "user", "content": prompt}], temperature=0.2 ) return resp.choices[0].message.content

注意提示词里那句“只能使用资料中的信息”不是废话，它是压制幻觉的关键。内部问答场景宁可回答“未找到”，也不能让它瞎编一个报销流程骗同事。temperature设成0.2也是经验值，太低没灵活性，太高容易跑偏。

最后套一层Flask就变成一个内部可用的HTTP服务了：

from flask import Flask, request, jsonify app = Flask(__name__) @app.route("/qa", methods=["POST"]) def qa_endpoint(): data = request.get_json() question = data.get("question", "") if not question: return jsonify({"error": "missing question"}) answer = ask(question) return jsonify({"answer": answer}) if __name__ == "__main__": app.run(host="0.0.0.0", port=8000)

跑起来之后，公司内部的同事用浏览器打开一个小工具页面，输入问题点击提问就能拿到答案。整个链路至此闭环。

5. 实操验证与效果评估

5.1 用一个真实案例走通全流程

代码写完不代表能用，我拿公司真实的制度文件做了三轮验证。第一轮挑的是高频问题“年假休假需要提前几天申请”，结果回答是“根据员工手册，年假需提前三天在OA系统中申请，并等待直属领导审批”。

这个结果看起来没问题，但我去查了原始文档，发现里面其实同时提到了“三天”和“五个工作日”两种说法，上下文不同导致模型选错了。问题出在切分后的文本块丢失了语境，检索到的段落正好是某个例外条款的说明。于是我调整了切分规则，把“适用范围”“有效期”“例外条款”这类元信息统一附加到每个块的前缀，再重新建索引后，回答就准确了。

第二轮测试我故意问了一些文档里没有的问题，比如“公司会不会给员工发元宵节礼物”。模型按照提示词的要求回复了“未找到相关信息”，而不是顺着问题编一个节日福利方案，符合预期。

第三轮测的是边界情况：同义词替换。同事问“出差打车发票怎么报”，文档里写的是“交通票据报销流程”。系统依然能检索到正确段落，因为嵌入模型处理了语义相似度，这就是向量检索比关键词搜索强的地方。

5.2 几个指标帮你判断系统好不好用

很多团队搭完RAG就结束，根本不确定效果好不好。我建议至少要盯两个数：检索命中率和答案准确率。

检索命中率指的是：系统检索出来的前5个文档块里，有没有包含真正能回答问题的内容。计算方法很简单，挑出50个真实的员工问题，逐个把正确答案所在的文档块抽出来，然后看系统每次检索时它是不是出现在结果里。我第一版跑下来命中率只有六成，这就是为什么有些问题回答得很准、有些完全跑偏的原因。

答案准确率更主观一些，需要人工打分。让同事帮忙随机抽20个问题，对着检索出的文档看回答对不对。一般做到“90%的问题能答对”就算及格，毕竟是给内部员工用的，他们不太在意措辞优美与否，更在乎信息是否准确。

根据我的经验，如果命中率低于七成，优先优化文档清洗和切分方式，而不是盲目换大模型。大部分人以为RAG效果差是模型不行，其实八成问题出在检索阶段。

6. 使用中的三块硬骨头

6.1 检索不准：问题出在“索引”而不是“模型”

我调试RAG系统最常听到的抱怨是“这个系统很蠢，问什么都答不上”。但打开日志一看，发现真正的问题是检索回来的文本片段驴唇不对马嘴。

搜索引擎靠关键词匹配，RAG靠语义匹配，但语义匹配的前提是你要检索的文本本身是完整且有语义的。如果原始文档里全是大量只有表格和编号的条目，切出来的块读起来像天书，向量化后的结果也好不到哪里去。这类情况我一般手动加一道工序：给每个文本块的前面加一段概括说明，相当于给文档做摘要，再向量化。

另外不要迷信大模型的中间结果。有些系统先让大模型把问题改写一遍再检索，叫“查询改写”。如果原问题本身已经直白清楚了，改写反而引入噪音。我中途试过这个方法，准确率不升反降，后来干脆关掉，只做原始问题检索。

6.2 回答错误：如何用“证据链”定位问题

同事反馈“回答似乎不对”时，我最忌讳直接去调提示词，那样无异于隔空猜谜。正确做法是让系统在提供答案的同时，把检索到的原始文档段落一并输出出来，这就是证据链。

实现也很简单，在第4.3节那个ask函数里，返回值加上hits里的来源文件名和原文即可。前端可以做成“展开查看引用来源”，同事看到原文后如果觉得答案不对，一眼就能判断是检索错了还是模型理解错了。这个功能刚开始觉得没必要，后来发现它减少了大量沟通成本。

顶端有一点容易被忽略：大模型会把上下文中不同来源的信息糅合在一起，造成张冠李戴。例如两个文档块都提到“报销”，但一个是差旅费标准，一个是办公用品采购标准，模型就可能把两者混着说。我的解决办法是在拼接上下文时为每个块加上明确的前缀标签，比如“【文件一：差旅费标准】”，让模型能区分信息来源。

6.3 依赖与部署：别在环境上翻车

开发环境跑得飞起，部署到公司服务器就歇菜，这种事太常见了。RAG系统依赖Python包版本，langchain这个库迭代极快，几个月不更新可能一堆API就变了。

我的建议是锁死依赖版本，最好用requirements.txt固定所有版本号。另外faiss-cpu在Windows和Linux上安装都有小坑，Windows记得装非官方预编译包，Linux别用pip install faiss直接装，要装faiss-cpu。

公司内网不能访问外网API的场景，就要考虑换成私有化部署的模型。方案是把对话模型切到本地开源模型，比如通过Ollama跑一个量化版的大模型。检索部分本身不依赖外网，只有嵌入与对话两处调API，其中任意一个换成本地服务，整个系统就能完全内网化。

实操心得：我最后是把系统封装成一个Docker镜像，挂载在内部服务器上，数据卷存索引文件和文档目录，服务重启自动加载索引。整个过程大概一百行配置，比裸机部署省心得多。

7. 进阶方向：从Demo到正经产品

三分钟版本搭好后，接下来怎么走下去是很多人关心的问题。我这里不准备谈太宏大的规划，就说说我们是怎么从Demo走向实际可用的。

第一件事是权限控制。公司内部文档有的只能HR看，有的IT团队才能看，如果一刀切全量进向量库，那完蛋了。我见过直接把制度文档做成公开问答系统的案例，结果被不该看的人看到，尴尬到脚趾抓地。所以如果资料有敏感分级，必须先做权限过滤，在检索阶段就按用户身份过滤文档块。

第二件事是反馈闭环。每次问答应该让用户可以点“这个回答有帮助吗”，把负反馈样本存下来，定期分析。如果发现有大量负反馈集中在同一个问题，说明对应文档可能过期了或切分有问题，这时候重点维护就好，不需要动不动重建整个系统。

第三件事是定期刷新。企业内部制度每年甚至每个季度都会改版，FAISS索引不会自动感知文档变化。我的做法是写一个定时任务，每天扫描文档目录的修改时间，变了就自动重建相关文件的索引，全量重建也可以，反正是小数据量几秒钟的事。

第四件事是知识库的持续积累。光有制度文档不够，员工问出来的真实问题才是黄金知识。把从未命中或答案质量低的问题整理成新的“问-答”对，确认后补进知识库，这个系统就会越用越聪明。这也是RAG类系统最独特的优势——知识可以持续积累，模型能力固定但知识库是活的。

我自己做完这套系统之后最深的感受是：技术本身不是什么大工程，难的是把散乱的内部知识梳理成可以被检索和生成的结构化数据。这个过程中你需要跟行政、HR、IT反复确认文档的准确性和时效性，技术交流会变成沟通成本。但也正因如此，这个东西才真正有业务价值——它逼着公司把内部知识管理做了一次系统性的梳理。

如果看完这篇文章你想动手做一个，我建议循序渐进。第一天就跑通最小Demo，用三五份文档、几十行代码，感受一下向量检索是怎么回事；接下来一周完善数据清洗和切分；一个月后再考虑权限和部署。别一上来就追求完美，先让它跑起来，再让它变聪明，这是任何知识库系统都要走的必经之路。