LangChain+百度搜索API搭建RAG人物知识库：从公开资料到数字分身-平芜编程栈

把LangChain和百度搜索API串起来，给一位公众人物做数字分身，听起来像是营销噱头，但拆开看，它就是一个非常典型的RAG项目：先搜资料、再建知识库、最后让大模型带着人设去回答问题。我最近用这套框架完整跑通了一遍，过程中踩了不少坑，也总结出一些值得复用的经验。这篇文章是系列第一篇，重点放在“如何把散落在中文互联网上的公开资料，变成可检索的人物知识库”，对话层、记忆优化和部署留到下一篇。

先说清楚一个前提：这里说的“名人数字分身”，不是生成换脸视频，也不是克隆声音，而是做一个“顶着某个人设、基于公开资料回答问题”的对话系统。比如你问“M怎么看教育”，系统会用M公开谈过的观点、写过的话来回答，而不是让大模型凭空编。M是谁不重要，下文统一用“M”代替，你可以替换成任何公开资料充足的目标对象。关键是这套流程本身。

1. 项目到底在做什么：一套标准的RAG人物问答系统

1.1 数字分身不是玄学，是把人设搬到检索增强生成里

一开始我收到这个需求时，脑子里跳出来的方案有两个：一个是微调大模型，用一堆人物语料去SFT一个专属模型；另一个就是RAG，把资料存进向量库，问答时检索出来拼进Prompt。

微调看起来更“专业”，但落地时你会发现几个问题：第一，语料量不够。数字分身想让人觉得“像”，至少得几十万条高质量问答对，而为一个人攒这么多数据，成本不是一般的高；第二，资料是活的。M今天有新访谈、新观点，微调模型想更新一次，就得重新训练，代价很大；第三，微调很容易让模型学到风格但丢掉事实，回答里一旦注入幻觉，用户立刻就觉得“这不是本人”。

RAG方案正好绕开这三个问题。它的思路很简单：把M的公开资料切块、向量化、存进向量库；用户提问时，先去向量库里检索最相关的几段资料，再连同人设Prompt一起交给大模型生成回答。资料是检索出来的，所以有据可依；更新知识只需要往库里加文档；成本就是一次性的索引构建加每次问答的API费用。对“名人分身”这种应用来说，RAG是明显更优的起点。

1.2 为什么选LangChain加百度搜索API这个组合

选LangChain，不是因为它功能最全，而是因为它的抽象层刚好覆盖了这条链路的每一个环节：网页请求要封装成工具，文本要分割，向量库要读写，Prompt模板要管理，带记忆的问答链要组装。这些组件LangChain社区都有现成实现，不用自己写胶水代码。当然你也可以不用框架手搓，但那意味着你要自己维护一堆接口适配，后续加功能会很痛苦。

选百度搜索API，核心原因是中文内容覆盖。M的采访、随笔、公开演讲，大部分散落在中文网页上，百度搜索对中文站点的收录质量是明显有优势的。另一个原因是搜索API拿到的是结构化结果——标题、链接、摘要——天然适合做数据清洗。自己写爬虫去抓搜索引擎的HTML页面不是不行，但解析规则脆弱，页面改版就崩，而且频率一高很容易触发风控。用API化访问的方式，至少在接口层面是稳定的。

1.3 整体流程拆解

整个项目分成四层，我这张图是画给自己团队看的，你也照着这个思路搭：

数据采集层：设计搜索词，调用百度搜索API拉取M相关的公开网页信息，重点是标题、摘要、URL；
知识构建层：把摘要和抓取回来的正文做清洗，去广告、去导航、去重复，然后切块、向量化、写入向量库；
检索问答层：用户提问后，做向量召回，把命中的文本块拼进角色化Prompt，交给大模型生成回答；
记忆与体验层：维护多轮对话记忆，让分身记得“刚才聊到哪了”，同时做人设一致性约束。

这篇先完整落地前两层，第三层给出可运行的最小链路，第四层只讲思路，详细实现在系列第二篇展开。

