大模型Context-Mode实战：构建可溯源的知识库问答系统

1. 先说清楚：Context-Mode到底是个什么东西

你要是最近在折腾大模型应用，八成见过"context-mode"这个说法。我第一次看到这个词是在一个RAG项目的技术评审里，当时团队里有人把"把检索结果拼到Prompt里再问模型"这个操作叫成了"开Context Mode"，其他人还一本正经地讨论要不要默认开启。后来我发现，这其实不是一个官方术语，而是大家在工程实践里约定俗成的一个叫法：让模型在"带着上下文"的状态下回答问题。换句话说，你不再让大模型凭记忆和参数里的知识硬答，而是先把相关资料、历史记录、规则说明一股脑塞进输入，再让它基于这些材料做分析和生成。

很多刚接触大模型开发的人会问：这有什么好单独拎出来讲的？直接把文档丢进去不就行了？恰恰是这种想法，让不少项目在"看起来能用"和"真正好用"之间反复横跳。上下文模式看起来简单，可一旦涉及Token预算、切片粒度、检索质量、拼接顺序这些细节，好不好用就完全是两码事了。这篇东西我想用我实际做过的项目来拆一遍，把"为什么需要它""怎么落地它""哪些坑我替你踩过了"讲清楚。

这个模式最适合谁？正在做知识库问答、客服助手、文档分析类应用的技术同学，尤其是那些已经发现"裸问大模型，它老一本正经胡说八道"的人。纯新手也不用慌，我会把前置概念一并解释，你跟着实操章节走一遍，就能搭出一个能用的上下文问答服务。

2. 整体设计与思路拆解：为什么我们最终选了Context-Mode，而不是"让模型自己记"

2.1 先回答一个问题：能不能不塞上下文，直接微调模型？

在动手之前，我们团队其实先吵了一轮架构选型。当时客户的需求很明确：给内部几百份产品文档做一个问答入口，要求回答必须能溯源到文档原文。摆在我们面前的有两条路：一条是微调模型，把文档知识"训练进参数";另一条就是本文主角Context-Mode。

微调看着很诱人，问题是它有几个硬伤。第一，数据更新太慢。客户文档每周都在变，微调一次少说几小时，多则几天，再加上数据清洗、验证集评估，根本跟不上业务节奏。第二，成本不透明。微调按GPU小时计费，几百份文档起步就是几千块，后面每更新一次都是成本。第三，也是最致命的，模型微调之后依然会"编造"。参数化知识没有源头，它把文档内容"记住"了，但你没办法逐句追踪答案到底是哪来的。

Context-Mode的思路刚好相反。它不试图让模型"记住"知识，而是把知识放在输入侧，让模型当一个"带着参考资料答题的助手"。你可以把大模型想象成一个特别聪明但容易道听途说的实习生，微调等于送他去脱产培训，Context-Mode等于在他答题时把相关参考资料直接翻到那一页放到桌上。哪个方案更适合动态更新、需要溯源的场景，答案很明显。

2.2 Context-Mode的本质：它不是一种算法，而是一种交互范式

别被"Mode"这个词误导，以为又是什么新模型架构。Context-Mode本质上只是一套输入组织方式：在生成回答之前，先把外部知识、对话历史、任务规则统一组织进上下文窗口，再让模型基于这个上下文进行推理。

它的核心链路可以拆成四步：

• 知识准备：把原始文档切成小块，做向量化，存进检索库。
• 意图检索：拿到用户问题后，从知识库里捞出最相关的若干块。
• 上下文拼装：把检索到的内容、系统提示词、历史对话、用户问题按顺序拼成Prompt。
• 生成回答：交给大模型，要求它只依据上文内容作答，并标明引用来源。

这套链路看起来每个环节都是常识，但真正把它做稳定，需要解决的问题一点都不少。后续章节我会把每个环节展开，这里先讲一个关键认知：Context-Mode的效果上限，取决于"检索"和"拼装"这两个容易被忽略的环节，而不取决于模型本身有多强。模型再聪明，你喂给它一堆不相关或者排列混乱的内容，它一样答不好。

2.3 权衡取舍：为什么不是所有场景都适合Context-Mode

当然，我不是说Context-Mode是银弹。如果你要做一个开放域闲聊机器人，它不需要严格溯源，直接对话式生成反而更自然;如果你的知识是高度结构化的，比如一张数据库表，比起拼上下文，写个SQL查询函数可能更准;如果你的数据量小到一只手数得过来且变化极少，那微调确实更省心。

