1. 从一堆 PDF 到能问答的知识库中间缺了什么如果你在企业里做数据分析、市场研究或产品运营大概率经历过这种场景几百份行业报告、竞品 PDF、内部 Markdown 文档散落在网盘和 Wiki 里想找某个具体参数或结论只能靠关键词一页页翻。更麻烦的是采购了 OpenClaw 这类 AI 助手之后问它业务相关的问题它答不上来——因为它压根没见过你的私域数据。这个问题的本质不是模型不够聪明而是数据没有变成模型能检索的形态。把文档切块、用嵌入模型转成向量、写进向量数据库检索时用语义相似度召回这套链路才是企业私域知识库的最小可用闭环。LanceDB 作为本地向量库不需要额外部署服务文件即数据库适合从零跑通嵌入模型负责把文本变成高维向量是整条链路里唯一需要调用外部 API 的环节。我试过把嵌入调用散落在各个脚本里结果换模型、换 Key、调维度的时候到处改配置非常容易出错。后来统一走 TaoToken 的 API 通道管理嵌入调用一个 Key 覆盖多个嵌入模型配置集中在一处排障时也能快速定位是 Key 问题还是模型问题。这篇文章就按“采集数据 → 嵌入向量化 → 写入 LanceDB → 检索验证”的顺序把每一步的配置和脚本都摊开讲你跟着复制就能跑通一个最小可用的企业私域知识库。2. 前置准备TaoToken 统一 Key 与嵌入模型选型在写任何入库脚本之前先把嵌入调用的通道固定下来。TaoToken 在这里扮演的角色是统一的 API 入口你不需要为每个嵌入模型单独申请 Key、单独记 base_url而是用同一个 Key 走同一个 API 地址在请求体里指定模型名即可。官网地址是 https://taotoken.net/ API 端点是 https://taotoken.net/api 注意 API 地址后面不加任何查询参数。先到控制台创建 API Key入口在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 创建后复制保存。如果你还没决定用哪个嵌入模型可以先去模型对话页面看看当前支持的模型列表地址是 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 确认你要用的嵌入模型名称拼写。嵌入模型选型上企业知识库场景优先考虑三点维度、中文支持、成本。维度决定 LanceDB 表结构的向量字段长度一旦写入后想换模型就得重建整张表中文支持直接影响检索命中率纯英文模型在中文文档上召回会明显掉成本则和文档量成正比几百份 PDF 切块后可能是几万到几十万条向量调用量不小。常见的选择是 768 维或 1024 维的中文友好嵌入模型具体模型名以模型列表页为准。Key 拿到后建议用环境变量管理不要硬编码进脚本。Linux/macOS 下在~/.bashrc或~/.zshrc里加一行export TAOTOKEN_API_KEYsk-你的KeyWindows PowerShell 则用$env:TAOTOKEN_API_KEYsk-你的Key这样脚本里通过os.environ读取换 Key 时只改一处。接下来所有嵌入调用都走这个 Key 和https://taotoken.net/api这个端点。3. 可复制配置config.toml 与 settings.json 骨架配置分两块一块是嵌入调用的通道配置用config.toml管理一块是 LanceDB 的存储和分块参数用settings.json管理。分开的好处是换嵌入模型时只动 toml调分块策略时只动 json互不干扰。先看config.toml放在项目根目录[embedding] provider taotoken api_base https://taotoken.net/api api_key_env TAOTOKEN_API_KEY model 你的嵌入模型名 dimensions 768 batch_size 32 timeout 60 [lancedb] uri ./data/knowledge.lance table docs mode overwrite [chunking] max_chars 800 overlap_chars 120 min_chars 50这里几个参数值得说明。batch_size控制每次请求送多少条文本去嵌入太大容易触发超时太小则请求次数多、整体慢32 是个稳妥起点。dimensions必须和模型实际输出维度一致写错了 LanceDB 建表时不会报错但检索时相似度计算会出问题。mode overwrite表示每次全量重建表适合首次跑通后续增量更新可以改成append配合去重逻辑。再看settings.json管理文档采集和分块{ source_dir: ./raw_docs, file_types: [.pdf, .md, .txt, .docx], chunk: { max_chars: 800, overlap_chars: 120, min_chars: 50, split_by: paragraph }, metadata_fields: [source, file_name, chunk_index, created_at], lancedb: { uri: ./data/knowledge.lance, table: docs } }split_by设为paragraph表示优先按段落切段落超长再按max_chars硬切。overlap_chars是相邻块的重叠字符数防止一个完整语义被切断后两边都召回不到。metadata_fields里保留source和file_name检索命中后能直接告诉用户答案来自哪份文档这对企业场景很重要。两个配置文件的关系是settings.json决定“怎么切”config.toml决定“怎么嵌入和存”。脚本启动时同时读这两个文件任何一边改了都不用动代码。4. 向量写入脚本从文档到 LanceDB 表配置就绪后写一个入库脚本。整体流程是遍历source_dir下的文档 → 解析出纯文本 → 按settings.json的规则切块 → 批量调 TaoToken 嵌入接口 → 组装成 LanceDB 需要的记录格式 → 写入表。先装依赖pip install lancedb pyarrow requests pypdf python-docx下面是核心脚本ingest.py关键部分都加了注释import os import json import tomllib import requests import lancedb import pyarrow as pa from pathlib import Path from datetime import datetime # 读配置 with open(config.toml, rb) as f: cfg tomllib.load(f) with open(settings.json, r, encodingutf-8) as f: settings json.load(f) API_BASE cfg[embedding][api_base] API_KEY os.environ[cfg[embedding][api_key_env]] MODEL cfg[embedding][model] DIMS cfg[embedding][dimensions] BATCH cfg[embedding][batch_size] def extract_text(path: Path) - str: suffix path.suffix.lower() if suffix .pdf: from pypdf import PdfReader reader PdfReader(str(path)) return \n.join(page.extract_text() or for page in reader.pages) elif suffix .docx: from docx import Document doc Document(str(path)) return \n.join(p.text for p in doc.paragraphs) else: return path.read_text(encodingutf-8, errorsignore) def chunk_text(text: str, max_chars: int, overlap: int, min_chars: int): paragraphs [p.strip() for p in text.split(\n) if p.strip()] chunks, buf [], for para in paragraphs: if len(buf) len(para) max_chars: buf para \n else: if len(buf) min_chars: chunks.append(buf.strip()) buf buf[-overlap:] para \n if overlap else para \n if len(buf) min_chars: chunks.append(buf.strip()) return chunks def embed_batch(texts): resp requests.post( f{API_BASE}/embeddings, headers{Authorization: fBearer {API_KEY}}, json{model: MODEL, input: texts}, timeoutcfg[embedding][timeout], ) resp.raise_for_status() data resp.json()[data] return [item[embedding] for item in data] def main(): source_dir Path(settings[source_dir]) records [] for path in source_dir.rglob(*): if path.suffix.lower() not in settings[file_types]: continue text extract_text(path) chunks chunk_text( text, settings[chunk][max_chars], settings[chunk][overlap_chars], settings[chunk][min_chars], ) for idx, chunk in enumerate(chunks): records.append({ text: chunk, source: str(path), file_name: path.name, chunk_index: idx, created_at: datetime.now().isoformat(), }) print(f{path.name}: {len(chunks)} chunks) # 批量嵌入 for i in range(0, len(records), BATCH): batch records[i:i BATCH] vectors embed_batch([r[text] for r in batch]) for r, v in zip(batch, vectors): r[vector] v print(fembedded {i len(batch)}/{len(records)}) # 写入 LanceDB db lancedb.connect(cfg[lancedb][uri]) schema pa.schema([ pa.field(vector, pa.list_(pa.float32(), DIMS)), pa.field(text, pa.string()), pa.field(source, pa.string()), pa.field(file_name, pa.string()), pa.field(chunk_index, pa.int32()), pa.field(created_at, pa.string()), ]) table db.create_table(cfg[lancedb][table], datarecords, schemaschema, modecfg[lancedb][mode]) print(fwritten {len(records)} rows to {cfg[lancedb][table]}) if __name__ __main__: main()跑之前把要入库的 PDF、Markdown、Word 丢进./raw_docs然后执行python ingest.py正常输出会逐文件打印切块数再按批次打印嵌入进度最后一行是写入行数。如果卡在嵌入阶段先检查TAOTOKEN_API_KEY是否生效、模型名是否和模型列表页一致。写入完成后./data/knowledge.lance目录下会出现表文件这就是你的向量库。5. 检索命中验证确认知识库真的能用入库不等于能用必须做一次检索验证。写一个search.py把用户问题嵌入后去 LanceDB 做相似度搜索看返回的文本块是否真的相关import os, json, tomllib, requests, lancedb with open(config.toml, rb) as f: cfg tomllib.load(f) API_BASE cfg[embedding][api_base] API_KEY os.environ[cfg[embedding][api_key_env]] MODEL cfg[embedding][model] def embed_one(text): resp requests.post( f{API_BASE}/embeddings, headers{Authorization: fBearer {API_KEY}}, json{model: MODEL, input: [text]}, timeout60, ) resp.raise_for_status() return resp.json()[data][0][embedding] query 你们产品的核心参数是什么 vec embed_one(query) db lancedb.connect(cfg[lancedb][uri]) table db.open_table(cfg[lancedb][table]) results table.search(vec).limit(5).to_list() for i, r in enumerate(results): print(f--- 命中 {i1} | 来源: {r[file_name]} | 距离: {r.get(_distance, N/A):.4f}) print(r[text][:200]) print()执行python search.py观察返回结果。判断标准有三条第一命中的文本块内容是否和问题语义相关而不是只匹配到个别关键词第二来源文件名是否合理如果命中的全是无关文档说明分块或嵌入有问题第三距离值是否在合理范围通常越接近 0 越相似如果所有结果距离都很大可能是维度配置错了。如果检索效果不理想优先调chunk.max_chars。切得太碎会丢失上下文切得太大会让一个向量混入多个主题召回精度下降。800 字符是个经验起点中文文档可以适当降到 500 到 600。另一个调优点是overlap_chars适当增大重叠能缓解语义断裂但会增加总向量数和存储量。验证通过后这个最小知识库就可以接进 OpenClaw 或你自己的问答流程了。检索时把命中的文本块拼进 prompt模型就能基于私域数据回答而不是凭空编造。6. 本篇常见错排查嵌入请求返回 401 或 403Key 没读到或已失效。先在终端echo $TAOTOKEN_API_KEY确认环境变量有值再检查脚本里读的是不是同一个变量名。如果 Key 刚创建确认没有多余空格。LanceDB 建表报维度不匹配config.toml里的dimensions和模型实际输出维度不一致。最快的验证方式是单独调一次嵌入接口打印返回向量的长度和配置里的数字对一下。改完维度后必须删掉旧表重建因为向量字段长度是建表时固定的。检索结果全是无关文档先看分块是否合理把某个命中块的文本打印出来如果它本身就不完整或混了多个主题问题在切块策略。其次确认查询文本和入库文本用的是同一个嵌入模型换过模型但没重建表会导致向量空间不一致。写入速度慢或超时batch_size太大导致单次请求超时降到 16 或 8 试试。另外检查网络到https://taotoken.net/api的连通性如果公司网络有限制确认 API 端点可访问。PDF 解析出空文本部分扫描版 PDF 没有文字层pypdf提取为空。这类文档需要先做 OCR或者换用带 OCR 能力的解析库。入库前建议打印每个文件的字符数字符数异常低的直接跳过并记录避免写入大量空块污染检索结果。增量更新后旧数据还在mode设成了append新数据追加但旧数据没删。如果文档内容变了需要先按source字段删除旧记录再写入或者干脆用overwrite全量重建。全量重建在几万条向量以内耗时可接受逻辑最简单。7. 把链路固定下来后续扩展才有支点跑通这条链路之后你会发现真正需要长期维护的只有三样东西嵌入调用的 Key 和模型配置、分块策略、LanceDB 表结构。把这三样分别收进config.toml和settings.json后续无论是换嵌入模型、调分块参数还是把 LanceDB 换成别的向量库改动都局限在配置层脚本主体不用动。如果你打算把这套知识库接进长期运行的编码或 Agent 工作流建议了解一下 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 它更适合需要持续调用模型能力的场景。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里面有各语言 SDK 的调用示例需要换语言实现时可以直接参考。API Key 管理入口还是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 建议给知识库单独建一个 Key方便按项目统计用量和随时吊销。最后留一个实操建议第一次跑通后先拿 10 份文档做小规模验证确认检索命中质量满意再全量入库。全量跑之前把raw_docs里的文件按类型分好目录出问题时能快速定位是哪类文档的解析或切块出了偏差。知识库的质量取决于入库数据的质量这一步偷懒后面问答环节会加倍还回来。 知识库构建实战：用 TaoToken 统一 Key 把采集数据写入 LanceDB 向量库
1. 从一堆 PDF 到能问答的知识库中间缺了什么如果你在企业里做数据分析、市场研究或产品运营大概率经历过这种场景几百份行业报告、竞品 PDF、内部 Markdown 文档散落在网盘和 Wiki 里想找某个具体参数或结论只能靠关键词一页页翻。更麻烦的是采购了 OpenClaw 这类 AI 助手之后问它业务相关的问题它答不上来——因为它压根没见过你的私域数据。这个问题的本质不是模型不够聪明而是数据没有变成模型能检索的形态。把文档切块、用嵌入模型转成向量、写进向量数据库检索时用语义相似度召回这套链路才是企业私域知识库的最小可用闭环。LanceDB 作为本地向量库不需要额外部署服务文件即数据库适合从零跑通嵌入模型负责把文本变成高维向量是整条链路里唯一需要调用外部 API 的环节。我试过把嵌入调用散落在各个脚本里结果换模型、换 Key、调维度的时候到处改配置非常容易出错。后来统一走 TaoToken 的 API 通道管理嵌入调用一个 Key 覆盖多个嵌入模型配置集中在一处排障时也能快速定位是 Key 问题还是模型问题。这篇文章就按“采集数据 → 嵌入向量化 → 写入 LanceDB → 检索验证”的顺序把每一步的配置和脚本都摊开讲你跟着复制就能跑通一个最小可用的企业私域知识库。2. 前置准备TaoToken 统一 Key 与嵌入模型选型在写任何入库脚本之前先把嵌入调用的通道固定下来。TaoToken 在这里扮演的角色是统一的 API 入口你不需要为每个嵌入模型单独申请 Key、单独记 base_url而是用同一个 Key 走同一个 API 地址在请求体里指定模型名即可。官网地址是 https://taotoken.net/ API 端点是 https://taotoken.net/api 注意 API 地址后面不加任何查询参数。先到控制台创建 API Key入口在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 创建后复制保存。如果你还没决定用哪个嵌入模型可以先去模型对话页面看看当前支持的模型列表地址是 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 确认你要用的嵌入模型名称拼写。嵌入模型选型上企业知识库场景优先考虑三点维度、中文支持、成本。维度决定 LanceDB 表结构的向量字段长度一旦写入后想换模型就得重建整张表中文支持直接影响检索命中率纯英文模型在中文文档上召回会明显掉成本则和文档量成正比几百份 PDF 切块后可能是几万到几十万条向量调用量不小。常见的选择是 768 维或 1024 维的中文友好嵌入模型具体模型名以模型列表页为准。Key 拿到后建议用环境变量管理不要硬编码进脚本。Linux/macOS 下在~/.bashrc或~/.zshrc里加一行export TAOTOKEN_API_KEYsk-你的KeyWindows PowerShell 则用$env:TAOTOKEN_API_KEYsk-你的Key这样脚本里通过os.environ读取换 Key 时只改一处。接下来所有嵌入调用都走这个 Key 和https://taotoken.net/api这个端点。3. 可复制配置config.toml 与 settings.json 骨架配置分两块一块是嵌入调用的通道配置用config.toml管理一块是 LanceDB 的存储和分块参数用settings.json管理。分开的好处是换嵌入模型时只动 toml调分块策略时只动 json互不干扰。先看config.toml放在项目根目录[embedding] provider taotoken api_base https://taotoken.net/api api_key_env TAOTOKEN_API_KEY model 你的嵌入模型名 dimensions 768 batch_size 32 timeout 60 [lancedb] uri ./data/knowledge.lance table docs mode overwrite [chunking] max_chars 800 overlap_chars 120 min_chars 50这里几个参数值得说明。batch_size控制每次请求送多少条文本去嵌入太大容易触发超时太小则请求次数多、整体慢32 是个稳妥起点。dimensions必须和模型实际输出维度一致写错了 LanceDB 建表时不会报错但检索时相似度计算会出问题。mode overwrite表示每次全量重建表适合首次跑通后续增量更新可以改成append配合去重逻辑。再看settings.json管理文档采集和分块{ source_dir: ./raw_docs, file_types: [.pdf, .md, .txt, .docx], chunk: { max_chars: 800, overlap_chars: 120, min_chars: 50, split_by: paragraph }, metadata_fields: [source, file_name, chunk_index, created_at], lancedb: { uri: ./data/knowledge.lance, table: docs } }split_by设为paragraph表示优先按段落切段落超长再按max_chars硬切。overlap_chars是相邻块的重叠字符数防止一个完整语义被切断后两边都召回不到。metadata_fields里保留source和file_name检索命中后能直接告诉用户答案来自哪份文档这对企业场景很重要。两个配置文件的关系是settings.json决定“怎么切”config.toml决定“怎么嵌入和存”。脚本启动时同时读这两个文件任何一边改了都不用动代码。4. 向量写入脚本从文档到 LanceDB 表配置就绪后写一个入库脚本。整体流程是遍历source_dir下的文档 → 解析出纯文本 → 按settings.json的规则切块 → 批量调 TaoToken 嵌入接口 → 组装成 LanceDB 需要的记录格式 → 写入表。先装依赖pip install lancedb pyarrow requests pypdf python-docx下面是核心脚本ingest.py关键部分都加了注释import os import json import tomllib import requests import lancedb import pyarrow as pa from pathlib import Path from datetime import datetime # 读配置 with open(config.toml, rb) as f: cfg tomllib.load(f) with open(settings.json, r, encodingutf-8) as f: settings json.load(f) API_BASE cfg[embedding][api_base] API_KEY os.environ[cfg[embedding][api_key_env]] MODEL cfg[embedding][model] DIMS cfg[embedding][dimensions] BATCH cfg[embedding][batch_size] def extract_text(path: Path) - str: suffix path.suffix.lower() if suffix .pdf: from pypdf import PdfReader reader PdfReader(str(path)) return \n.join(page.extract_text() or for page in reader.pages) elif suffix .docx: from docx import Document doc Document(str(path)) return \n.join(p.text for p in doc.paragraphs) else: return path.read_text(encodingutf-8, errorsignore) def chunk_text(text: str, max_chars: int, overlap: int, min_chars: int): paragraphs [p.strip() for p in text.split(\n) if p.strip()] chunks, buf [], for para in paragraphs: if len(buf) len(para) max_chars: buf para \n else: if len(buf) min_chars: chunks.append(buf.strip()) buf buf[-overlap:] para \n if overlap else para \n if len(buf) min_chars: chunks.append(buf.strip()) return chunks def embed_batch(texts): resp requests.post( f{API_BASE}/embeddings, headers{Authorization: fBearer {API_KEY}}, json{model: MODEL, input: texts}, timeoutcfg[embedding][timeout], ) resp.raise_for_status() data resp.json()[data] return [item[embedding] for item in data] def main(): source_dir Path(settings[source_dir]) records [] for path in source_dir.rglob(*): if path.suffix.lower() not in settings[file_types]: continue text extract_text(path) chunks chunk_text( text, settings[chunk][max_chars], settings[chunk][overlap_chars], settings[chunk][min_chars], ) for idx, chunk in enumerate(chunks): records.append({ text: chunk, source: str(path), file_name: path.name, chunk_index: idx, created_at: datetime.now().isoformat(), }) print(f{path.name}: {len(chunks)} chunks) # 批量嵌入 for i in range(0, len(records), BATCH): batch records[i:i BATCH] vectors embed_batch([r[text] for r in batch]) for r, v in zip(batch, vectors): r[vector] v print(fembedded {i len(batch)}/{len(records)}) # 写入 LanceDB db lancedb.connect(cfg[lancedb][uri]) schema pa.schema([ pa.field(vector, pa.list_(pa.float32(), DIMS)), pa.field(text, pa.string()), pa.field(source, pa.string()), pa.field(file_name, pa.string()), pa.field(chunk_index, pa.int32()), pa.field(created_at, pa.string()), ]) table db.create_table(cfg[lancedb][table], datarecords, schemaschema, modecfg[lancedb][mode]) print(fwritten {len(records)} rows to {cfg[lancedb][table]}) if __name__ __main__: main()跑之前把要入库的 PDF、Markdown、Word 丢进./raw_docs然后执行python ingest.py正常输出会逐文件打印切块数再按批次打印嵌入进度最后一行是写入行数。如果卡在嵌入阶段先检查TAOTOKEN_API_KEY是否生效、模型名是否和模型列表页一致。写入完成后./data/knowledge.lance目录下会出现表文件这就是你的向量库。5. 检索命中验证确认知识库真的能用入库不等于能用必须做一次检索验证。写一个search.py把用户问题嵌入后去 LanceDB 做相似度搜索看返回的文本块是否真的相关import os, json, tomllib, requests, lancedb with open(config.toml, rb) as f: cfg tomllib.load(f) API_BASE cfg[embedding][api_base] API_KEY os.environ[cfg[embedding][api_key_env]] MODEL cfg[embedding][model] def embed_one(text): resp requests.post( f{API_BASE}/embeddings, headers{Authorization: fBearer {API_KEY}}, json{model: MODEL, input: [text]}, timeout60, ) resp.raise_for_status() return resp.json()[data][0][embedding] query 你们产品的核心参数是什么 vec embed_one(query) db lancedb.connect(cfg[lancedb][uri]) table db.open_table(cfg[lancedb][table]) results table.search(vec).limit(5).to_list() for i, r in enumerate(results): print(f--- 命中 {i1} | 来源: {r[file_name]} | 距离: {r.get(_distance, N/A):.4f}) print(r[text][:200]) print()执行python search.py观察返回结果。判断标准有三条第一命中的文本块内容是否和问题语义相关而不是只匹配到个别关键词第二来源文件名是否合理如果命中的全是无关文档说明分块或嵌入有问题第三距离值是否在合理范围通常越接近 0 越相似如果所有结果距离都很大可能是维度配置错了。如果检索效果不理想优先调chunk.max_chars。切得太碎会丢失上下文切得太大会让一个向量混入多个主题召回精度下降。800 字符是个经验起点中文文档可以适当降到 500 到 600。另一个调优点是overlap_chars适当增大重叠能缓解语义断裂但会增加总向量数和存储量。验证通过后这个最小知识库就可以接进 OpenClaw 或你自己的问答流程了。检索时把命中的文本块拼进 prompt模型就能基于私域数据回答而不是凭空编造。6. 本篇常见错排查嵌入请求返回 401 或 403Key 没读到或已失效。先在终端echo $TAOTOKEN_API_KEY确认环境变量有值再检查脚本里读的是不是同一个变量名。如果 Key 刚创建确认没有多余空格。LanceDB 建表报维度不匹配config.toml里的dimensions和模型实际输出维度不一致。最快的验证方式是单独调一次嵌入接口打印返回向量的长度和配置里的数字对一下。改完维度后必须删掉旧表重建因为向量字段长度是建表时固定的。检索结果全是无关文档先看分块是否合理把某个命中块的文本打印出来如果它本身就不完整或混了多个主题问题在切块策略。其次确认查询文本和入库文本用的是同一个嵌入模型换过模型但没重建表会导致向量空间不一致。写入速度慢或超时batch_size太大导致单次请求超时降到 16 或 8 试试。另外检查网络到https://taotoken.net/api的连通性如果公司网络有限制确认 API 端点可访问。PDF 解析出空文本部分扫描版 PDF 没有文字层pypdf提取为空。这类文档需要先做 OCR或者换用带 OCR 能力的解析库。入库前建议打印每个文件的字符数字符数异常低的直接跳过并记录避免写入大量空块污染检索结果。增量更新后旧数据还在mode设成了append新数据追加但旧数据没删。如果文档内容变了需要先按source字段删除旧记录再写入或者干脆用overwrite全量重建。全量重建在几万条向量以内耗时可接受逻辑最简单。7. 把链路固定下来后续扩展才有支点跑通这条链路之后你会发现真正需要长期维护的只有三样东西嵌入调用的 Key 和模型配置、分块策略、LanceDB 表结构。把这三样分别收进config.toml和settings.json后续无论是换嵌入模型、调分块参数还是把 LanceDB 换成别的向量库改动都局限在配置层脚本主体不用动。如果你打算把这套知识库接进长期运行的编码或 Agent 工作流建议了解一下 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 它更适合需要持续调用模型能力的场景。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里面有各语言 SDK 的调用示例需要换语言实现时可以直接参考。API Key 管理入口还是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 建议给知识库单独建一个 Key方便按项目统计用量和随时吊销。最后留一个实操建议第一次跑通后先拿 10 份文档做小规模验证确认检索命中质量满意再全量入库。全量跑之前把raw_docs里的文件按类型分好目录出问题时能快速定位是哪类文档的解析或切块出了偏差。知识库的质量取决于入库数据的质量这一步偷懒后面问答环节会加倍还回来。