2. 环境与选型：版本、依赖、配置一次到位

2.1 依赖安装与版本锁定

这个项目对Python版本没有特别苛刻的要求，我用的3.10，3.9以上都没问题。安装依赖之前，建议先建一个虚拟环境，避免和系统Python打架。核心依赖就这么几个：

pip install langchain pip install langchain-community pip install langchain-chroma pip install faiss-cpu pip install bge-m3 pip install python-dotenv

这里稍微解释一下为什么拆得这么细。新版LangChain把核心框架和第三方集成拆成了不同的包，langchain是主框架，langchain-community里放着各种社区工具（包括百度搜索的封装），langchain-chroma是向量库的封装。你如果图省事直接pip install langchain装全家桶，也能跑，但依赖会非常臃肿，后面排查问题时很痛苦。我建议按需安装，每一个包都明确知道自己为什么存在。

版本上有个坑要提醒：LangChain的API迭代很快，网上很多教程用的还是0.x版本的写法，比如from langchain.llms import OpenAI这种老接口，在新版里已经挪到langchain_community或者被弃用了。我这篇用的是1.x时期的主流写法，你装依赖时最好pip freeze > requirements.txt把版本锁住，之后复现也方便。

2.2 凭据管理与目录结构

百度搜索API和后续要接的大模型API都需要密钥。我习惯用.env文件管理，不放代码里，更不提交到仓库。

BAIDU_API_KEY=你申请到的密钥 BAIDU_API_SECRET=对应的Secret LLM_API_KEY=你正在用的大模型服务密钥 LLM_BASE_URL=模型服务的接口地址 LLM_MODEL_NAME=模型名称

用python-dotenv加载非常省事，项目启动时自动读取。目录结构我建议这样组织：

celebrity_twin/ ├── .env # 密钥配置 ├── requirements.txt # 依赖锁定 ├── config.py # 全局配置读取 ├── collector/ # 百度搜索采集模块 │ ├── search_client.py # 搜索API封装 │ └── keywords.py # 关键词规划 ├── knowledge/ # 知识库构建模块 │ ├── splitter.py # 文本切块 │ ├── embedder.py # 向量化 │ └── vector_store.py # 向量库读写 ├── rag/ # 问答链路模块 │ ├── prompt_templates.py # 人设Prompt │ ├── chain.py # 检索问答链 │ └── memory.py # 对话记忆 ├── data/ # 原始资料、中间结果 │ ├── raw/ # 搜索返回的原始JSON │ └── cleaned/ # 清洗后的纯文本 └── scripts/ # 运行脚本

这个结构不算复杂，但每个模块职责清晰，后面单独调采集或者调检索的时候，不用在几百行代码里翻来翻去。我在做第一个版本时直接把所有代码写在一个脚本里，跑到后面想加个数据统计，改一处崩三处，教训深刻。

大模型这块，我建议选兼容标准Chat Completion接口的服务，这样LangChain里只需要写一次调用逻辑，以后想换模型，改环境变量就行。M的问答对模型的中文语感和指令遵循能力要求比较高，选模型时优先看中文能力和上下文长度，上下文最好能到8K以上，否则塞了资料和对话历史后很容易截断。

3. 数据采集：用百度搜索API批量拉取公开资料

3.1 搜索关键词设计是数据质量的起点

很多人做这个项目会把精力全放在后面的Prompt上，但实际决定数字分身“像不像”的，首先是喂进去的资料质量。如果库里全是百科词条式的干巴巴生平，那回答再流畅也是个百科机器人；如果库里有访谈、随笔、演讲实录，回答才会有人味儿。

所以关键词不能只搜“M”，要按信息类型拆维度。我做了八组关键词，覆盖M的不同侧面：