我们当时选择Context-Mode，核心原因是业务有两个刚需：一是知识必须实时可更新，二是答案必须能引用出处。这两个刚需直接把微调和纯参数记忆排除了。所以你在做方案选型时，先别急着跟风，拿一张纸写下你的数据更新频率、溯源要求、成本预算，答案基本就浮出来了。Context-Mode最擅长解决的，是"有一堆散装文档，想让模型基于它们精确作答"这一类问题。

3. 核心细节解析与实操要点：Token预算、切片与检索质量

3.1 上下文窗口就是你的预算：Token怎么算才不会超

这是新手最容易炸的第一道防线。很多人以为模型写了"支持128K上下文"，就可以放心往里塞文档。实际上，等你把系统提示词、检索结果、历史对话、当前问题全部加起来，再预留回答空间，128K的天花板很快就能顶到。况且窗口越长，单次调用的费用越高，响应时间也跟着变长，盲塞并不划算。

我习惯的做法是，每次请求前先在代码里算一笔Token账。以我们项目为例，模型上下文上限按32K来规划（即便底层支持更大，我也只按32K做预算），分配大致如下：

这样一算，单次请求总消耗控制在12K以内，给模型留足了"思考余量"。你可别小看这个规划，实际项目里我见过太多人把上下文塞到90%，结果模型回答到一半报"maximum context length exceeded"，或者回答质量明显下降——因为模型在超长上下文里找重点的能力也是会衰减的。预算表列出来之后，建议把数字写进配置项，做成可动态调整的参数，而不是写死在代码里。

3.2 文档切片：切得好不好，直接决定后面所有环节的成败

切片是整个链路里最"脏"也最容易被忽视的活。很多人在这一步偷懒，直接把整个章节丢进向量库，结果检索时要么命中一大坨无关内容，要么因为切得太碎把一句完整的技术结论拆成两半。我调试过无数个"检索结果看起来相关但回答质量稀烂"的案例，最后八成问题都出在切片策略上。

切片的基本原则是：按语义完整块切，而不是按固定字符数硬切。我常用的一套组合策略是这样的：

• 优先按文档自带的层级结构切，比如Markdown的标题、Word的章节号，先切出段落级别的候选块。
• 对块内文本再判断长度，如果超过800个字符，就用滑动窗口继续细分;如果不足200个字符，就跟下一段合并。
• 相邻块之间保留50-100个字符的重叠。这个重叠是防止检索时把跨块的上下文切丢，比如一个结论在前一块末尾、解释在后一块开头的情况。

为什么是200到800这个区间？200字符以下的块常常语义不完整，没有检索价值;800字符以上则会导致向量表征被稀释——一个块里的有效信息可能只占一小部分，相似度检索时容易被噪声带偏。当然这个数值不是绝对的，中英文、技术文档还是对话记录，都得自己调。我的建议是，每次调整切片参数后，拿一批典型问题重新跑一遍检索，对比命中内容的质量，而不是凭感觉。

3.3 检索层：Top-K、重排序与相关度阈值，缺一不可

上下文内容的质量上限，由检索层决定。最初我们直接用向量相似度取Top-5，效果勉强能看，但经常出现"用户问A，检索出来B和C也混在里面"的情况。后来我加了两个关键动作，效果提升非常明显。

第一个动作是重排序。向量检索擅长找"语义上有点像"的内容，但它不太擅长判断"谁才是这个问题的正解"。所以在向量召回Top-20之后，我会用一个重排序模型（比如bge-reranker）对这20条重新打分，只取前3-5条进入上下文。重排序本质上是一个更精细的相关性判断器，它能结合问题和候选内容的词面、语义做交叉注意力计算，准确性比向量相似度高一截。这一步每多花几百毫秒，换来的往往是回答质量肉眼可见的提升。

第二个动作是设相关度下限。不是所有问题都能在知识库里找到答案，如果你不管三七二十一把最像那几条都塞进去，模型很容易被误导着"硬答"。我给重排序后的结果设了一个阈值，低于阈值的块直接丢弃。这时候再配合Prompt里的指令——"如果上下文没有足够信息，直接说不知道"——能大大减少胡说八道的情况。

3.4 上下文拼装的"隐藏规则"：顺序、格式与隔离

拼装顺序这件事，我一开始完全没在意，直到有一次发现模型总是忽略中间那段上下文，才意识到这里面有门道。业内把这个现象叫"Lost in the Middle"，意思是模型对长上下文开头和结尾的内容注意力更强，中间部分容易被忽略。

所以我的拼装规则是：

