把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.103.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, paramsparams, timeout10) 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的作品发表平台、长期合作的媒体、本人或官方团队运营的站点。白名单之外的域名第一次先抽查内容质量再决定要不要批量抓。这个谨慎不是多余的中文互联网的垃圾站点实在太多很多“资讯站”其实是自动采集的拼凑内容抓进来只会污染知识库。正文抓取这一步我用的是requests加BeautifulSoup做解析优先抽取article标签、content类的DIV同时排除导航栏、版权声明、广告区块。清洗逻辑如下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, stripTrue) if article else soup.get_text(\n, stripTrue) # 压缩多余空行 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_size300、chunk_overlap50。这个选择针对中文本地化场景做过调优。300字对中文来说大约是几段话的体量既保留了完整语义又不至于太碎。overlap设50字是为了避免语义被切刀从中间切断——比如一段话上半句在上一块下半句在下一块有了重叠检索时还能找回上下文。from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size300, chunk_overlap50, separators[\n\n, \n, 。, , , , , ], keep_separatorTrue, )separators这个参数值得多说一句。默认的英文切分器把空格和换行放在前面对中文就很吃亏因为中文的语义边界往往是句号和逗号。我把句子结束符的优先级调高切出来的块基本停在一句话的边界上后面做检索时的体验完全不一样。4.2 向量化与检索链路向量化我选了bge系列的中文模型这个选择基于两点一是对中文长文本的语义理解明显比通用模型稳二是它在检索任务上的表现经过了社区大量验证而且可以在本地离线跑不需要额外调用远程服务省一层依赖也少一层网络故障点。加载模型和建库的流程大致这样from langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_chroma import Chroma embedding HuggingFaceBgeEmbeddings( model_nameBAAI/bge-large-zh-v1.5, encode_kwargs{normalize_embeddings: True}, ) vectorstore Chroma( collection_namecelebrity_m, embedding_functionembedding, persist_directory./data/chroma_db, )normalize_embeddingsTrue这个参数是很多教程不会提但很重要的细节。归一化之后向量相似度用余弦距离计算才有意义不然内积和余弦会是两套标准检索排序容易飘。往向量库写入时我建议连元数据一起存标题、来源URL、发布日期、文档类型。这些信息后面有两个用处一是回答时引用出处让分身说“我在M的某次访谈里看到过这个观点”而不是凭空转述二是过滤用比如用户问的是近期的观点可以按日期字段过滤掉老文章。vectorstore.add_texts( textschunk_list, metadatasmetadata_list, ids[fdoc_{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( modelos.getenv(LLM_MODEL_NAME), api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), temperature0.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() )temperature0.4是调过的值。太低会让回答像念稿没有人物该有的松弛感太高会让模型自由发挥削弱知识库的约束力。0.4到0.5之间是个比较合适的区间具体可以按测试感受微调。k4代表召回四块文本拼进Prompt。这个值不是越大越好四块大概一千二百字既给了模型充分的上下文又不会把Prompt撑得太长。如果你发现经常需要更全的资料优先考虑切块是否太小而不是盲目加k。5.3 对话记忆与会话稳定到这里单轮问答已经通了。但数字分身不能是“金鱼记忆”用户说“我刚才问的那个作品你有印象吗”模型如果完全断片体验就崩了。对话记忆我用的是LangChain的ConversationSummaryBufferMemory它的思路是短期保留最近几轮完整对话更早的历史自动压缩成摘要这样既能让分身记住上下文又不会让历史无限占上下文窗口。from langchain.memory import ConversationSummaryBufferMemory from langchain_core.runnables.history import RunnableWithMessageHistory memory ConversationSummaryBufferMemory( llmllm, max_token_limit2000, memory_keychat_history, return_messagesTrue, ) chain_with_history RunnableWithMessageHistory( rag_chain, lambda session_id: memory, input_messages_keyquestion, history_messages_keychat_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_embeddingsTrue这里我想特别强调第一行那条。很多人一遇到召回质量差就想着换更贵的Embedding模型但实际上一半以上的问题出在切块策略上。中文不像英文有天然的空格分词切块时如果不照顾句号、问号这类语义边界语义就会被硬生生切开再好的向量模型也无能为力。先检查切块再怀疑模型这个排查顺序能帮你省很多冤枉钱。另一个容易被忽视的问题是数据时效性。如果你给M建库时跑了一批数据之后M又有了新的公开活动库里就会缺最新信息。我建议把采集和建库做成可重复执行的任务定期增量补充。尤其要注意的是不要把新数据和老数据混在同一个collection里不去重否则同一条信息的新旧版本会互相打架检索排序会很不稳定。6.3 关于“像不像”的几点真实体会项目跑通之后我做了不少内部测试。最有意思的发现是决定用户“像不像”感受的往往不是模型答出了多少冷门细节而是答得有没有“人味”。有一次我拿M的一篇公开访谈做测试模型完整复述了访谈里的观点但语气完全是一本正经的摘要腔被同事评价“不像M像报道M的新闻稿”。后来我把访谈里那种习惯性的转折词和口头禅提炼出来加进Prompt同一批问题再测观感立刻不一样。还有一个体会是资料库里“争议性内容”的处理需要谨慎。名人分身如果只捡正面信息建库回答会显得刻意用户稍微追问一些敏感经历就会发现答不上来但把网络上的各种未经验证的传闻也全收进去又会带来事实性风险。我的做法是事实性信息优先采用多方来源对照印象性评价和传闻单独打标签存库命中和用户主动问到时才被动提及并且加上“这是外界的说法”这类限定语。这个分寸拿捏既保住了可信度也保留了人物的复杂性。最后再分享一个小技巧多轮对话里如果你发现模型开始“用力过猛”满口都是M的观点但缺乏具体细节支撑试着把检索到但未直接引用的文本块也以“补充背景”的形式放在Prompt末尾。这个做法看似占用了一点上下文但实际上能让模型在组织语言时吸收更多隐性信息回答的颗粒感会细腻很多。这个项目做完第一版我的结论是LangChain加百度搜索API这套组合非常适合用来快速搭建中文场景下的人物知识问答系统。它的下限很低跟着教程两三天就能跑通上限也不低数据质量、切块策略、人设提炼、记忆管理每一步都有大量可优化的空间。第二篇我准备重点写对话记忆的深度优化、人设风格自动提取以及如何把这一整套东西包装成对外可用的服务。到时候见。
把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.103.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, paramsparams, timeout10) 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的作品发表平台、长期合作的媒体、本人或官方团队运营的站点。白名单之外的域名第一次先抽查内容质量再决定要不要批量抓。这个谨慎不是多余的中文互联网的垃圾站点实在太多很多“资讯站”其实是自动采集的拼凑内容抓进来只会污染知识库。正文抓取这一步我用的是requests加BeautifulSoup做解析优先抽取article标签、content类的DIV同时排除导航栏、版权声明、广告区块。清洗逻辑如下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, stripTrue) if article else soup.get_text(\n, stripTrue) # 压缩多余空行 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_size300、chunk_overlap50。这个选择针对中文本地化场景做过调优。300字对中文来说大约是几段话的体量既保留了完整语义又不至于太碎。overlap设50字是为了避免语义被切刀从中间切断——比如一段话上半句在上一块下半句在下一块有了重叠检索时还能找回上下文。from langchain_text_splitters import RecursiveCharacterTextSplitter splitter RecursiveCharacterTextSplitter( chunk_size300, chunk_overlap50, separators[\n\n, \n, 。, , , , , ], keep_separatorTrue, )separators这个参数值得多说一句。默认的英文切分器把空格和换行放在前面对中文就很吃亏因为中文的语义边界往往是句号和逗号。我把句子结束符的优先级调高切出来的块基本停在一句话的边界上后面做检索时的体验完全不一样。4.2 向量化与检索链路向量化我选了bge系列的中文模型这个选择基于两点一是对中文长文本的语义理解明显比通用模型稳二是它在检索任务上的表现经过了社区大量验证而且可以在本地离线跑不需要额外调用远程服务省一层依赖也少一层网络故障点。加载模型和建库的流程大致这样from langchain_community.embeddings import HuggingFaceBgeEmbeddings from langchain_chroma import Chroma embedding HuggingFaceBgeEmbeddings( model_nameBAAI/bge-large-zh-v1.5, encode_kwargs{normalize_embeddings: True}, ) vectorstore Chroma( collection_namecelebrity_m, embedding_functionembedding, persist_directory./data/chroma_db, )normalize_embeddingsTrue这个参数是很多教程不会提但很重要的细节。归一化之后向量相似度用余弦距离计算才有意义不然内积和余弦会是两套标准检索排序容易飘。往向量库写入时我建议连元数据一起存标题、来源URL、发布日期、文档类型。这些信息后面有两个用处一是回答时引用出处让分身说“我在M的某次访谈里看到过这个观点”而不是凭空转述二是过滤用比如用户问的是近期的观点可以按日期字段过滤掉老文章。vectorstore.add_texts( textschunk_list, metadatasmetadata_list, ids[fdoc_{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( modelos.getenv(LLM_MODEL_NAME), api_keyos.getenv(LLM_API_KEY), base_urlos.getenv(LLM_BASE_URL), temperature0.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() )temperature0.4是调过的值。太低会让回答像念稿没有人物该有的松弛感太高会让模型自由发挥削弱知识库的约束力。0.4到0.5之间是个比较合适的区间具体可以按测试感受微调。k4代表召回四块文本拼进Prompt。这个值不是越大越好四块大概一千二百字既给了模型充分的上下文又不会把Prompt撑得太长。如果你发现经常需要更全的资料优先考虑切块是否太小而不是盲目加k。5.3 对话记忆与会话稳定到这里单轮问答已经通了。但数字分身不能是“金鱼记忆”用户说“我刚才问的那个作品你有印象吗”模型如果完全断片体验就崩了。对话记忆我用的是LangChain的ConversationSummaryBufferMemory它的思路是短期保留最近几轮完整对话更早的历史自动压缩成摘要这样既能让分身记住上下文又不会让历史无限占上下文窗口。from langchain.memory import ConversationSummaryBufferMemory from langchain_core.runnables.history import RunnableWithMessageHistory memory ConversationSummaryBufferMemory( llmllm, max_token_limit2000, memory_keychat_history, return_messagesTrue, ) chain_with_history RunnableWithMessageHistory( rag_chain, lambda session_id: memory, input_messages_keyquestion, history_messages_keychat_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_embeddingsTrue这里我想特别强调第一行那条。很多人一遇到召回质量差就想着换更贵的Embedding模型但实际上一半以上的问题出在切块策略上。中文不像英文有天然的空格分词切块时如果不照顾句号、问号这类语义边界语义就会被硬生生切开再好的向量模型也无能为力。先检查切块再怀疑模型这个排查顺序能帮你省很多冤枉钱。另一个容易被忽视的问题是数据时效性。如果你给M建库时跑了一批数据之后M又有了新的公开活动库里就会缺最新信息。我建议把采集和建库做成可重复执行的任务定期增量补充。尤其要注意的是不要把新数据和老数据混在同一个collection里不去重否则同一条信息的新旧版本会互相打架检索排序会很不稳定。6.3 关于“像不像”的几点真实体会项目跑通之后我做了不少内部测试。最有意思的发现是决定用户“像不像”感受的往往不是模型答出了多少冷门细节而是答得有没有“人味”。有一次我拿M的一篇公开访谈做测试模型完整复述了访谈里的观点但语气完全是一本正经的摘要腔被同事评价“不像M像报道M的新闻稿”。后来我把访谈里那种习惯性的转折词和口头禅提炼出来加进Prompt同一批问题再测观感立刻不一样。还有一个体会是资料库里“争议性内容”的处理需要谨慎。名人分身如果只捡正面信息建库回答会显得刻意用户稍微追问一些敏感经历就会发现答不上来但把网络上的各种未经验证的传闻也全收进去又会带来事实性风险。我的做法是事实性信息优先采用多方来源对照印象性评价和传闻单独打标签存库命中和用户主动问到时才被动提及并且加上“这是外界的说法”这类限定语。这个分寸拿捏既保住了可信度也保留了人物的复杂性。最后再分享一个小技巧多轮对话里如果你发现模型开始“用力过猛”满口都是M的观点但缺乏具体细节支撑试着把检索到但未直接引用的文本块也以“补充背景”的形式放在Prompt末尾。这个做法看似占用了一点上下文但实际上能让模型在组织语言时吸收更多隐性信息回答的颗粒感会细腻很多。这个项目做完第一版我的结论是LangChain加百度搜索API这套组合非常适合用来快速搭建中文场景下的人物知识问答系统。它的下限很低跟着教程两三天就能跑通上限也不低数据质量、切块策略、人设提炼、记忆管理每一步都有大量可优化的空间。第二篇我准备重点写对话记忆的深度优化、人设风格自动提取以及如何把这一整套东西包装成对外可用的服务。到时候见。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