生平经历史：“M 生平”“M 早年经历”“M 人物生平”
代表作品：“M 作品”“M 代表作”“M 创作谈”
观点访谈：“M 访谈”“M 专访”“M 对话”
演讲发言：“M 演讲”“M 发言实录”“M 论坛”
私人随笔：“M 随笔”“M 专栏”“M 书信”
争议评价：“M 争议”“M 评价”“M 批评”
时代背景：“M 与 XX浪潮”“M 时代”
细节花絮：“M 轶事”“M 生活细节”“M 习惯”

每组关键词再配上两三个同义词变体，比如“访谈”和“对话”和“问答”其实是同一类。这样做的目的很朴素：不同网站对同一内容的措辞不同，关键词太死，召回率会很低。我第一版只用了“M 访谈”一个词，结果搜索API返回的全是同一个门户网站的几篇文章，覆盖率惨不忍睹。

另外一个细节是时间范围。如果M的活动周期持续了很长时间，建议按时间段分段拉取，比如1990到2000、2000到2010，这样能避免搜索结果被近几年的内容淹没，也能更好地覆盖M不同人生阶段的信息。百度搜索API一般支持时间筛选参数，没有的话就在关键词里加年份。

3.2 请求参数与结果解析

我封装搜索请求的思路是这样的：每次调用传入查询词、页码、每页条数和可选的站点过滤条件，返回结构化结果列表。核心代码大致长这样：

import os import time import hashlib import requests from typing import List, Dict class BaiduSearchClient: def __init__(self): self.api_key = os.getenv("BAIDU_API_KEY") self.api_secret = os.getenv("BAIDU_API_SECRET") self.base_url = "https://api.search.example.com/v1/search" def _sign(self, params: Dict) -> str: # 按常见API签名规范：参数排序后拼接密钥做哈希 raw = "&".join(f"{k}={v}" for k, v in sorted(params.items())) return hashlib.md5((raw + self.api_secret).encode("utf-8")).hexdigest() def search(self, query: str, page: int = 1, per_page: int = 10) -> List[Dict]: params = { "q": query, "page": page, "per_page": per_page, "api_key": self.api_key, "ts": int(time.time()), } params["sign"] = self._sign(params) resp = requests.get(self.base_url, params=params, timeout=10) resp.raise_for_status() data = resp.json() results = [] for item in data.get("results", []): results.append({ "title": item.get("title", "").strip(), "url": item.get("url", ""), "snippet": item.get("abstract", "").strip(), "source": item.get("source", ""), "publish_date": item.get("publish_date", ""), }) return results

注意几点。第一，签名逻辑每个API服务商的规范不一样，有的用HMAC，有的直接在Header里传密钥，我这里是常见的一种做法，你实际对接时以服务商文档为准；第二，abstract也就是摘要字段，是后续知识库的主力数据来源，抓回来之后不要丢；第三，请求超时时间设10秒，搜索接口的响应普遍不快，只等3秒的话频繁超时。

爬回来的结果建议统一存成JSON行文件，每条一行，方便后续清洗和排错。文件名格式类似raw/m_20250608.jsonl，按日期命名，方便追溯这批数据是什么时候抓的。

3.3 抓取正文与清洗去重

只靠搜索摘要做知识库不是不行，但摘要一般只有几十到一两百字，信息密度低，而且搜索引擎的摘要经常截断得很生硬。我实际测试下来，想要让知识库支撑“M今天聊了什么话题”这种偏长尾的问答，还得把搜索结果里的正文页抓下来。

抓正文我坚持一个原则：只抓明确可靠来源的页面。我在代码里维护了一个白名单域名列表，比如M的作品发表平台、长期合作的媒体、本人或官方团队运营的站点。白名单之外的域名，第一次先抽查内容质量，再决定要不要批量抓。这个谨慎不是多余的，中文互联网的垃圾站点实在太多，很多“资讯站”其实是自动采集的拼凑内容，抓进来只会污染知识库。