• 系统提示词放在最前面，明确模型角色和作答规则。
• 检索到的核心上下文放在系统提示词之后，尽量靠前，但保证每条内容之间用清晰的分隔符隔开。
• 历史对话放在上下文之后、用户当前问题之前。
• 用户当前问题紧挨着生成位置，让模型在回答时能直接聚焦。

此外还有两个看似细碎但很关键的细节。一是每条上下文前加上来源标签，比如"[引用1]文档《部署手册》第3节"，这样模型回答时可以直接引用编号，方便我做溯源;二是明确告诉模型"只能依据引用内容回答，不得使用你自身记忆中的知识"，这句话能极大降低模型自由发挥的冲动。别小看这两句指令，它们对回答可控性的提升，有时比你换一个更强的模型还明显。

4. 实操过程与核心环节实现：搭一个带Context-Mode的知识库问答服务

4.1 技术选型：这一套组合拳，兼顾效果与成本

实操部分，我会拿一个"产品文档问答助手"作为例子。技术栈选择上，我没有用太重的框架，核心就三样：一个向量数据库存切片，一个Embedding模型做文档向量化，一个兼容OpenAI接口的大模型做生成。中间那层检索与拼装逻辑，用Python手写，代码量不大，但每一步都能让你看清楚在干什么。

向量库我选了轻量的Chroma，适合本地开发和中小规模知识库;Embedding模型用现成的text-embedding接口，省钱省事;大模型也直接用现成的LLM接口。如果你想换成其他向量库，比如Milvus、Qdrant，或者换成其他模型服务商，只要改对应封装就行，整体架构不变。

这样选的原因是：项目初期最重要的是跑通链路、验证效果，而不是一上来就上一套微服务架构。等量上来了再考虑拆分也不迟。这里也分享一个踩坑教训：一开始我们想用LangChain一把梭，确实省事，但出了问题之后排查链路太长——到底是检索的问题还是Prompt的问题还是模型的问题，全被框架包住了。后来我改成手写核心逻辑，每个环节都变成独立函数，调试效率高了很多。

4.2 数据准备与向量化入库：先跑通"切分+入库"这一段

先看数据准备的代码。这里假设你有一批Markdown格式的文档，放在docs目录下。第一步是把文档按章节切块并向量化入库。

import os from pathlib import Path import chromadb from chromadb.utils import embedding_functions # 1. 读取文档，按层级分块 def split_document(text: str, max_chunk_size: int = 800, overlap: int = 50): lines = text.split("\n") chunks = [] current_chunk = [] current_len = 0 for line in lines: # 识别标题行，遇到新标题就切新块 if line.startswith("#") and current_chunk: chunks.append("\n".join(current_chunk)) current_chunk = [] current_len = 0 current_chunk.append(line) current_len += len(line) # 超过长度上限时，切块并保留重叠 if current_len >= max_chunk_size: chunk_text = "\n".join(current_chunk) chunks.append(chunk_text) overlap_text = chunk_text[-overlap:] current_chunk = [overlap_text] current_len = len(overlap_text) if current_chunk: chunks.append("\n".join(current_chunk)) return chunks # 2. 初始化向量库，指定Embedding模型 client = chromadb.PersistentClient(path="./kb_store") embed_fn = embedding_functions.OpenAIEmbeddingFunction( api_key=os.environ["OPENAI_API_KEY"], model_name="text-embedding-3-small" ) collection = client.get_or_create_collection( name="product_docs", embedding_function=embed_fn ) # 3. 遍历文档，切分并入库 doc_dir = Path("./docs") doc_id = 0 for doc_path in doc_dir.glob("*.md"): text = doc_path.read_text(encoding="utf-8") chunks = split_document(text) for idx, chunk in enumerate(chunks): # 元数据里记录来源，方便后面溯源 collection.add( ids=[f"doc_{doc_id}_chunk_{idx}"], documents=[chunk], metadatas=[{"source": str(doc_path), "chunk_index": idx}] ) doc_id += 1 print(f"已入库 {doc_path.name}: {len(chunks)} 个切片")

这里需要注意几个点。第一，Embedding接口的限流和费用。如果你有几千份文档，一次性全量入库挺费时间的，建议分批处理，并做好进度记录，断了能续跑。第二，切分函数里的标题检测是粗粒度实现，如果你的文档结构复杂，建议用专门的解析库做结构化切分。第三，入库时把来源信息写进metadata，后面回答时溯源就靠它，这一步别省。

4.3 检索与上下文拼装：把"取回数据"变成"可用的上下文"

检索与拼装是Context-Mode的核心环节。我的实现分三步：先向量召回候选集，再做重排序，最后拼装成符合规则的系统提示词。

