企业官网建设流程全解析

本地AI知识库问答这个系列写到第三篇，前面已经把环境、代码骨架和基础问答链路跑通了。很多人到这一步就开始卡壳：模型文件到底放哪、怎么加载，知识库的文档应该怎么塞进去，参数怎么调。这篇就把"配置模型"和"配置知识库"这两件最关键的事一次性讲透。它解决的不是"能不能跑"的问题，而是"跑得对不对、回答得准不准"的问题，适合已经把代码骨架跑通、准备接私域知识的开发者。

1. 配置前先把链路摸清楚

1.1 最短可用链路：文档进去、答案出来

本地AI知识库问答系统，底层逻辑是现在很成熟的RAG（检索增强生成）架构，说穿了就是一条流水线：一边是文档处理，把原始文档拆成小块，转成向量存进向量数据库；另一边是问答处理，用户提问时，先从向量库里找回最相关的片段，再把这些片段拼进提示词，最后丢给大模型生成回答。

所以配置模型和知识库，本质上就是在给这条流水线定各种参数。模型配置决定的是"最后用哪个大脑来组织语言、生成回答"；知识库配置决定的是"检索阶段能不能找到真正有用的原文片段"。两者缺一不可，而且顺序很重要：先让模型能跑起来，再去填充知识库，最后联调的时候会省很多事。

我见过不少朋友把顺序搞反，先把一堆文档切块入库，折腾了半天向量数据，结果模型根本加载不出来，还得回头排查环境问题。我的建议是，无论代码骨架怎么写的，配置环节请严格遵循"模型先行、知识库跟上、联调收尾"的顺序。

1.2 需要打交道的三个配置对象

配置工作其实集中在三个对象上，搞清楚它们的职责，后面就顺畅了。

第一个是模型加载器。它负责把大模型文件加载起来，并提供统一的接口给上层程序调用。优秀的模型加载器能够自动管理显存、支持CPU和GPU切换、把模型封装成标准协议，上层程序完全不需要关心模型文件是怎么被推理的。它的配置项主要是模型路径、设备类型、上下文长度。

第二个是嵌入模型。它跟对话模型是两个完全不同的东西，负责把文本变成向量。你可能会问，为什么不能让对话模型直接做向量化？可以，但成本太高、响应太慢，而且两者是分开调优的。嵌入模型体积小、推理快，专门干这种"文本转向量"的活。配置项主要是模型路径和向量维度。

第三个是向量数据库。它负责存向量、算相似度、做检索。配置项主要是集合名、向量维度、距离算法、索引类型。这三个对象的关系非常像工厂里的三条产线：嵌入模型负责把原料标准化，向量库负责把标准件入库上架，对话模型负责从货架上挑零件组装成成品。

2. 模型配置：先让问答引擎转起来

2.1 模型选型看的是显存，不是参数越大越好

配置模型的第一件事不是写代码，而是选模型。很多新手上来就想跑最大的模型，结果把显卡跑爆。选模型的核心约束是硬件，尤其是显存大小。

我直接给个参考，方便你对照自己的机器做决定：

• 独立显卡显存小于8G，老老实实选7B参数级别的量化模型，也就是用GGUF格式压缩过的版本；
• 显存在8G到16G之间，可以试试14B级别的量化模型，前提是你还需要8G以上的系统内存做运行支撑；
• 显存16G以上，可以考虑14B级别以上的模型，或者让模型加载器做部分量化；
• 没有独立显卡，只有纯CPU和16G以上内存，也不是不能玩，选7B级别的小模型，用低位数量化，推理速度能到每秒几个字到十几个字，做知识库问答够用。

中文场景优先选中文语料微调过的模型，这类模型对中文表达的理解明显更到位，回答不容易出现英文混合或翻译腔。嵌入模型同理，中文场景不要选纯英文优化的模型。

2.2 拉取模型并启动推理服务的完整流程

模型加载器装好之后，拉取模型一般有两种方式：一是用命令行工具直接从模型仓库拉取，二是手动下载模型文件放到指定目录。命令行拉取最省事，它会自动处理格式转换和目录摆放。

假设你用的是某个本地推理框架，命令大概是这样的：

# 查看已安装的模型 runtime-cli list # 拉取一个7B级中文对话模型 runtime-cli pull your-chat-model:7b-q4 # 查看模型详细信息 runtime-cli show your-chat-model:7b-q4

这里有个操作习惯很重要：模型名字后面的标签一定要固定下来，不要随意用latest。量化版模型体积通常在三到五个G之间，如果拉取下来只有几百兆，大概率是标签不对或者仓库源不对。

