把 LLM 连到你的业务数据上听起来是知识库问答项目里最关键的一步。实际做完几轮之后我的判断是这一步只解决了问题的 21% 左右剩下的大头在数据准备、检索质量、接口安全、批量处理和长期运维上。这篇文章把“接入数据”之后真正要做的环节拆开讲一遍适合正在做 RAG、知识库问答、LLM Agent 应用的读者。很多人一开始的思路很简单找一个 LLM 框架把文档加载进来丢进向量库然后用一个 Prompt 让模型基于检索结果回答。这个流程确实能跑通 Demo但离“能用”和“稳定用”还有不少距离。真正花时间的不是连接动作本身而是连接前后那些容易被忽略的细节。1. “21% 方案”到底指什么别把数据连接当成完整答案“Connecting an LLM to Your Data Is the 21% Solution”这个标题在我看来更像一个提醒把 LLM 接到数据上只是完整解决方案里的一小块。你可以把这一步叫做数据接入也可以叫向量化也可以统称为 RAG。但不管叫什么它都不等于一个可落地的知识库问答系统。1.1 为什么连接数据只是起点先想清楚一个问题LLM 本身训练时不会见过你的私有数据所以你需要把数据“喂”给它。常见做法不是把整个文档塞进上下文而是先把文档拆成片段、做向量化然后根据用户问题检索相关片段再把片段拼到 Prompt 里让模型生成答案。这个链路里“连接数据”解决的只是“模型能访问哪些数据”的问题。但用户真正关心的是“答案准不准、有没有依据、能不能在业务里用”。这两件事差得很远。举一个最常见的例子你把一份 PDF 合同加载进向量库用户问“违约金比例是多少”。如果 PDF 里的表格被解析成乱码或者切块时把一个条款从中间切断检索出来的片段可能根本不含关键数字。这时候模型再怎么聪明也只能猜甚至会说“文档里没有写”。问题不在模型而在连接数据之前的数据处理。所以 21% 这个数字我理解是在说接入数据可能只占整个工作量的一小部分剩下的是数据治理、检索优化、上下文组装、接口保护、批量任务、评估和监控。不要指望一句“把数据接进来”就能解决企业问答的所有问题。1.2 完整链路里真正耗时的几个环节不管用什么框架一条完整的 LLM 数据应用链路大致是这样的数据接入读文件、连数据库、抓网页、接 API。数据解析把 PDF、Word、Excel、HTML 转成可处理的文本。数据清洗去掉页眉页脚、乱码、重复内容、无关广告、水印。文本切块按长度、语义或文档结构切成适合检索的片段。向量化用 Embedding 模型把文本片段转成向量。索引存储把向量写入向量数据库或支持向量检索的存储。检索召回根据用户问题找到最相关的片段。上下文组装把片段排序、去重、裁剪拼进 Prompt。答案生成让 LLM 基于上下文生成回答。效果评估检查答案是否准确、有没有引用、有没有幻觉。你会发现真正花时间的往往是第 2 到第 6 步以及第 10 步。第 1 步“连接数据”只是开头。如果只盯着连接后面每一步都可能翻车。注意先别急着选框架。先把你的数据长什么样、用户会问什么问题、答案需要什么格式想清楚再决定用什么组件。2. 从一份本地文档跑通 LLM 数据问答很多人不喜欢理论那我们就从一份本地文档开始手动走一遍最小可用流程。目标不是写一个完整项目而是让你知道每一步在做什么以及怎么判断有没有做对。2.1 先确认数据形态和部署方式不同数据形态的处理方式完全不同。纯文本TXT、Markdown最好处理。半结构化PDF、Word、HTML需要解析。表格数据Excel、CSV可能不适合直接切块更适合按行或按表结构处理。数据库需要把表结构、字段说明一起提供给模型或者通过工具调用查询。网页需要抓取正文并清洗注意只处理你有权限或公开合规的数据。部署方式也很关键。如果调 SaaS LLM API重点是请求格式、超时限制和费用如果本地推理重点就变成了显存、内存和模型精度。本地推理时模型精度直接影响资源占用。现在常见的是 FP16、BF16、FP32。FP32 精度高但显存占用大FP16 和 BF16 在多数推理场景下效果差异不大但占用的显存明显更低。如果机器显存有限不要一上来就加载最大模型可以先尝试量化版本或小一点的模型把流程跑通再换更大的。2.2 最小流程加载、切块、向量化、检索、生成下面是一个通用示例用 Python 描述整个流程。不同框架的 API 不完全一样但思路是一致的。# 示例流程文档加载 - 切块 - 向量化 - 检索 - 生成 # 具体依赖和类名以你使用的版本为准 from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.embeddings import OpenAIEmbeddings from langchain_community.vectorstores import FAISS from langchain_openai import ChatOpenAI from langchain.chains import RetrievalQA # 1. 加载文档 loader TextLoader(knowledge_base/introduction.md) docs loader.load() # 2. 切块 splitter RecursiveCharacterTextSplitter( chunk_size500, chunk_overlap100 ) chunks splitter.split_documents(docs) # 3. 向量化并存入向量库 embeddings OpenAIEmbeddings() vectorstore FAISS.from_documents(chunks, embeddings) # 4. 创建检索问答链 retriever vectorstore.as_retriever(search_kwargs{k: 4}) llm ChatOpenAI(modelgpt-4o-mini, temperature0) qa RetrievalQA.from_chain_type( llmllm, retrieverretriever, return_source_documentsTrue ) # 5. 提问 answer qa.invoke(这份文档里介绍了哪些功能) print(answer[result])如果你是第一次跑不要直接复制到生产环境。先确认几个点文档路径是否正确有没有权限读取。切块大小是否适合你的文档语言和结构。Embedding API 是否配置了密钥或者本地模型是否已下载。向量库能不能写入磁盘输出目录是否有权限。2.3 单条样例的验证标准跑通不等于做对。一条样例至少要验证这些内容能启动不报错。输入问题后能在可接受时间内返回结果。答案和文档内容相关不是模型凭空编造。能追到引用来源最好能看到检索出的原始片段。对文档里不存在的信息模型愿意说“不知道”而不是硬答。我一般会先问一个“事实定位型”问题比如“文档里第几章提到某某配置”再问一个“总结型”问题。如果事实定位能答对说明检索链路是通的总结型问题能答好说明上下文组装和模型指令都还行。3. 数据连接中最容易翻车的四个环节流程跑通之后真正的问题才开始。下面这四个环节是我在多个项目里反复踩过的坑。3.1 文档解析PDF、表格、扫描件不是纯文本很多文档看着是文字实际上解析出来一堆乱码。尤其是 PDF里面可能是图片型扫描件也可能包含复杂表格直接pdfplumber或PyPDF2提取后顺序错乱、空格丢失、表格合并得一塌糊涂。遇到这种情况先不要急着调 Prompt。先把你解析出来的一小段文本打印出来看看原样是什么样子。如果原始文本就是乱的后面所有环节都会受影响。处理表格数据时一个常用思路是把表格转成 Markdown 格式再切块而不是把每行单独拆开。因为表格的列名和行数据放在一起模型才能理解每一列的含义。扫描件要先做 OCROCR 的质量直接决定后续回答质量。3.2 切块大小和重叠影响检索质量切块大小没有唯一标准但有一个判断原则小块更精准但容易丢失上下文大块上下文更完整但可能引入无关信息也更容易超过模型上下文长度。我常用的起点是块大小 500 到 800 个字符重叠 50 到 200 个字符。中文场景可以适当缩小因为中文信息密度高。切块时尽量按标题、段落、列表结构去切而不是硬按长度截断。如果用户问“某个功能怎么配置”结果答案总是缺后半段多半是切块把配置步骤切断了。这时候可以调整切分逻辑比如遇到“步骤一、步骤二”这样的列表时把整个列表作为一个块。3.3 向量检索召回后别立刻拼给模型检索返回的片段不一定都相关。默认 top_k 拉 5 个或 10 个片段里面可能有三四个是干扰项。把不相关内容拼进 Prompt模型容易被带偏。建议先做一层轻量处理去掉重复片段。按相关性分数排序。如果片段之间矛盾优先保留与问题最相关的。限制最终进入 Prompt 的字符数避免超出上下文窗口。有些场景还需要重排序。重排序模型会把检索出的候选片段重新打分效果比直接用向量相似度高不少但会增加一次调用开销。小项目可以先不做问答效果不稳定的时候再考虑。3.4 输出约束和引用来源很多 RAG 系统回答得挺流畅但用户根本不知道依据是什么。生产环境里这是不可接受的。可以给 Prompt 加两个约束如果上下文中没有相关信息明确回答“文档里没有找到”不要自己编。回答时标注引用来源比如[1]、[2]对应检索到的片段编号。实现方式很简单在 Prompt 里把检索片段按编号列出要求模型按编号引用。然后把return_source_documentsTrue的原始来源路径或页码一起返回。这样用户至少能自己去核对。4. 从单条问答到批量任务和 API 接口单条问答稳定之后下一步通常是批量处理一批问题或者把能力开放成 API 给其他系统调用。这时候最容易出现的问题是只看到单条成功没考虑并发、超时和失败重试。4.1 批量任务先定输入、输出和失败策略批量问答跟单条问答不是一回事。批量任务要关心输入从哪来是一个 CSV 文件、一个 JSON 数组还是一个目录里的多个文档。输出写到哪里文件命名规则、目录结构、是否追加还是覆盖。失败怎么办单条失败是跳过、重试还是终止。中途断了怎么续跑记录处理进度支持从上次失败的位置继续。建议第一次批量先跑 3 到 5 条确认输出格式和文件命名符合预期再跑完整批。不要一上来就全量跑万一 Prompt 写错或输出目录没建好跑完才发现问题就浪费了大量时间和 token。批量任务里还要注意输出文件命名。如果按问题 ID 命名要保证 ID 唯一如果按时间命名要保证同一批任务重复执行不会覆盖前面的结果。能把任务日志和输出文件放在一起排查时会方便很多。4.2 API 化时控制请求体、超时和并发把问答能力封装成 API 时第一个要处理的是请求体大小限制。很多接口对单次请求体有上限比如 1MB 或 10MB。如果用户把整篇文档直接塞进请求很容易触发413 Request Entity Too Large。解决方案不是简单调大服务端限制而是从调用方式上做限制限制单次请求文本长度超长内容先切块再发送。短视频场景不要一次传多个长文件。在接口层做参数校验拒绝明显超限的请求。把耗时操作改成异步任务避免 HTTP 连接长时间占用。并发数也要控制。不要一上来就并发 50。常见顺序是先单线程跑通再并发 5 验证稳定性然后逐步调到 20、50。并发越高对数据库、向量库和模型 API 的压力越大。报错时不一定是代码问题可能是对方限流或超时。4.3 Agent 和 MCP 扩展时收紧工具权限现在很多 LLM 应用不止做问答还会接工具调用比如查数据库、调内部 API、操作文件。这类能力通常叫 Agent也可以通过 MCP 这类协议连接外部工具。能调用工具是好事但一定要控制权限。给了模型过大的工具权限它可能执行你不希望的操作。最基本的防护原则是每个工具只暴露最小必要能力不做大而全的接口。对高危操作设置人工确认步骤比如删除、修改、转账、改权限。对工具入参做白名单校验不让模型自由传参。记录工具调用日志出现问题时能回溯。这不是为了限制能力而是为了避免“过度代理”的风险。模型生成的自然语言参数很容易不可控接口写的是“删除文件”模型可能因为 Prompt 注入或上下文误导真的去删文件。生产环境里建议默认不给模型任意执行权限。5. 从 Demo 走向生产的评估和运维视角Demo 能跑通和生产环境长期稳定运行完全不是一回事。如果你打算把这个能力做成正式服务下面几个视角必须补上。5.1 评估不能只看一两个样例很多人说“我试了几个问题效果挺好”但真正上线后才发现用户问题稍微一变回答质量就下降。原因很简单测试样例太少且样例往往是自己写的模型或检索模块对这些特定句式有偏好。建议整理一份小测试集至少覆盖这几类单轮事实问答答案直接对应文档中的具体内容。多轮追问第一问之后继续追问细节。需要多片段才能回答的问题答案分散在多个段落。无法回答的问题文档里根本没有涉及。边界问题问题很短、口语化、错别字多。每个问题记录这几个字段输入问题、检索到的片段、最终答案、是否有引用、是否正确。跑完一轮后统计一个“正确率”再针对错误样本去调整切块、检索和 Prompt。5.2 日志、版本和依赖管理生产环境里最怕“昨天还好好的今天突然不行了”。这种问题大概率不是模型突然变差而是某个依赖升级了或者向量库的索引状态变了。所以从第一版开始就要记录每次请求的输入、输出、耗时、token 消耗。检索命中了哪些片段相似度分数是多少。LLM 框架、Embedding 模型、向量库版本。批量任务的执行时间、成功数、失败数和失败原因。依赖安装时也常遇到问题。比如拉取仓库时出现error: rpc failed; curl 18 transfer closed with outstanding read data remaining多半是网络中断或仓库太大。可以先检查磁盘空间再尝试调整 git 配置的重试次数或者对大型仓库做浅克隆。这类问题不是代码错误不要反复改业务逻辑。5.3 成本和资源意识调用外部 LLM API 是按 token 计费的检索得到的片段越多、模型生成的文字越长成本越高。批量任务尤其明显。控制成本的基本思路只把必要的上下文拼进 Prompt不要盲目把 top_k 调到 10。对简单问题用更小、更便宜的模型。对重复问题做缓存命中缓存就不请求模型。长文档批量入库时关注 Embedding 调用量尽量一次多传几条文本。本地部署模型时注意力更多放在硬件上。FP16 和 BF16 的显存占用通常只有 FP32 的一半左右。如果你的机器配置不高可以先尝试小模型或量化版本先把服务跑起来再逐步升级。注意先跑通流程再考虑性能和成本。一上来就做分布式或异步队列大概率会在还没看到效果之前把自己绕晕。6. 排查清单和边界意识最后给一份排查顺序和边界判断遇到问题时不至于从 Prompt 开始乱调。6.1 排查顺序我自己的习惯是先看现象再看输入再看环境最后才看参数。具体来说如果直接报错先看错误信息在哪个环节产生。是加载、切块、向量化、检索还是生成每层都加打印定位到具体一层。如果输出为空先看输入文档是否被正确解析。打印原始文本前 200 个字符确认不是乱码。如果回答不准确先看检索结果。把检索到的片段打印出来看是否包含正确答案。如果检索不到问题在切块或向量化如果检索到了但答案仍不对问题在 Prompt 或上下文组装。如果接口超时或失败先看请求体大小和并发数。必要时重启服务或检查依赖版本。如果本地模型占用异常先看模型精度和上下文长度。不要盲目加大上下文。6.2 高频问题对照表下面这几类问题很常见建议直接作为排查清单。现象优先检查项常见原因文本向量 API 一直报未配置环境变量、密钥、模型名称配置项拼写错误或密钥缺失答案完全和文档无关检索结果、切块大小文档解析失败或检索到错误片段请求返回 413请求体大小、文本长度限制单次请求传了太大内容批量任务中途失败输出目录权限、文件命名冲突目录不存在或命名重复模型回答太快但质量差Prompt、检索 top_k上下文不够或模型被误导本地推理很慢模型精度、显存、上下文长度模型太大或上下文被塞满6.3 哪些能力不要过度期待连接 LLM 和数据能解决很多知识类问题但它不是万能的。数据本身质量差LLM 无法变出正确答案。比如合同扫描件模糊、表格结构混乱、信息已经过期再好的模型也救不回来。需要实时计算的场景比如“当前库存还有多少”不应该靠静态向量检索。这类问题更适合让 LLM 调用数据库查询接口而不是把整张表塞进上下文。需要精确权限控制的场景比如“这个用户能看哪些合同”也不能只靠 Prompt 约束。权限判断必须在数据访问层完成模型只能回答它已经拿到权限的数据。如果你发现自己花了很长时间在调 Prompt 上但问题一直没消失可能是选错了方案。比如应该走工具调用结果你硬要做成 RAG应该先清洗数据结果你一直在换模型。回到最前面那个 21% 的判断连接数据只是开始剩下 79% 的工作才是真正决定项目能不能落地的地方。