★ FEATURED ARTICLE 简介面向希望动手搭建中文知识库问答系统的开发者与学习者这份资源以chatglm3-6b对话模型为核心配合bge-large-zh向量模型覆盖从模型权重到推理脚本的完整落地素材适合具备一定Python与深度学习基础、想实践大模型问答应用的中级读者。压缩包共53个文件、约126KB以safetensors与bin两类权重分片为主体辅以json配置、py建模与分词脚本、sample示例及git版本元数据便于按目录快速定位模型加载、量化与配置环节。已有946人学习下载说明其在同类实践中具备一定参考价值。读者可据此理清双模型协同的工程结构掌握权重分片索引、配置项与推理代码的对应关系并借助示例文件快速验证环境为后续微调、融合策略与在线部署打下可复用的基础。1. 拿到 chatglm3-6b.zip 先别急着解压这套本地知识库问答到底能跑出什么效果上周有个做企业内训的朋友甩给我一个压缩包文件名就四个字加版本号说想给公司内部文档做个能问答的入口预算为零机器只有一张 24G 显存的卡。我解压跑了一遍结论是这套东西能落地但落地的前提是你得先搞清楚它到底由哪几块拼起来。chatglm3-6b.zip 里装的是 ChatGLM3-6B 的模型权重与配套推理代码配合 bge-large-zh 做向量化、LangChain 风格的检索链路做知识库问答是一条典型的「本地大模型 中文嵌入模型 RAG」组合。它解决的不是「让模型变聪明」而是「让模型只回答你文档里有的东西」。适合谁手里有中文私有文档、不想把数据传出去、又愿意花半天调通检索链路的从业者。不适合指望开箱即用做客服机器人的场景因为检索质量决定了八成效果模型只是最后一公里。2. 拆开压缩包看结构权重、分词器与推理入口怎么对上2.1 目录里到底有什么哪些能删哪些不能动解压后第一件事不是跑 demo而是把目录结构摸清楚。ChatGLM3-6B 这类权重包通常包含模型分片文件、配置文件、分词器文件和一份示例推理脚本。很多人翻车的起点就是「看着一堆 bin 文件不知道哪个是入口」然后随手改了个 config 里的参数模型直接加载失败。常见结构大致是这样不同打包方式文件名会有出入以实际为准文件/目录作用能不能动config.json模型结构参数层数、隐藏维度、注意力头数不要改改了权重对不上configuration_chatglm.py自定义配置类定义模型超参不要改modeling_chatglm.py模型前向逻辑含 RoPE、注意力实现谨慎改错直接 NaNtokenizer.model/tokenizer_config.json分词器中文切分依赖它不要换换了词表对不上pytorch_model-*.bin或.safetensors分片实际权重不要单独删某个分片MODEL_LICENSE/README许可与说明可读别删这里有个血泪经验分片权重必须整组保留少一个分片加载时报的错往往不是「文件缺失」而是「size mismatch」新手容易误以为是显存不够。实际是权重没拼齐。2.2 用一段最小脚本验证权重能不能加载在接知识库之前先单独验证模型本身能跑。这一步是后悔药能帮你把「模型问题」和「检索问题」彻底分开。下面这段是最小加载脚本跑通它再谈 RAG。from transformers import AutoTokenizer, AutoModel # 指向解压后的权重目录不要指向 zip model_path ./chatglm3-6b # trust_remote_code 必须开因为模型用了自定义 modeling 文件 tokenizer AutoTokenizer.from_pretrained( model_path, trust_remote_codeTrue ) # 半精度加载24G 卡上 6B 模型用 fp16 大约占 12~13G model AutoModel.from_pretrained( model_path, trust_remote_codeTrue, device_mapauto, # 自动分配到可用显卡 torch_dtypeauto # 有 fp16 就用 fp16 ).eval() # 一句最短的对话验证前向能走通 response, history model.chat( tokenizer, 用一句话说明什么是向量检索, history[] ) print(response)逻辑说明trust_remote_codeTrue是这类带自定义建模文件的权重包的必要开关不开会直接报找不到模型类。device_mapauto让 transformers 自己决定放哪张卡单卡场景等价于全放上去。torch_dtypeauto会读 config 里的精度声明通常落到 fp16。参数上唯一需要你手动调的是model_path其余保持默认即可。如果这一步报OutOfMemoryError先别怀疑模型坏了去看是不是用了 fp32 加载——6B 模型 fp32 要 24G 以上加上激活值很容易爆。把torch_dtype显式写成torch.float16再试。如果报size mismatch回去查分片是否完整。如果报KeyError之类多半是trust_remote_code没开或 modeling 文件被改动过。2.3 为什么选 bge-large-zh 而不是模型自带的嵌入知识库问答的检索环节需要一个嵌入模型把文档切块转成向量。ChatGLM3-6B 本身是生成模型不负责这件事。关键词里出现的 bge-large-zh 就是干这个的它是中文语义检索里比较稳的一档1024 维输出对中文长句的语义压缩比通用多语言模型更贴合。选它的理由很实际中文文档里同义改写多「报销流程」和「费用核销步骤」在字面上几乎不重叠靠关键词匹配会漏。bge-large-zh 在中文语义相似度任务上表现稳定且模型体积适中单卡能同时放下生成模型和嵌入模型。常见做法是把嵌入模型单独加载不要和生成模型挤在同一进程的同一张卡上做批处理否则显存峰值会打架。from sentence_transformers import SentenceTransformer # bge 系列建议加查询指令前缀检索召回会明显更稳 embedder SentenceTransformer(BAAI/bge-large-zh-v1.5, devicecuda:0) query 员工出差住宿标准是多少 # 查询侧加指令前缀文档侧不加这是 bge 的用法约定 query_vec embedder.encode( 为这个句子生成表示以用于检索相关文章 query, normalize_embeddingsTrue ) print(query_vec.shape) # 期望 (1024,)参数说明normalize_embeddingsTrue让向量归一化后续用余弦相似度时可以直接点积省一次除法。查询前缀是 bge 的约定用法文档入库时不加前缀这个不对称设计如果搞反了召回率会掉一截属于典型的玄学问题——看起来都能跑效果就是差。3. 把文档灌进知识库切块、向量化与检索链路搭起来3.1 文档切块的参数怎么定别用默认值糊弄RAG 效果差十次有七次死在切块上。切太大一个块里混了好几个主题检索命中后模型抓不住重点切太小一句话被拦腰截断语义残缺。中文文档的合格从业者常用做法是按字符数切带重叠重叠比例 10%~20%。from langchain.text_splitter import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size500, # 每块约 500 字符中文约 250~300 字 chunk_overlap80, # 相邻块重叠 80 字符防止语义断在边界 separators[\n\n, \n, 。, , , , , , ] ) docs splitter.split_text(open(handbook.txt, encodingutf-8).read()) print(len(docs), docs[0][:120])逻辑说明separators的顺序决定了优先在哪切。先按段落切段落太长再按句号切最后才落到逗号和空格。中文标点必须显式写进去默认分隔符是英文的直接用在中文文档上会把整段当一块。chunk_size500是个起点制度类文档可以到 600~800问答对密集的 FAQ 可以降到 300。chunk_overlap80保证跨块句子至少有一半落在两个块里检索时不会因为切在关键词中间而漏掉。这里有个容易忽略的点切块前要清洗。PDF 转出来的文本常带页眉页脚、乱码空格这些噪声会污染向量。我一般会先跑一遍正则去掉连续空白和孤立页码再切。3.2 向量入库与检索用 FAISS 做最小可跑链路向量库选型上本地单机场景 FAISS 足够不需要上重型向量数据库。它的索引文件就是一个本地文件拷走就能迁移适合内网部署。import faiss import numpy as np # 批量编码batch_size 按显存调24G 卡上 32 比较稳 doc_vecs embedder.encode( docs, batch_size32, normalize_embeddingsTrue, show_progress_barTrue ).astype(float32) # 内积索引配合归一化向量等价于余弦相似度 index faiss.IndexFlatIP(doc_vecs.shape[1]) index.add(doc_vecs) # 检索 top-kk 一般取 3~5 D, I index.search(query_vec.reshape(1, -1).astype(float32), k4) for score, idx in zip(D[0], I[0]): print(round(float(score), 4), docs[idx][:80])参数说明IndexFlatIP是精确内积检索数据量在十万块以内都够用超过再考虑IndexIVFFlat做近似。k4是召回条数太少容易漏太多会把无关块塞进上下文挤占生成模型的窗口。batch_size32是显存和速度的折中爆显存就降到 16。检索分数低于 0.5 的块建议直接丢弃硬塞给模型只会让它编。3.3 拼 prompt 让模型只答文档里的内容检索到块之后要把它们拼进 prompt。这一步的写法直接决定模型会不会「自由发挥」。核心是明确约束只依据给定资料回答资料里没有就说不知道。context \n\n.join([docs[i] for i in I[0] if D[0][list(I[0]).index(i)] 0.5]) prompt f你是一个严谨的文档问答助手。请只根据下面的资料回答问题。 如果资料中没有相关信息直接回答「资料中未提及」不要编造。 资料 {context} 问题{query} 回答 response, _ model.chat(tokenizer, prompt, history[]) print(response)逻辑说明context拼接时按检索分数过滤低分块不进上下文。prompt 里把「不要编造」写成硬约束比写「请尽量准确」有效得多。history[]表示单轮问答多轮场景要把历史传进去但要注意历史会占用上下文窗口长对话需要做截断。4. 避坑与排查这套链路最容易翻车的五个地方4.1 检索明明命中了模型却说「资料中未提及」现象手动打印检索结果明明有相关段落模型回答却是「未提及」。原因通常是拼进 prompt 的上下文被截断了——生成模型的上下文窗口有限检索块太多或太长时靠后的块被静默丢弃。解决控制k在 3~4单块不超过 600 字符拼之前统计总长度超了就砍块数而不是砍单块内容。4.2 中文文档切块后全是碎片现象检索出来的块都是半句话读起来莫名其妙。原因是用默认英文分隔符切中文或者chunk_size设得太小。解决显式配置中文标点分隔符chunk_size不低于 300chunk_overlap保持在 10%~20%。切完抽十条人工看一眼这个检查五分钟能省后面两小时调参。4.3 显存够却报 OOM现象24G 卡6B 模型 fp16 明明放得下跑起来还是爆。原因多半是嵌入模型和生成模型在同一张卡上同时做大批量编码峰值叠加。解决嵌入编码和生成推理分阶段执行编码完释放中间张量或者把batch_size降到 8~16。另一个隐蔽原因是device_mapauto把部分层放到了 CPU速度骤降还占内存显式指定device_map{: 0}更可控。4.4 换了台机器向量检索结果全乱现象索引文件拷过去同样的查询返回完全不同的结果。原因是嵌入模型版本或维度不一致或者查询侧忘了加 bge 的指令前缀。解决索引文件和嵌入模型绑定管理换模型必须重建索引查询前缀和文档编码的不对称用法写进代码注释别靠记忆。4.5 回答流畅但答非所问现象模型回答通顺但和问题对不上。原因是检索召回了语义相近但主题不同的块模型被带偏。解决提高相似度阈值到 0.55~0.6减少k同时在 prompt 里要求模型先复述问题再回答能逼它对齐。这个技巧在制度类文档上尤其管用。5. 进阶调优用重排和分块策略把召回率再抬一档跑通最小链路只是及格线。真正拉开效果差距的是检索后的重排。向量检索是粗筛召回 top-10 里往往混着语义相近但实际无关的块用一个轻量重排模型对候选块重新打分能把真正相关的顶上来。常见做法是接一个中文重排模型对 query 和每个候选块做交叉编码打分取前 3 进 prompt。from sentence_transformers import CrossEncoder # 重排模型比嵌入模型小单卡可共存 reranker CrossEncoder(BAAI/bge-reranker-base, devicecuda:0) # 先粗召回 10 条再重排取前 3 D, I index.search(query_vec.reshape(1, -1).astype(float32), k10) pairs [(query, docs[i]) for i in I[0]] scores reranker.predict(pairs) # 按重排分数排序取前 3 ranked sorted(zip(scores, I[0]), reverseTrue)[:3] context \n\n.join([docs[i] for _, i in ranked])参数说明粗召回k10给重排留足候选重排后取 3 条进上下文。CrossEncoder的predict返回相关性分数越高越相关。重排的代价是延迟增加单次查询多几十毫秒内网场景完全可接受。这一步在 FAQ 密集的文档上提升最明显因为粗筛容易被高频词带偏。另一个值得调的是分块策略。固定字符切块简单但粗糙制度类文档可以按「章节标题 段落」做层级切块检索时先定位章节再取段上下文更完整。我一般会先跑固定切块拿到基线再对比层级切块的效果用同一批测试问题各跑二十条人工看命中率别只看模型回答像不像——回答流畅不代表检索对。从那以后我每次拿到这类权重包都强制先跑一遍最小加载脚本、再抽十条切块人工过目这两步不做完绝不接知识库。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