拉取完成后，启动服务：

# 指定运行设备，GPU用cuda，纯CPU用cpu runtime-cli serve --host 127.0.0.1 --port 8000 --device cuda

服务起来之后，确认一下模型是否真正加载成功，可以看健康状态接口：

curl http://127.0.0.1:8000/health

返回正常再往下走。这里提醒一句，模型加载器和程序之间的接口地址不要用localhost，直接用127.0.0.1，避免因为系统hosts解析问题导致连不上。

2.3 对话参数按知识库场景来配

模型启动之后，还有一个很容易忽略的环节：对话参数配置。知识库问答跟闲聊不同，闲聊可以天马行空，知识库问答却要求忠实于上下文。参数配置不对，模型回答得越流畅，反而可能错得越离谱。

我整理了一套知识库场景的保守配置，直接用问题不大：

为什么知识库问答要压低温度？因为知识库问答是"查证"场景，不是"创作"场景。温度高了，模型对同一个问题回答会漂移，今天说A明天说B，这在业务场景里是完全不可接受的。我实测下来，temperature设到0.2左右，既能保证稳定，又不会因为太死板而显得像复读机。

还有个参数叫system prompt，它不属于数学模型参数，但效果远比那些数值参数重要。知识库问答建议写死一段系统提示词，核心内容就两句：第一，优先根据给定的知识库内容回答；第二，知识库中找不到依据时，明确说明不知道，不允许编造。这段提示词一定要有，否则模型很容易把检索片段当成背景材料，然后凭自己训练时的记忆自由发挥。

2.4 把模型接进问答程序

模型服务跑起来之后，程序怎么连过去？现在的本地推理框架普遍兼容标准的HTTP接口协议，上层代码写起来非常统一。Python里一般可以这样写：

import requests as http def chat_with_model(prompt, history=[], temperature=0.2): resp = http.post( "http://127.0.0.1:8000/v1/chat/completions", json={ "model": "your-chat-model:7b-q4", "messages": history + [{"role": "user", "content": prompt}], "temperature": temperature, "max_tokens": 1024 }, timeout=60 ) return resp.json()["choices"][0]["message"]["content"]

第一次对接成功，标准是要能正常拿到一句完整的中文回答。别小看这一步，很多配置问题都是在这里暴露的，比如端口不通、模型名不对、上下文长度不足。模型配置这块全部完工后，再做知识库配置。

3. 知识库配置：把文档变成可检索的向量

3.1 文档加载与清洗，别让垃圾进库

知识库配置的第一步，是把你手头的文档变成纯文本。支持格式一般至少包括txt、markdown和PDF，做得好的还可能支持Word和HTML。

这里最值得警惕的是PDF。PDF解析出来的文本经常带着乱七八糟的换行、页码、页眉页脚，如果直接切块入库，检索系统会把页面上的"第2页共15页"这种内容当作有效信息检索出来。所以我强烈建议，入库之前加一道清洗步骤，包括：

• 删除页码和页眉页脚，规则可以是正则匹配，也可以是固定位置截断；
• 合并错误的换行，PDF解析经常把同一个段落拆成多行；
• 过滤超短行，比如只有一个字、两个字的孤立行，多数是排版残留；
• 统一全角和半角符号，中文场景里这个细节影响还挺大。

清洗代码不复杂，但效果立竿见影。以PDF为例：

def extract_text_from_pdf(path): text = pdf_loader(path) # 按你选用的解析库处理 lines = [ln.strip() for ln in text.splitlines() if len(ln.strip()) > 1] body = "".join(lines) body = re.sub(r"第\s*\d+\s*页", "", body) return body

清洗完的文本质量，直接决定后续切块和检索的上限。源文本是脏的，参数再调也救不回来。

3.2 文本切块的粒度怎么定

文本切块是整个知识库配置里最考经验的一步，它直接影响检索精度。切得太粗，一个块太长，里面有用的信息被大量无关内容稀释，检索回来不够精准；切得太细，一个块只有一个短句，语义不完整，模型拿到手也不知道上下文是什么。

基本的切块策略是：按块大小切分，同时保留块与块之间的重叠。常见配置是块大小500字到800字，重叠50字到100字。这个量级既保证每个片段有完整语义，又保证段落边界处的内容不丢。

def split_document(text, chunk_size=600, overlap=80): from langchain_text_splitters import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter( chunk_size=chunk_size, chunk_overlap=overlap, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " ", ""] ) return splitter.split_text(text)