import openai def retrieve_context(question: str, top_k: int = 20, rerank_top_n: int = 5): # 1. 向量检索召回候选集 candidates = collection.query( query_texts=[question], n_results=top_k, include=["documents", "metadatas", "distances"] ) docs = candidates["documents"][0] metas = candidates["metadatas"][0] # 2. 重排序：这里调用一个rerank接口做二次筛选 reranked = openai.rerank( model="bge-reranker-v2-m3", query=question, documents=docs, top_n=rerank_top_n ) # 3. 过滤低相关度结果，整理成带引用的格式 context_blocks = [] for item in reranked.results: if item.relevance_score < 0.35: continue src = metas[int(item.index)]["source"] ctx = item.document.text block = f"[引用] 来源: {src}\n{ctx}" context_blocks.append(block) return "\n\n".join(context_blocks) def build_prompt(question: str, history: list, context_text: str): system_prompt = """你是一个严谨的技术问答助手。请严格依据[引用]内容回答用户问题。 规则： 1. 只能使用上文提供的引用内容作答。 2. 如果引用内容不足，直接回答“根据现有资料无法确认”，不要自行推断。 3. 回答末尾标注用到的引用来源。 """ history_text = "" for turn in history[-3:]: # 只保留最近3轮 history_text += f"用户: {turn['user']}\n助手: {turn['assistant']}\n" user_prompt = f""" 【上下文内容】 {context_text} 【历史对话】 {history_text} 【用户问题】 {question} 请根据上下文内容回答。 """ return [ {"role": "system", "content": system_prompt}, {"role": "user", "content": user_prompt} ]

这段代码里有两个地方值得单独说。第一，重排序接口的relevance_score阈值0.35是我调出来的经验值，不同模型、不同场景分数分布不一样。你拿到数据后先打印一批分数看看分布，再定阈值，别直接抄。第二，历史对话我只保留3轮，这不是偷懒，而是防止早期对话把最新问题淹没掉。如果你做的是长会话场景，可以考虑用摘要的方式压缩更早的对话，但代价是增加一层摘要调用，我建议初期先截断，跑通再优化。

4.4 调用模型并检查输出：上下文给了，还得确认它真的在用

最后一步是调用大模型生成回答。选模型时，我会优先选上下文能力稳、指令遵循好的模型，而不是只看跑分。实际调用代码如下：