def clean_html(html_text: str) -> str: soup = BeautifulSoup(html_text, "html.parser") for tag in soup.find_all(["script", "style", "nav", "footer", "aside"]): tag.decompose() article = soup.find("article") or soup.find("div", class_=lambda c: c and "content" in c.lower()) text = article.get_text("\n", strip=True) if article else soup.get_text("\n", strip=True) # 压缩多余空行 text = re.sub(r"\n{3,}", "\n\n", text) return text

然后做两层过滤。第一层是长度过滤，正文少于200字的页面直接丢弃，多半是转页或者纯索引页；第二层是相似度去重，用简单的文本哈希或者difflib比对标题正文，相似度超过0.85的只保留最早抓到的版本。这一步很重要，因为同一篇访谈经常被几十个网站转载，不去重的话，向量库里会出现大量重复内容，检索的时候会被同一篇文档刷屏。

到这里，“采集层”就算落地了。我实际跑了一个中型规模的目标人物，大概用了两组关键词，抓回来的搜索结果去重后有一千多条，再经过正文抓取和清洗，最终入库的有效文本近百篇。这个量对RAG问答来说已经能出效果了。

4. 知识库构建：文本分割、向量化、召回验证

4.1 为什么“存原文”不如“切块存”

很多第一次做RAG的同学会想：我直接把清洗后的全文扔给大模型不就行了？上下文塞得下就塞，塞不下就截断。这个想法在几十条资料的规模下勉强能跑，但马上会撞两个墙：

第一是上下文长度。M的访谈全文动辄几千字，一次问答把几篇全文都塞进Prompt，你的模型上下文再长也会爆，更何况还要留空间给对话历史和系统人设。

第二是检索精度。用户问“M对教育的看法”，两篇各一万字的文章里，相关段落可能只有那么三四百字。如果不切块，向量化时整篇文章被压缩成一个向量，语义细节全被冲淡，检索出来的结果是“整篇文章都相关”，但大模型面对一大坨流水账，很难精准踩中回答需要的具体段落。

所以正确做法是：把长文档切成适当大小的文本块，每个块单独向量化、单独入库。用户提问时，命中的是一个个语义精准的小块，拼进Prompt的也都是和问题高度相关的段落。经典RAG几乎都采用这个范式，不是没有原因的。

我用的切块参数是chunk_size=300、chunk_overlap=50。这个选择针对中文本地化场景做过调优。300字对中文来说大约是几段话的体量，既保留了完整语义，又不至于太碎。overlap设50字，是为了避免语义被切刀从中间切断——比如一段话上半句在上一块，下半句在下一块，有了重叠，检索时还能找回上下文。

from langchain_text_splitters import RecursiveCharacterTextSplitter splitter = RecursiveCharacterTextSplitter( chunk_size=300, chunk_overlap=50, separators=["\n\n", "\n", "。", "！", "？", "；", "，", " "], keep_separator=True, )

separators这个参数值得多说一句。默认的英文切分器把空格和换行放在前面，对中文就很吃亏，因为中文的语义边界往往是句号和逗号。我把句子结束符的优先级调高，切出来的块基本停在一句话的边界上，后面做检索时的体验完全不一样。

4.2 向量化与检索链路

向量化我选了bge系列的中文模型，这个选择基于两点：一是对中文长文本的语义理解明显比通用模型稳，二是它在检索任务上的表现经过了社区大量验证，而且可以在本地离线跑，不需要额外调用远程服务，省一层依赖也少一层网络故障点。

加载模型和建库的流程大致这样：

from langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_chroma import Chroma embedding = HuggingFaceBgeEmbeddings( model_name="BAAI/bge-large-zh-v1.5", encode_kwargs={"normalize_embeddings": True}, ) vectorstore = Chroma( collection_name="celebrity_m", embedding_function=embedding, persist_directory="./data/chroma_db", )

normalize_embeddings=True这个参数是很多教程不会提但很重要的细节。归一化之后，向量相似度用余弦距离计算才有意义，不然内积和余弦会是两套标准，检索排序容易飘。