注意分隔符的顺序，这是递归切分器的精髓：优先按段落切，段落太长再按句子切，句子还太长才按词切。中文文本要特别把句号、问号、分号这些补齐，否则切出来的块会在莫名其妙的地方断开。

一个小技巧是先按章节标题切分，再对每个章节做块切分。这样能保住文档结构，比如一份使用手册，按"第一章、第二章"分开，再在每个章节内部切块，检索时同章节的内容更容易被同时命中。

3.3 嵌入模型与向量库参数对齐

文本块准备好了，下一步就是向量化入库。这里最重要的事情是：嵌入模型的向量维度和向量库的配置必须完全一致，否则写入数据时会直接报错。

嵌入模型一般会输出固定维度的向量，中文场景常用的开源嵌入模型大多是768维或1024维。你在创建向量库集合时，要把维度参数填成嵌入模型的实际输出维度。

# 初始化嵌入模型，这里以某开源中文嵌入模型为例 embedder = load_embedder("models/embed/your-chinese-embedder.bin") # 向量库集合配置：维度必须和嵌入模型输出一致 vector_store.create_collection( name="private_kb", dimension=768, metric="cosine" # 余弦相似度对文本检索最友好 ) # 文档入库：切块 -> 转向量 -> 写入 chunks = split_document(clean_text) vectors = [embedder.embed(chunk) for chunk in chunks] vector_store.insert( collection="private_kb", vectors=vectors, texts=chunks, metadata=[{"source": "user_manual.pdf", "page": 6}] * len(chunks) )

向量库的距离算法，文本检索场景优先用余弦相似度。原因简单说，余弦相似度只看方向不看长度，对"文档长短不一"这种情况更宽容。欧氏距离受文本长度影响较大，在两个块明明语义相近、但一个长一个短的时候，余弦能给更高分，欧氏可能误判。

3.4 检索参数决定答案质量

知识库配置最后一块是检索参数。最核心的是top_k和相似度阈值。

top_k表示每次问答从向量库召回多少个文本块。推荐设置在5到8个。设得太少，比如1到3个，可能漏掉关键信息；设得太多，比如20个，会给模型塞大量噪声，回答反而被不相关内容带偏。

相似度阈值表示"相似度低于多少就不算命中"。这个参数一定要设，否则用户问一个知识库完全没有的问题，系统也可能硬凑几个低分片段拼进提示词，模型就会一本正经地胡说八道。阈值一般从0.6到0.8之间试，建议先设0.7，如果发现该召回的内容被过滤掉了再往下降。

def search_knowledge(query, top_k=6, threshold=0.7): query_vec = embedder.embed(query) results = vector_store.search("private_kb", query_vec, top_k=top_k) return [r for r in results if r.score >= threshold]

如果检索结果不理想，先不要急着调阈值。先看返回的片段文本是不是完整、是不是真的相关。很多时候是切块切得太碎，或者源文档清洗不干净，而不是检索算法的问题。检索参数的调整要小步慢跑，一次只动一个变量。

4. 配置文件和首次联调

4.1 一份YAML把配置管起来

配置项这么多，散落在代码里迟早出问题。我的习惯是建一个config.yaml，把模型配置、知识库配置、检索参数、提示词全部集中管理。以后调参数只改文件，不动代码。

model: runtime_endpoint: "http://127.0.0.1:8000" name: "your-chat-model:7b-q4" temperature: 0.2 top_p: 0.85 max_tokens: 1024 context_length: 8192 embedder: model_path: "models/embed/your-chinese-embedder.bin" dimension: 768 vector_store: collection: "private_kb" metric: "cosine" top_k: 6 score_threshold: 0.7 knowledge_base: source_files: - "docs/user_manual.pdf" - "docs/faq.md" - "docs/README.txt" chunk_size: 600 chunk_overlap: 80 system_prompt: > 你是一个知识库问答助手。请严格根据用户提供的知识库内容回答问题。 如果知识库中没有相关内容，请直接说"知识库中暂未找到相关答案"， 不要自行编造。回答尽量简洁，并引用知识库中的关键依据。

加载这个配置可以用Python自带的标准库，也可以用更专业的配置库，看你的项目情况。关键是配置项的顺序要固定，模型在前，知识库在后，检索参数居中，逻辑上跟配置顺序一致，不容易漏。

4.2 首次入库的手动操作顺序

配置文件就位之后，首次入库建议不要一把梭全量跑，而是走一遍手工流程，每步都确认结果。我的推荐顺序是：

1. 先入库一个小文件，比如一份5页左右的文档；
2. 跑完打印三个统计信息：文本块数量、向量维度、入库耗时；
3. 到向量库里按关键词手动查一次，看能不能检索到对应片段；
4. 确认没问题后，再全量入库。

