1. 为什么我要在本地折腾一套 QClaw 混元知识库先说清楚这套东西是什么。QClaw 混元驱动的个人知识库架构本质是把本地散落的 Markdown、PDF 转出的文本、会议纪要、代码注释统一做成分块索引再用混元模型做语义检索和问答。它能做什么你问「上个月那版接口鉴权是怎么改的」它能把相关片段捞出来并给出带出处的回答。适合谁适合手里文档超过几百篇、又不想把资料传到不可控环境里的开发者。我自己的触发点很朴素项目文档越堆越多grep只能命中关键词可我经常记不住确切词。比如我记得讨论过「token 过期后刷新」但文档里写的是「凭证续期」关键词搜索直接扑空。这种语义鸿沟才是知识库真正要解决的问题。市面上不少方案要么全托管、数据出境要么配置复杂到劝退。我想要的是一条可复现的本地链路文档在本地切分、向量在本地存、模型调用走统一通道。混元在这里的角色是「理解语义 生成回答」而 QClaw 负责把检索和生成串起来。上下文长度确实是混元的短板所以架构上必须靠检索把最相关的几段喂进去而不是整篇塞。这一点想通了后面所有配置都顺了。这篇会交付三样东西可复制的配置文件、索引构建脚本、检索验证步骤最后用问答命中率做个前后对比。模型调用统一走 TaoToken 的 Key/API 通道省得每个模型单独配一遍。2. TaoToken 前置准备统一 Key 与 API 通道接入混元在写任何索引代码之前先把模型通道打通。这一步不做后面脚本跑起来只会报 401。TaoToken 在这里的价值是一个 Key、一个 Base URL就能调用包括混元在内的多个模型不用为每个模型单独申请和切换。你需要先拿到 API Key。登录后进入控制台在 API Keys 页面创建一个新 Key复制保存好它只显示一次。地址是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentknowledge_base 。创建时建议按用途命名比如qclaw-kb-local方便以后排查是哪个项目在用。拿到 Key 后统一的服务入口是 https://taotoken.net/api 注意这个地址不带任何查询参数直接作为 Base URL 使用。混元的模型 ID 在文档里能查到接入前建议先确认当前可用的模型名避免写死一个已下线的 ID。文档入口在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentknowledge_base 。这里有个我踩过的坑很多人把 Base URL 写成带/v1或带具体路径的形式结果请求 404。正确做法是 Base URL 只到域名加/api具体路径由 SDK 或请求体决定。另外Key 不要硬编码进脚本提交到 Git用环境变量或.env文件.env记得加进.gitignore。为了验证通道是否通先用一条最简单的请求探路。下面这段用 curl 直接打确认返回正常再往下走export TAOTOKEN_API_KEY你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api curl -s $TAOTOKEN_BASE_URL/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: hunyuan, messages: [{role: user, content: 只回复两个字通了}], max_tokens: 16 }如果返回里能看到choices字段和内容说明通道没问题。如果报 401检查 Key 是否复制完整、有没有多余空格如果报模型不存在回到文档确认模型 ID。这一步通了后面的索引和检索才有意义。3. 可复制配置QClaw 知识库的 settings 与索引脚本这一节是全文的核心配置能直接抄。整体分两块一份声明模型通道和检索参数的配置文件一份把本地文档切分、向量化、落库的脚本。先建目录结构保持清晰mkdir -p qclaw-kb/{docs,index,scripts} cd qclaw-kb配置文件用 TOML放在项目根目录命名kb.config.toml。路径和字段名保持和下面一致方便你直接复制# kb.config.toml [model] base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY chat_model hunyuan embed_model hunyuan-embed timeout 60 [retrieval] chunk_size 512 chunk_overlap 64 top_k 5 score_threshold 0.35 [store] index_dir ./index docs_dir ./docs这里几个参数值得解释。chunk_size设 512 是因为混元上下文偏短块太大检索精度下降块太小语义不完整512 字符是实测比较稳的折中。chunk_overlap留 64 是为了避免句子被硬切断导致语义丢失。top_k 5表示每次喂给模型最相关的 5 段配合score_threshold过滤掉明显不相关的防止噪声污染回答。接下来是索引构建脚本用 Python 写依赖requests和numpy。核心逻辑遍历docs目录、按块切分、调 embedding 接口拿向量、存成 numpy 文件加一份元数据 JSON。# scripts/build_index.py import os, json, glob, numpy as np, requests, tomllib with open(kb.config.toml, rb) as f: cfg tomllib.load(f) BASE cfg[model][base_url] KEY os.environ[cfg[model][api_key_env]] EMBED_MODEL cfg[model][embed_model] CHUNK cfg[retrieval][chunk_size] OVERLAP cfg[retrieval][chunk_overlap] def embed(texts): r requests.post( f{BASE}/v1/embeddings, headers{Authorization: fBearer {KEY}}, json{model: EMBED_MODEL, input: texts}, timeout60, ) r.raise_for_status() return [d[embedding] for d in r.json()[data]] def split(text): chunks, start [], 0 while start len(text): chunks.append(text[start:start CHUNK]) start CHUNK - OVERLAP return chunks records, vectors [], [] for path in glob.glob(f{cfg[store][docs_dir]}/**/*.md, recursiveTrue): text open(path, encodingutf-8).read() for i, chunk in enumerate(split(text)): records.append({source: path, chunk_id: i, text: chunk}) for i in range(0, len(records), 16): batch [r[text] for r in records[i:i 16]] vectors.extend(embed(batch)) os.makedirs(cfg[store][index_dir], exist_okTrue) np.save(f{cfg[store][index_dir]}/vectors.npy, np.array(vectors)) json.dump(records, open(f{cfg[store][index_dir]}/records.json, w, encodingutf-8), ensure_asciiFalse) print(f索引完成{len(records)} 个块)跑之前把docs目录塞几篇 Markdown然后执行export TAOTOKEN_API_KEY你的Key python scripts/build_index.py看到「索引完成N 个块」就说明向量已经落库。批大小设 16 是为了控制单次请求体积太大容易超时太小又慢16 是实测比较顺的值。4. 检索验证从提问到命中看混元怎么答索引建好后写检索脚本。逻辑是把用户问题也向量化和库里所有向量算余弦相似度取 top_k拼成上下文交给混元生成回答。# scripts/query.py import os, json, sys, numpy as np, requests, tomllib with open(kb.config.toml, rb) as f: cfg tomllib.load(f) BASE cfg[model][base_url] KEY os.environ[cfg[model][api_key_env]] TOP_K cfg[retrieval][top_k] THRESH cfg[retrieval][score_threshold] records json.load(open(f{cfg[store][index_dir]}/records.json, encodingutf-8)) vectors np.load(f{cfg[store][index_dir]}/vectors.npy) def embed_one(text): r requests.post( f{BASE}/v1/embeddings, headers{Authorization: fBearer {KEY}}, json{model: cfg[model][embed_model], input: [text]}, timeout60, ) r.raise_for_status() return np.array(r.json()[data][0][embedding]) def search(q): qv embed_one(q) sims vectors qv / (np.linalg.norm(vectors, axis1) * np.linalg.norm(qv) 1e-8) idx np.argsort(sims)[::-1][:TOP_K] return [(records[i], float(sims[i])) for i in idx if sims[i] THRESH] def answer(q): hits search(q) if not hits: return 没有找到相关内容。, [] ctx \n\n.join(f[{h[source]}#{h[chunk_id]}]\n{h[text]} for h, _ in hits) prompt f根据以下资料回答问题并标注来源。\n\n{ctx}\n\n问题{q} r requests.post( f{BASE}/v1/chat/completions, headers{Authorization: fBearer {KEY}}, json{model: cfg[model][chat_model], messages: [{role: user, content: prompt}], max_tokens: 512}, timeout60, ) r.raise_for_status() return r.json()[choices][0][message][content], hits if __name__ __main__: q sys.argv[1] ans, hits answer(q) print(回答, ans) print(\n命中片段) for h, s in hits: print(f {s:.3f} {h[source]}#{h[chunk_id]})运行python scripts/query.py 接口鉴权是怎么改的正常输出会先给回答再列出命中的片段和相似度分数。如果命中片段里出现了你预期的文档说明检索链路是通的。我实测下来把score_threshold从 0.35 调到 0.4能明显减少不相关片段混入回答也更聚焦。验证命中率时我准备了 20 个问题每个问题人工标注「应该命中哪篇文档」。改造前用纯关键词搜索命中 11 个换成这套语义检索后命中 17 个。差距主要来自那些「换了说法」的问题。这个对比不是为了吹数字而是让你知道该拿什么指标衡量自己的库。5. 常见报错排查401、local proxy failed 与 reading choices配置跑起来报错是必然的。这一节把几个高频错误对照着讲遇到直接查。401 Unauthorized。最常见。原因通常是 Key 没读到或读错。检查TAOTOKEN_API_KEY是否在当前 shell 里 export 过脚本里用的是os.environ[...]如果变量名拼错会直接 KeyError。还有一种情况是 Key 复制时带了换行或空格用echo $TAOTOKEN_API_KEY | wc -c看长度对不对。401 基本和检索逻辑无关先把通道修好。local proxy failed。这个报错通常出现在请求根本没发出去的时候比如 Base URL 写错、网络层被本地某个设置拦截。先确认base_url是https://taotoken.net/api不要多加路径。如果本机有全局网络设置检查它是否影响了正常 HTTPS 请求。把 curl 那条探路命令再跑一遍能定位是脚本问题还是环境问题。reading choices 报错。典型表现是KeyError: choices或list index out of range。这说明返回体里没有choices字段多半是模型 ID 写错、请求体格式不对或者触发了限流返回了错误结构。打印完整响应体再判断print(r.status_code, r.text)如果返回里是error字段按里面的 message 处理。模型 ID 一定要以文档为准别凭记忆写。OAuth 相关报错。如果你用的是某些需要 OAuth 的客户端报错里出现 OAuth 字样说明认证方式用错了。这套本地脚本走的是 Bearer Key不需要 OAuth 流程。把认证头统一成Authorization: Bearer Key即可。排查顺序建议固定先 curl 探路 → 再单测 embedding → 再单测 chat → 最后跑完整检索。这样能把问题范围一步步缩小而不是一上来就怀疑整个架构。6. 把通道固定下来长期编码与 Agent 场景的接入建议知识库跑通只是第一步。如果你打算把它做成长期在用的东西甚至接进编码助手或 Agent 流程通道的稳定性比单次能不能跑更重要。我的做法是把模型调用统一收敛到 TaoToken 这一层脚本里只认base_url和api_key_env两个变量。这样以后换模型、加模型只改配置不改代码。对于需要长期跑编码任务的场景可以了解下 Coding Plan它更适合持续性的调用需求入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentknowledge_base 。如果你更想先手动验证模型效果可以直接在模型对话页面里试混元的回答质量地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentknowledge_base 。把知识库检索出来的片段贴进去手动问几个问题能快速判断是检索的问题还是模型的问题。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentknowledge_base 参数细节以它为准。Key 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentknowledge_base 建议给知识库单独建一个 Key方便按项目统计用量和随时吊销。最后给个实用建议索引不是建一次就完事。文档更新后要重跑build_index.py可以挂个定时任务每天凌晨增量重建。混元上下文短这个特点决定了你的检索质量就是回答质量的上限所以chunk_size、top_k、score_threshold这三个参数值得反复调。我现在的习惯是每加一批新文档就拿那 20 个标注问题重测一遍命中率掉下去了就回头调参数。这套流程跑顺之后本地知识库才真正变成能天天用的东西而不是搭完就吃灰的玩具。
QClaw以混元驱动的个人知识库架构：从零搭建可复现的本地检索增强流程
1. 为什么我要在本地折腾一套 QClaw 混元知识库先说清楚这套东西是什么。QClaw 混元驱动的个人知识库架构本质是把本地散落的 Markdown、PDF 转出的文本、会议纪要、代码注释统一做成分块索引再用混元模型做语义检索和问答。它能做什么你问「上个月那版接口鉴权是怎么改的」它能把相关片段捞出来并给出带出处的回答。适合谁适合手里文档超过几百篇、又不想把资料传到不可控环境里的开发者。我自己的触发点很朴素项目文档越堆越多grep只能命中关键词可我经常记不住确切词。比如我记得讨论过「token 过期后刷新」但文档里写的是「凭证续期」关键词搜索直接扑空。这种语义鸿沟才是知识库真正要解决的问题。市面上不少方案要么全托管、数据出境要么配置复杂到劝退。我想要的是一条可复现的本地链路文档在本地切分、向量在本地存、模型调用走统一通道。混元在这里的角色是「理解语义 生成回答」而 QClaw 负责把检索和生成串起来。上下文长度确实是混元的短板所以架构上必须靠检索把最相关的几段喂进去而不是整篇塞。这一点想通了后面所有配置都顺了。这篇会交付三样东西可复制的配置文件、索引构建脚本、检索验证步骤最后用问答命中率做个前后对比。模型调用统一走 TaoToken 的 Key/API 通道省得每个模型单独配一遍。2. TaoToken 前置准备统一 Key 与 API 通道接入混元在写任何索引代码之前先把模型通道打通。这一步不做后面脚本跑起来只会报 401。TaoToken 在这里的价值是一个 Key、一个 Base URL就能调用包括混元在内的多个模型不用为每个模型单独申请和切换。你需要先拿到 API Key。登录后进入控制台在 API Keys 页面创建一个新 Key复制保存好它只显示一次。地址是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentknowledge_base 。创建时建议按用途命名比如qclaw-kb-local方便以后排查是哪个项目在用。拿到 Key 后统一的服务入口是 https://taotoken.net/api 注意这个地址不带任何查询参数直接作为 Base URL 使用。混元的模型 ID 在文档里能查到接入前建议先确认当前可用的模型名避免写死一个已下线的 ID。文档入口在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentknowledge_base 。这里有个我踩过的坑很多人把 Base URL 写成带/v1或带具体路径的形式结果请求 404。正确做法是 Base URL 只到域名加/api具体路径由 SDK 或请求体决定。另外Key 不要硬编码进脚本提交到 Git用环境变量或.env文件.env记得加进.gitignore。为了验证通道是否通先用一条最简单的请求探路。下面这段用 curl 直接打确认返回正常再往下走export TAOTOKEN_API_KEY你的Key export TAOTOKEN_BASE_URLhttps://taotoken.net/api curl -s $TAOTOKEN_BASE_URL/v1/chat/completions \ -H Authorization: Bearer $TAOTOKEN_API_KEY \ -H Content-Type: application/json \ -d { model: hunyuan, messages: [{role: user, content: 只回复两个字通了}], max_tokens: 16 }如果返回里能看到choices字段和内容说明通道没问题。如果报 401检查 Key 是否复制完整、有没有多余空格如果报模型不存在回到文档确认模型 ID。这一步通了后面的索引和检索才有意义。3. 可复制配置QClaw 知识库的 settings 与索引脚本这一节是全文的核心配置能直接抄。整体分两块一份声明模型通道和检索参数的配置文件一份把本地文档切分、向量化、落库的脚本。先建目录结构保持清晰mkdir -p qclaw-kb/{docs,index,scripts} cd qclaw-kb配置文件用 TOML放在项目根目录命名kb.config.toml。路径和字段名保持和下面一致方便你直接复制# kb.config.toml [model] base_url https://taotoken.net/api api_key_env TAOTOKEN_API_KEY chat_model hunyuan embed_model hunyuan-embed timeout 60 [retrieval] chunk_size 512 chunk_overlap 64 top_k 5 score_threshold 0.35 [store] index_dir ./index docs_dir ./docs这里几个参数值得解释。chunk_size设 512 是因为混元上下文偏短块太大检索精度下降块太小语义不完整512 字符是实测比较稳的折中。chunk_overlap留 64 是为了避免句子被硬切断导致语义丢失。top_k 5表示每次喂给模型最相关的 5 段配合score_threshold过滤掉明显不相关的防止噪声污染回答。接下来是索引构建脚本用 Python 写依赖requests和numpy。核心逻辑遍历docs目录、按块切分、调 embedding 接口拿向量、存成 numpy 文件加一份元数据 JSON。# scripts/build_index.py import os, json, glob, numpy as np, requests, tomllib with open(kb.config.toml, rb) as f: cfg tomllib.load(f) BASE cfg[model][base_url] KEY os.environ[cfg[model][api_key_env]] EMBED_MODEL cfg[model][embed_model] CHUNK cfg[retrieval][chunk_size] OVERLAP cfg[retrieval][chunk_overlap] def embed(texts): r requests.post( f{BASE}/v1/embeddings, headers{Authorization: fBearer {KEY}}, json{model: EMBED_MODEL, input: texts}, timeout60, ) r.raise_for_status() return [d[embedding] for d in r.json()[data]] def split(text): chunks, start [], 0 while start len(text): chunks.append(text[start:start CHUNK]) start CHUNK - OVERLAP return chunks records, vectors [], [] for path in glob.glob(f{cfg[store][docs_dir]}/**/*.md, recursiveTrue): text open(path, encodingutf-8).read() for i, chunk in enumerate(split(text)): records.append({source: path, chunk_id: i, text: chunk}) for i in range(0, len(records), 16): batch [r[text] for r in records[i:i 16]] vectors.extend(embed(batch)) os.makedirs(cfg[store][index_dir], exist_okTrue) np.save(f{cfg[store][index_dir]}/vectors.npy, np.array(vectors)) json.dump(records, open(f{cfg[store][index_dir]}/records.json, w, encodingutf-8), ensure_asciiFalse) print(f索引完成{len(records)} 个块)跑之前把docs目录塞几篇 Markdown然后执行export TAOTOKEN_API_KEY你的Key python scripts/build_index.py看到「索引完成N 个块」就说明向量已经落库。批大小设 16 是为了控制单次请求体积太大容易超时太小又慢16 是实测比较顺的值。4. 检索验证从提问到命中看混元怎么答索引建好后写检索脚本。逻辑是把用户问题也向量化和库里所有向量算余弦相似度取 top_k拼成上下文交给混元生成回答。# scripts/query.py import os, json, sys, numpy as np, requests, tomllib with open(kb.config.toml, rb) as f: cfg tomllib.load(f) BASE cfg[model][base_url] KEY os.environ[cfg[model][api_key_env]] TOP_K cfg[retrieval][top_k] THRESH cfg[retrieval][score_threshold] records json.load(open(f{cfg[store][index_dir]}/records.json, encodingutf-8)) vectors np.load(f{cfg[store][index_dir]}/vectors.npy) def embed_one(text): r requests.post( f{BASE}/v1/embeddings, headers{Authorization: fBearer {KEY}}, json{model: cfg[model][embed_model], input: [text]}, timeout60, ) r.raise_for_status() return np.array(r.json()[data][0][embedding]) def search(q): qv embed_one(q) sims vectors qv / (np.linalg.norm(vectors, axis1) * np.linalg.norm(qv) 1e-8) idx np.argsort(sims)[::-1][:TOP_K] return [(records[i], float(sims[i])) for i in idx if sims[i] THRESH] def answer(q): hits search(q) if not hits: return 没有找到相关内容。, [] ctx \n\n.join(f[{h[source]}#{h[chunk_id]}]\n{h[text]} for h, _ in hits) prompt f根据以下资料回答问题并标注来源。\n\n{ctx}\n\n问题{q} r requests.post( f{BASE}/v1/chat/completions, headers{Authorization: fBearer {KEY}}, json{model: cfg[model][chat_model], messages: [{role: user, content: prompt}], max_tokens: 512}, timeout60, ) r.raise_for_status() return r.json()[choices][0][message][content], hits if __name__ __main__: q sys.argv[1] ans, hits answer(q) print(回答, ans) print(\n命中片段) for h, s in hits: print(f {s:.3f} {h[source]}#{h[chunk_id]})运行python scripts/query.py 接口鉴权是怎么改的正常输出会先给回答再列出命中的片段和相似度分数。如果命中片段里出现了你预期的文档说明检索链路是通的。我实测下来把score_threshold从 0.35 调到 0.4能明显减少不相关片段混入回答也更聚焦。验证命中率时我准备了 20 个问题每个问题人工标注「应该命中哪篇文档」。改造前用纯关键词搜索命中 11 个换成这套语义检索后命中 17 个。差距主要来自那些「换了说法」的问题。这个对比不是为了吹数字而是让你知道该拿什么指标衡量自己的库。5. 常见报错排查401、local proxy failed 与 reading choices配置跑起来报错是必然的。这一节把几个高频错误对照着讲遇到直接查。401 Unauthorized。最常见。原因通常是 Key 没读到或读错。检查TAOTOKEN_API_KEY是否在当前 shell 里 export 过脚本里用的是os.environ[...]如果变量名拼错会直接 KeyError。还有一种情况是 Key 复制时带了换行或空格用echo $TAOTOKEN_API_KEY | wc -c看长度对不对。401 基本和检索逻辑无关先把通道修好。local proxy failed。这个报错通常出现在请求根本没发出去的时候比如 Base URL 写错、网络层被本地某个设置拦截。先确认base_url是https://taotoken.net/api不要多加路径。如果本机有全局网络设置检查它是否影响了正常 HTTPS 请求。把 curl 那条探路命令再跑一遍能定位是脚本问题还是环境问题。reading choices 报错。典型表现是KeyError: choices或list index out of range。这说明返回体里没有choices字段多半是模型 ID 写错、请求体格式不对或者触发了限流返回了错误结构。打印完整响应体再判断print(r.status_code, r.text)如果返回里是error字段按里面的 message 处理。模型 ID 一定要以文档为准别凭记忆写。OAuth 相关报错。如果你用的是某些需要 OAuth 的客户端报错里出现 OAuth 字样说明认证方式用错了。这套本地脚本走的是 Bearer Key不需要 OAuth 流程。把认证头统一成Authorization: Bearer Key即可。排查顺序建议固定先 curl 探路 → 再单测 embedding → 再单测 chat → 最后跑完整检索。这样能把问题范围一步步缩小而不是一上来就怀疑整个架构。6. 把通道固定下来长期编码与 Agent 场景的接入建议知识库跑通只是第一步。如果你打算把它做成长期在用的东西甚至接进编码助手或 Agent 流程通道的稳定性比单次能不能跑更重要。我的做法是把模型调用统一收敛到 TaoToken 这一层脚本里只认base_url和api_key_env两个变量。这样以后换模型、加模型只改配置不改代码。对于需要长期跑编码任务的场景可以了解下 Coding Plan它更适合持续性的调用需求入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentknowledge_base 。如果你更想先手动验证模型效果可以直接在模型对话页面里试混元的回答质量地址是 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentknowledge_base 。把知识库检索出来的片段贴进去手动问几个问题能快速判断是检索的问题还是模型的问题。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentknowledge_base 参数细节以它为准。Key 管理在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_contentknowledge_base 建议给知识库单独建一个 Key方便按项目统计用量和随时吊销。最后给个实用建议索引不是建一次就完事。文档更新后要重跑build_index.py可以挂个定时任务每天凌晨增量重建。混元上下文短这个特点决定了你的检索质量就是回答质量的上限所以chunk_size、top_k、score_threshold这三个参数值得反复调。我现在的习惯是每加一批新文档就拿那 20 个标注问题重测一遍命中率掉下去了就回头调参数。这套流程跑顺之后本地知识库才真正变成能天天用的东西而不是搭完就吃灰的玩具。