往向量库写入时，我建议连元数据一起存：标题、来源URL、发布日期、文档类型。这些信息后面有两个用处：一是回答时引用出处，让分身说“我在M的某次访谈里看到过这个观点”，而不是凭空转述；二是过滤用，比如用户问的是近期的观点，可以按日期字段过滤掉老文章。

vectorstore.add_texts( texts=chunk_list, metadatas=metadata_list, ids=[f"doc_{i:04d}" for i in range(len(chunk_list))], )

向量库我用的Chroma，因为它本地持久化做得最省心，一个目录搞定，适合这个体量的项目。如果文档规模到了几十万块，再考虑换更重型的方案，前期没必要给自己加运维负担。

4.3 召回质量自测方法

建完库别急着接大模型，先做一轮召回自测。方法很土但非常有效：准备一组模拟用户可能会问的问题，逐个去向量库检索，人工检查召回的前三块文本是不是真的和问题相关。

我准备的测试问题包括：

“M小时候的成长经历是什么样的？”
“M怎么看待技术和人的关系？”
“M印象最深的一部作品是哪个？”
“M对年轻人的建议是什么？”

然后逐条看检索结果。这里有个常见现象：第一次建库后，召回结果往往差强人意，有些问题能召回正确段落，有些问题召回的块完全跑偏。排查思路是回头调整切块参数，或者检查是不是某些重要材料压根没入库。我遇到过最典型的情况是：某次清洗时把一篇长访谈的后续页面当成了重复内容过滤掉，结果用户问“M中期创作理念”时，库里只剩零散片段，召回质量自然崩。

自测通过的标准是：大部分问题的前三块召回都精准命中。如果做不到，先调数据，再调参数，顺序不要反。数据没问题但召回仍差，才考虑换Embedding模型或者调top_k。

5. 角色化问答链：从知识库到“分身”

5.1 人设Prompt的写法

知识库就绪后，真正让回答“像M”的，是人设Prompt。这一部分看似简单，实际非常考验细节。

我的系统Prompt结构分四层：身份设定、说话风格、知识边界、应答规则。大致模板如下：

SYSTEM_PROMPT = """ 你正在扮演人物M，一位{职业}。请严格遵循以下规则： 【身份与背景】 - 你拥有M的全部生平经历和知识背景 - 你阅读过资料库中关于M的所有公开资料 - 你以M的第一人称视角回答用户的问题 【说话风格】 - 语气{语气特征} - 表达{措辞习惯} - 避免{禁忌词或风格} 【知识边界】 - 只基于检索资料中的事实作答 - 如果资料中没有相关内容，坦率说明“这一点我没有公开谈过” - 绝不编造M没有说过的话、没有做过的事 【应答规则】 - 回答控制在{字数}字以内 - 结合{核心观点关键词} - 每条关键观点尽量附上出处，如“这是我某次访谈中提到过的” """

这里最关键的是“知识边界”这一层。数字分身做得像不像，很大程度上取决于它会不会诚实地说“不知道”。一个什么都能编的假M，用户问两轮就会识破；一个知道自己哪里不知道的M，反而更可信。实际上这也是RAG和纯模型臆想的根本区别。

语气特征和措辞习惯从哪里来？就是我们在采集层积累的资料。做人物分析时，把访谈和随笔里反复出现的高频词、句式、口头禅整理出来，填进{语气特征}和{措辞习惯}里。这一步是人工活，但也是数字分身“像不像”的灵魂所在，偷懒不得。

5.2 用LangChain组装检索问答链

我建议用LangChain的LCEL表达式语言来组装链路，它比老式的RetrievalQA更可控，每一步的输入输出都透明，调试时能看中间结果。