def ask_with_context(question: str, history: list): context_text = retrieve_context(question) if not context_text: return "根据现有资料，暂时无法回答该问题。", [] messages = build_prompt(question, history, context_text) response = openai.chat.completions.create( model="your-llm-model-name", messages=messages, temperature=0.2, # 低温度，让回答更贴近上下文 max_tokens=1500 ) answer = response.choices[0].message.content # 一个简单的质量自检：确认回答里引用了来源 if "[引用]" not in context_text or len(answer) < 3: pass # 如果发现模型回答里和引用内容完全对不上，说明检索或拼装有bug return answer, context_text

这里把温度调到0.2是有讲究的。Context-Mode场景下我们追求的是稳定和可溯源，不是创意发散，温度太高模型容易把上下文里的信息改写得面目全非。质量自检那段代码，我建议上线后做成日志：记录每个问题的上下文数量、重排序分数、回答长度、是否包含引用来源。这些日志往后做评估时都是宝贵的数据。我们当时就是因为没做日志，出了问题根本没法回溯是哪一次改动引入的，后来老老实实补上了。

5. 实测中踩过的坑：常见问题与排查方法实录

5.1 症状一："它总说不知道，可资料里明明有答案"

这个是最打击信任感的问题。用户一问三不知，第一反应是"模型太笨"，但实际排查下来，八成是检索环节把正确答案过滤掉了。我遇到过的典型原因有三个：

• 查询的措辞和文档里的措辞差别太大。用户问"怎么重置管理员密码"，文档里写的是"恢复root账户访问权限"，纯向量检索匹配不上。解法是用查询改写：先让模型把用户问题改写成几个更贴合文档用语的候选问法，再分别检索合并结果。
• 切片切断了关键信息。答案被夹在两个块的边界，哪一块都不完整。解法是检查重叠机制是否生效，或者用更大的块重试。
• 相关度阈值设太高，正确答案被误杀。把阈值往上调一档试试，或者先打日志看正确答案的重排序分数是多少。

排查顺序我推荐是先看检索结果，再反过来调Prompt。很多人一上来就改Prompt，那是舍本逐末。把检索到的内容打印出来人眼看一遍，如果人眼都觉得相关，再怀疑是生成环节的问题。

5.2 症状二：Token频繁超限，账单也压不住

上下文模式是Token消耗大户，稍微没控制好，几个问题下去就顶到上限。除了前面说的做好预算规划，还有几个实用招数：

• 给检索结果做"动态裁剪"。如果重排序后的某一块很长，但核心句子只有开头几句，可以用一个固定模板只截取每块的前N个字。别觉得粗暴，实际效果往往不差。
• 历史对话用摘要压缩。连续对话超过5轮后，用一次轻量调用把前面的对话总结成两句话，再放进上下文。这比全部丢掉更能保持语义连续。
• 按文档来源做过滤。用户明确在问"安装部署"时，如果上下文里混入了"故障排查"的内容，直接按metadata里的source字段过滤掉，省Token又提效果。

我见过有人为了省Token，把检索结果压缩得只剩几个关键词，结果模型完全无法理解。压缩要有底线，至少保留完整的因果句。

5.3 症状三：回答看似流畅，但细节是错的

这个最迷惑人，因为模型说得头头是道，你不核对原文根本发现不了。我们把这类错误归成两种：

第一种是"合理编造"。模型觉得引用内容信息不够，就自动用常识补了一段，补完还很符合上下文风格。解法就是前面说的，在系统提示词里把"只能依据引用内容回答"写上，同时把temperature压低。如果还压不住，可以在生成后又加一道校验：把回答里的事实性关键句拿出来做一次"是否可在引用中找到依据"的核对。这一步可以用模型自查，虽然会增加调用成本，但对事实准确性要求高的场景值得。

第二种是"错误引用"。模型把[引用1]的内容安到了[引用2]头上。这种情况通常是因为引用块数量太多、格式太接近，模型记混了。我后来在拼接时给每个引用块加了不同的前缀关键词，比如"文档A-部署手册第3节""文档B-FAQ第七问"，并严格要求模型按这个标识引用，明显改善了混引用的概率。

5.4 给一份排查速查表：从症状到解法一次给齐

我把上面讲的这些整理成一张速查表，方便你上线后遇到问题直接对着看：

这张表不一定覆盖所有情况，但能帮你快速定位问题在链路里的哪个环节。记住一条原则：Context-Mode的Bug绝大多数时候不在模型，而在上下文本身。

6. 这个模式还能怎么演进：三个值得尝试的扩展方向

6.1 让"是否启用上下文"变成一个可路由的决策

不是每个问题都需要走完整套检索。比如用户问"你好""你是谁"，你硬要走一遍检索和拼装，既浪费Token，又会因为检索到无关内容把简单问题搞复杂。我最近在做的改进是加一层路由：先让轻量模型判断这个问题是否需要外部知识，如果不需要，直接走普通对话;如果需要，再进入Context-Mode链路。这一层成本很低，但对体验和成本的改善都很大。你可以把它理解成给系统装了个分流闸，流量该走哪条路，先判一下再说。

6.2 基于反馈数据自动调整检索参数

我在前面反复提到阈值、Top-N、温度这些参数，它们现在都是人工调的。人工调的坏处是，你对某类问题调好了，换一类问题可能又不行。比较进阶的做法是，把每次问答的"用户反馈"（点赞/点踩）和"自动评估分数"收集起来，做成一个简单的评估集。每周自动跑一遍不同的参数组合，看哪组在评估集上表现最好，再自动更新线上的配置。这并不需要多复杂的机器学习流程，本质上就是"多组参数对拍选最优"，但带来的稳定性提升很可观。

6.3 用"上下文摘要"替代"上下文全文"，解决超长文档问题

对付超长文档，比如一本书、一份几百页的白皮书，直接切块检索仍然可能漏掉藏在长文中间的关键逻辑。我现在在尝试一种两级结构：预先为每个章节生成一段摘要，检索时先用问题匹配摘要，命中后再把对应章节的详细内容取出来拼装。这相当于给知识库加了一层索引目录，虽然入库时多花一次摘要调用，换来的却是检索精度和响应速度的双重提升。如果你的文档动辄上百页，非常建议试试这个思路。

说到最后，Context-Mode这个名字听起来像什么高深开关，拆开看其实就是"认真组织输入"这五个字。它没有把大模型变聪明，只是让大模型在回答时手里真的握着有用的资料。我做了快一年这类项目，最深的体会是：别迷信某一个神奇组件，也别跳过那些琐碎的工程质量——切片切得乱、检索调得糙、拼装没章法，再强的模型也救不回来。把上下文这条链路里的每一个环节当成正经产品来做，你得到的就不只是一个能跑的Demo，而是一个稳定、可溯源、能持续迭代的问答系统。希望我踩过的这些坑，能让你少走几段弯路。