实际操作时，入库脚本大致是这个样子：

import yaml, glob from pathlib import Path cfg = yaml.safe_load(open("config.yaml")) for pattern in cfg["knowledge_base"]["source_files"]: for fpath in glob.glob(pattern): text = extract_and_clean(Path(fpath)) chunks = split_document( text, chunk_size=cfg["knowledge_base"]["chunk_size"], chunk_overlap=cfg["knowledge_base"]["chunk_overlap"], ) vectors = [embedder.embed(c) for c in chunks] vector_store.insert( collection=cfg["vector_store"]["collection"], vectors=vectors, texts=chunks, metadata=[{"source": str(fpath)}] * len(chunks), ) print(f"入库完成: {fpath} -> {len(chunks)} 个片段")

一个小文件入库，正常情况下几分钟内能完成。如果速度慢到离谱，先别急着加文档，很可能是嵌入模型被反复加载了，把模型加载放到循环外面，只加载一次，会快很多。

4.3 问答联调：观察三个关键表现

知识库入库之后，进入联调环节。打开问答界面，先问几个跟知识库内容强相关的问题，然后观察三个关键表现：

第一，回答是不是有依据。好的回答应该能明显看出源自某一段原文，最好还能点出"根据文档中提到的……"这种措辞。如果回答泛泛而谈，说明检索到的片段没有被真正利用。

第二，回答是不是稳定。同一个问题连续问三次，内容可以有措辞上的差别，但核心信息不能有冲突。出现冲突，多半是温度太高。

第三，回答不出来的问题，它是不是诚实。问一个知识库里完全没有的问题，比如问"本文档作者最喜欢的颜色是什么"，模型应该说"知识库中未找到相关答案"，而不是随机猜一个颜色。猜了，就是系统提示词没写到位或者阈值太低。

如果这三个表现全部正常，说明模型和知识库的配合已经通了。如果不正常，看下面一节。

4.4 效果不理想时的调整顺序

联调效果不理想，调整的时候要有顺序，不要三个参数一起动，否则出了问题根本不知道是哪个引起的。

我的调整顺序是：

• 回答乱编、缺乏依据，先看相似度阈值，把它升高，让低质量片段进不了提示词；
• 回答内容太泛、不够具体，先把top_k调小，聚焦到最相关的几个片段；
• 回答整体答非所问，先看检索回来的片段对不对，在向量库里手动把问题做一次相似度搜索，如果片段不对，问题出在切块或嵌入，而不是对话模型；
• 回答不稳定、前后矛盾，把temperature往下降；
• 回答语言风格不对，调整系统提示词，加一句"使用简洁、专业的中文回答"。

每次只改一个参数，然后重新跑同一个测试问题，记录回答变化。改完一轮没效果，就还原参数，换一个方向试。这套方法看着笨，但实际最高效。

5. 常见问题与排查记录

5.1 高频问题速查表

把实际踩过的坑整理成一张速查表，按问题、原因、解决思路三个维度看，效率最高：

这张表里有一项我特别想强调：入库报维度错误。这个问题看起来是配置错误，实际上是流程设计问题。一旦你换了嵌入模型，或者升级了版本，向量库里已有的旧向量和新向量维度不一致，就必须重建整个集合。不要想着只删一部分，直接drop掉重建最靠谱，省得留在里面引入脏数据。

5.2 实战中积累的几条操作习惯

最后分享几条我自己在实操里沉淀下来的习惯，算不上什么高深理论，但很管用。

第一，配置文件做好版本管理。哪怕只是改了一个temperature，也最好跟着代码一起提交。我遇到过很多次，明明昨天问答还好好的，今天怎么变了个味道，一查发现是配置被某次调试改了没还原。

第二，向量库的备份比模型文件更脆弱。模型文件丢了可以重新下载，向量库如果没备份，数据要全部重新切块、重新嵌入一遍，虽然能自动化，但成本不小。入库完成后，定期导出一次向量数据文件，能省很多事。

第三，小步验证永远比大步调试省时间。无论模型还是知识库的调整，都用同一个测试问题集，四五个问题就够，每次改完跑一遍。我自己的测试问题集里，一定包含一个知识库内的问题、一个知识库外的问题、一个模糊问题，这三个问题足够了。

配置模型和配置知识库，说到底是把系统里最"虚"的两个部分变成可量化、可调整的参数。模型决定上限，知识库决定下限，两者配置到位后，整个系统才算真的能交付使用。