from langchain.chat_models import init_chat_model from langchain_core.prompts import ChatPromptTemplate from langchain_core.output_parsers import StrOutputParser from langchain_core.runnables import RunnablePassthrough llm = init_chat_model( model=os.getenv("LLM_MODEL_NAME"), api_key=os.getenv("LLM_API_KEY"), base_url=os.getenv("LLM_BASE_URL"), temperature=0.4, ) prompt = ChatPromptTemplate.from_messages([ ("system", SYSTEM_PROMPT), ("human", "用户的提问：{question}\n\n相关资料：\n{context}"), ]) retriever = vectorstore.as_retriever(search_kwargs={"k": 4}) def format_docs(docs): return "\n\n---\n\n".join(doc.page_content for doc in docs) rag_chain = ( {"context": retriever | format_docs, "question": RunnablePassthrough()} | prompt | llm | StrOutputParser() )

temperature=0.4是调过的值。太低会让回答像念稿，没有人物该有的松弛感；太高会让模型自由发挥，削弱知识库的约束力。0.4到0.5之间是个比较合适的区间，具体可以按测试感受微调。

k=4代表召回四块文本拼进Prompt。这个值不是越大越好，四块大概一千二百字，既给了模型充分的上下文，又不会把Prompt撑得太长。如果你发现经常需要更全的资料，优先考虑切块是否太小，而不是盲目加k。

5.3 对话记忆与会话稳定

到这里，单轮问答已经通了。但数字分身不能是“金鱼记忆”，用户说“我刚才问的那个作品，你有印象吗？”，模型如果完全断片，体验就崩了。

对话记忆我用的是LangChain的ConversationSummaryBufferMemory，它的思路是：短期保留最近几轮完整对话，更早的历史自动压缩成摘要，这样既能让分身记住上下文，又不会让历史无限占上下文窗口。

from langchain.memory import ConversationSummaryBufferMemory from langchain_core.runnables.history import RunnableWithMessageHistory memory = ConversationSummaryBufferMemory( llm=llm, max_token_limit=2000, memory_key="chat_history", return_messages=True, ) chain_with_history = RunnableWithMessageHistory( rag_chain, lambda session_id: memory, input_messages_key="question", history_messages_key="chat_history", )

注意这里有个藏得很深的坑：记忆中的历史对话里，模型上一轮回答的内容如果没有标注是“M说的”，塞回Prompt时可能和身份设定冲突，模型会分不清哪句是用户说的、哪句是它自己扮演的M说的。所以写进记忆的历史消息，一定要在系统Prompt里说明“以下是历史上你和用户的对话，其中assistant的消息代表你当时说的”，把这个边界划清楚。

会话稳定性还有一个小技巧：如果同一轮里用户多次追问同一话题，可以在检索时带上上一轮的关键词做查询改写。比如用户第一轮问“你怎么看教育”，第二轮说“那就多讲讲学校吧”，直接把“学校”拿去检索，大概率召回一堆不相关的东西。把上一轮的主要语义和当前问题合并成新的检索query，召回质量会明显提升。

6. 常见问题和避坑实录

6.1 采集中遇到的三个典型问题

第一个是搜索API的限流。我的第一版脚本没有做任何限速，循环拉关键词时一口气请求了几百次，很快就触发了服务商的频率限制，返回直接变成错误码。后来我在search()方法里加了重试和退避逻辑：遇到429或503，先等2秒再重试，连续失败三次就停30秒，并且每次调用之间强制sleep(0.5)。采集任务本来就是离线跑，慢一点无所谓，稳定不封号才是关键。

第二个是“关键词回声”。搜“M 访谈”出来的前几页结果，经常都是同一个站点批量发布的自动采集稿，标题几乎一样，内容高度重复。这个靠3.3里的相似度去重能解决大半，但更根本的办法是关键词多样化之后，把抓回来的结果按来源URL的域名做聚合统计，看看是不是集中在少数几个站点——如果是，就说明关键词设计太窄了，需要补充更多维度的搜索词。

第三个是正文抓取失败率奇高。很多内容平台的页面是动态渲染的，requests拿到的HTML里根本没有正文，全是JS脚本。我一开始死磕动态渲染解析，后来想通了：对于这类站点，搜索API返回的摘要反而是更可靠的数据源。摘要本身就是平台从正文里提炼出来的核心句，直接入库虽然信息量少一些，但准确度极高。现在我的策略是：能抓到高质量静态正文的抓正文，抓不到的就用摘要兜底，绝不硬上浏览器渲染方案给自己找麻烦。

6.2 检索与生成环节的排查方法

我把这个项目里反复遇到的检索和生成问题整理成了排查表，按现象、原因、处理三步走：

现象	可能原因	处理手段
召回的全是不相关内容	切块太大或太小，语义边界被切断	调chunk_size到200~400区间重新测试
同一篇文档反复霸屏	未做相似度去重，转载内容重复入库	按标题和正文哈希去重，只保留最早版本
用户问细节，回答却很模糊	检索命中的文本块太少，上下文不够	先检查切块质量，再适当调大`k`值
M会一本正经编造事实	Prompt缺少知识边界约束	强化“没有资料就承认不知道”的规则，并要求附出处
多轮对话后M“变了一个人”	历史消息身份边界没划清	在Prompt中明确历史消息中assistant消息的来历
回答风格不像M	语气特征没有提炼到位	人工分析语料，把高频词和句式写进风格层
检索时好时坏，不稳定	向量归一化未开启	Embedding时开启`normalize_embeddings=True`

这里我想特别强调第一行那条。很多人一遇到召回质量差就想着换更贵的Embedding模型，但实际上一半以上的问题出在切块策略上。中文不像英文有天然的空格分词，切块时如果不照顾句号、问号这类语义边界，语义就会被硬生生切开，再好的向量模型也无能为力。先检查切块，再怀疑模型，这个排查顺序能帮你省很多冤枉钱。

另一个容易被忽视的问题是数据时效性。如果你给M建库时跑了一批数据，之后M又有了新的公开活动，库里就会缺最新信息。我建议把采集和建库做成可重复执行的任务，定期增量补充。尤其要注意的是，不要把新数据和老数据混在同一个collection里不去重，否则同一条信息的新旧版本会互相打架，检索排序会很不稳定。

6.3 关于“像不像”的几点真实体会

项目跑通之后，我做了不少内部测试。最有意思的发现是：决定用户“像不像”感受的，往往不是模型答出了多少冷门细节，而是答得有没有“人味”。有一次我拿M的一篇公开访谈做测试，模型完整复述了访谈里的观点，但语气完全是一本正经的摘要腔，被同事评价“不像M，像报道M的新闻稿”。后来我把访谈里那种习惯性的转折词和口头禅提炼出来加进Prompt，同一批问题再测，观感立刻不一样。

还有一个体会是：资料库里“争议性内容”的处理需要谨慎。名人分身如果只捡正面信息建库，回答会显得刻意，用户稍微追问一些敏感经历就会发现答不上来；但把网络上的各种未经验证的传闻也全收进去，又会带来事实性风险。我的做法是：事实性信息优先采用多方来源对照，印象性评价和传闻单独打标签存库，命中和用户主动问到时才被动提及，并且加上“这是外界的说法”这类限定语。这个分寸拿捏，既保住了可信度，也保留了人物的复杂性。

最后再分享一个小技巧：多轮对话里，如果你发现模型开始“用力过猛”，满口都是M的观点但缺乏具体细节支撑，试着把检索到但未直接引用的文本块也以“补充背景”的形式放在Prompt末尾。这个做法看似占用了一点上下文，但实际上能让模型在组织语言时吸收更多隐性信息，回答的颗粒感会细腻很多。

这个项目做完第一版，我的结论是：LangChain加百度搜索API这套组合，非常适合用来快速搭建中文场景下的人物知识问答系统。它的下限很低，跟着教程两三天就能跑通；上限也不低，数据质量、切块策略、人设提炼、记忆管理，每一步都有大量可优化的空间。第二篇我准备重点写对话记忆的深度优化、人设风格自动提取，以及如何把这一整套东西包装成对外可用的服务。到时候见。