用Python+OpenAI把对话记录变成智能客服机器人：Few-shot与RAG实战

你有没有过这种念头：手头攒了一大堆客服聊天记录、销售话术、或者教学答疑记录，想把这些沉淀成一个能自动回答问题的聊天机器人？这个需求太常见了，而且用 Python 调 OpenAI 接口完全能落地。但真正动手的时候，很多人第一步就跑偏了——把全部对话记录一股脑丢给接口，盼着模型自己“学会”。真相是，基于对话记录做聊天机器人，核心并不在“喂多少数据”，而在选对转换路线。

这篇文章我以一批真实客服对话记录为例（内容已脱敏），聊聊怎么把这些记录变成可用的机器人知识。从数据清洗讲起，分别给出小样本提示词方案和 RAG 检索增强方案，最后附上我日常踩坑的排查记录。适合做客服助手、销售陪练、教学答疑机器人的开发者参考；如果你完全零基础，也可以照着步骤复现。

1. 项目拆解：对话记录如何变成机器人知识

1.1 先搞清楚三条主流技术路线

对话记录在手里是什么形态？可能是客服工单导出的 CSV、聊天软件导出的文本、甚至语音转写出来的长对话。它们有个共同特点：非结构化、有噪音、格式乱。要把这些变成机器人能用的“知识”，不是简单把文件塞进模型就完事。

目前基于对话记录做聊天机器人，主流就是三条路线：

• 小样本提示词（Few-shot Prompting）：从记录里挑出几十组有代表性的问答，写进 system prompt，让模型模仿这批示例的回答风格和结构。
• 检索增强生成（RAG）：把大量对话记录切块、向量化，用户提问时先检索最相关的片段，再把这些片段作为参考资料交给模型组织答案。
• 微调（Fine-tuning）：用上万条标准化数据去更新模型参数，让模型自身学到某种表达习惯或领域知识。

选型逻辑特别现实：看数据量、看更新频率、看预算。我用这张表做个快速对照：

我的建议是，一开始别碰微调。一方面微调贵，另一方面对话记录不等于微调数据集，它需要转成严格的“指令-回答”格式，清洗量巨大；更坑的是，模型接口升级之后，你微调过的版本可能还停在旧模型上，追版本非常被动。RAG 和 Few-shot 的组合，在绝大多数业务场景里已经够用。

1.2 最容易踩的认知误区

这块我多说几句，因为接到的咨询里十个有九个都在这上面翻过车。

第一个误区是“对话记录是训练数据，丢进去模型自然就学会了”。OpenAI 接口的调用方式是“上下文窗口”，也就是每次把你要给模型看的内容按 messages 传进去，模型根据这些内容生成回答。它是通过上下文理解，不是通过训练记忆。你塞再多历史对话，都只是在影响当次回答的“临场发挥”，不会真的沉淀为模型长期记忆。

第二个误区是“上下文塞得越多，回答就越像”。上下文窗口确实能装不少内容，但塞太多会导致两个问题：一是成本按 Token 计算，几千条历史记录可能一次请求就烧掉几美元；二是关键信息被淹没在噪音里，模型的注意力是有限的，检索出来的相关片段明显比整段历史更聚焦、更可控。

第三个误区是“风格模仿只能靠模型自己去悟”。实际上，风格模仿是可以被“锚定”的。把几组语气鲜明、结构清晰的真实问答直接放进提示词，模型会精准复用这些格式。语气、断句、常用口头禅、甚至是否喜欢用短句，都能在示例里体现出来。

我实际项目里的做法是：拿到需求先问数据量。几百条以内的，直接走 Few-shot；数据量上了千、且答案高度依赖内部资料，就上 RAG。先跑通最小可用方案，确认瓶颈出在哪里，再决定要不要升级，永远比上来就整花活靠谱。

2. 环境准备与对话记录清洗

2.1 Python 环境与 OpenAI SDK 初始化

开始之前先把 Python 环境准备好。我推荐用虚拟环境隔离依赖，避免脏环境干扰。装这几个库就够了：

pip install openai python-dotenv pandas chromadb

新版 openai 库用起来比老版本顺手，初始化方式也更清爽。API Key 千万别写死在代码里，放到项目根目录的.env文件中，提交代码时把.env加进.gitignore。

# .env OPENAI_API_KEY=你的key

import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client = OpenAI( api_key=os.getenv("OPENAI_API_KEY"), timeout=30.0, max_retries=2, )

timeout 和 max_retries 是我习惯加的，网络抖动时不至于让服务一直挂着。聊天补全接口调用统一走client.chat.completions.create，模型名我会优先用gpt-3.5-turbo，处理客服问答、话术模仿这类任务性价比很高；如果项目里已经换了更新的型号，参数结构基本兼容。

2.2 对话记录清洗的三要素

原始对话记录有多脏，不处理真的没法直接用。我总结为三个必须做的步骤：

第一，身份标注。每一句都要能明确知道是谁说的。比如客服对话里，用户问一句、客服回一句，导出文件通常只给你一个长文本，需要把发言角色拆出来。角色只能用两类：user和assistant，这对应 OpenAI messages 结构里的两个角色。第三人称的“系统消息”“转接提示”不要混进去。

第二，噪音过滤。客服记录里大量混着时间戳、工单号、系统自动回复、操作日志。比如“您已被接入人工客服”“满意度评价请点击链接”，这类内容不是有效知识，进模型反而会干扰。我需要通过规则或长度阈值把它们筛掉。

第三，敏感信息脱敏。手机号、姓名、地址、订单号必须处理成占位符，别拿真实用户数据直接喂外部接口。这块既是隐私合规问题，也是技术质量问题——模型会把“138****1234”当成一个事实记进上下文，下次回答时它可能在无关问题里自动补全一个错误号码。

2.3 用一段脚本完成基础清洗

清洗脚本我习惯用 pandas 处理结构化数据，正则做脱敏，最后输出 JSONL 格式的对话对。示例如下：

import pandas as pd import re import json df = pd.read_csv("dialog_logs.csv") df = df.dropna(subset=["speaker", "content"]) # 过滤明显的系统流水 noise_keywords = ["系统消息", "满意度评价", "已转接", "工单号"] df = df[~df["content"].str.contains("|".join(noise_keywords), na=False)] # 过滤过短的无效内容 df = df[df["content"].str.len() >= 4] # 脱敏 def masking(text): text = re.sub(r"1[3-9]\d{9}", "[手机号]", text) # 手机号 text = re.sub(r"\d{16,19}", "[订单号]", text) # 订单编号 text = re.sub(r"[\u4e00-\u9fa5]{2,4}先生|[\u4e00-\u9fa5]{2,4}女士", "[客户]", text) # 称呼 return text.strip() df["content"] = df["content"].apply(masking)

清洗完的数据，我会再按问答顺序聚合成一组组对话。客服场景下，用户问题常常在中间段，客服回答在后面。简单聚合可以用“遇到 user 内容则新开一个会话块”的方式：把连续对话按用户轮次切段，每个段取“用户提问 + 客服回答”的相邻对。输出示例格式：

{"role": "user", "content": "这个订单什么时候发货"} {"role": "assistant", "content": "您好，您购买的订单预计明天发出，物流单号今晚更新，请关注通知。"}

做完这步，才到了能被模型理解的“干净语料”。

2.4 为什么说清洗决定后面 80% 的效果

很多人觉得清洗是浪费时间，直接拿原始数据跑接口也能出结果。但我的经验是，原始记录里混着一堆“情绪化发泄”“重复唠叨”“无意义寒暄”，这些内容进了模型，它会误以为这就是回答的格式。特别是在 Few-shot 场景下，模型对示例的模仿是全局性的，它会连你不想模仿的脏话、错别字、混乱标点一起学走。

打个比方：你把一份带着菜叶淤泥的食材直接下锅，炒出来的菜必然有土腥味。清洗就是把烂叶摘掉、泥沙冲掉，后面怎么调味都干净。这个环节在我所有项目里都花最多时间，但也是回报率最高的一步。

3. 最小可用方案：Few-shot 提示词模拟对话风格

3.1 从清洗结果里抽取高质量样本

Few-shot 方案的核心是样本质量。先按内容长度、是否自然完整跑一遍筛选，把那些“答非所问”“信息残缺”的对话对剔除。然后做频次统计，出现次数多的提问场景优先入选，比如“发货时间”“退换货规则”“发票开具”这类高频问题。

我一般抽 30 到 50 组。太少，模型学不到稳定的格式；太多，提示词动辄几百行，Token 成本也压不住。抽样时要保证覆盖高频场景，同时保留几组有个性的口语化回答，让人感觉“像个真人”。

选择标准记笔记：

• 回答结构完整：有开头称呼、有结论、有后续指引。
• 语气一致：短文为主，客服表达，不用复杂长难句。
• 没有歧义：不会引起二义性理解。
• 长度适中：每条回答控制在 30-80 字之间，方便模型复刻节奏。

3.2 把角色说明与示例写进 system prompt

Few-shot 不是单纯把示例堆在 system 里，角色设定要写明确。以“电商客服助手”为例，我会这样构造提示词：

你是一个电商售后客服助手。你的回答风格要求： 1. 先称呼客户为“您”，语气礼貌但简洁直接； 2. 不废话，不编造知识点； 3. 如果资料里没有答案，直接说“这个情况我们需要核实一下，请您稍等”，不要硬答； 4. 回答结尾给出明确的下一步动作。 下面是一些已被确认过的优秀问答示例，回答时尽量沿用这些示例的结构和语气： 用户：这个商品什么时候发货？ 客服：您好，商品会在付款后48小时内发出，节假日延迟会另行通知，您留意物流信息即可。 用户：我不小心把订单取消了，能恢复吗？ 客服：订单取消后无法直接恢复，建议您重新下单，如果需要优惠差价可以联系我们处理。

这里 system prompt 不仅是给模型“秀样例”，更是在做行为约束。很多人的 system 只有“你是客服”四个字，结果模型回答大段废话。把具体行为要求写进去，再用示例锚定，效果立刻不同。

3.3 完整调用 Python 示例

有了干净的样本和 system prompt，调用接口就很简单了。下面是完整可运行的入口：

import os from openai import OpenAI from dotenv import load_dotenv load_dotenv() client = OpenAI(api_key=os.getenv("OPENAI_API_KEY")) few_shot_examples = [ {"role": "user", "content": "这个商品什么时候发货？"}, {"role": "assistant", "content": "您好，商品会在付款后48小时内发出，节假日延迟会另行通知，您留意物流信息即可。"}, {"role": "user", "content": "我不小心把订单取消了，能恢复吗？"}, {"role": "assistant", "content": "订单取消后无法直接恢复，建议您重新下单，如果需要优惠差价可以联系我们处理。"}, ] def build_messages(user_input: str): system_prompt = ( "你是一个电商售后客服助手。你的回答风格要求：\n" "1. 先称呼客户为“您”，语气礼貌但简洁直接；\n" "2. 不废话，不编造知识点；\n" "3. 如果资料里没有答案，直接说“这个情况我们需要核实一下，请您稍等”，不要硬答。\n" "4. 回答结尾给出明确的下一步动作。\n\n" "下面是一些优秀问答示例：\n" ) messages = [{"role": "system", "content": system_prompt}] messages.extend(few_shot_examples) messages.append({"role": "user", "content": user_input}) return messages def chat_with_bot(user_input: str): resp = client.chat.completions.create( model="gpt-3.5-turbo", messages=build_messages(user_input), temperature=0.3, max_tokens=300, presence_penalty=0.2, frequency_penalty=0.3, ) return resp.choices[0].message.content.strip() if __name__ == "__main__": question = "你们发什么快递" print(chat_with_bot(question))

这个版本已经可以当聊天机器人用了，我一般直接套一个 Web 接口或者与本地的问答路由对接。

3.4 参数选择和调优思路

很多人问 temperature 到底该设多少。我的经验是：涉及业务风格固定、事实要求稳定的场景，temperature 设置在 0.2 到 0.4 之间。太低会变成复读机，回答非常干；太高就会出现“自由发挥”，把客服语气学歪。

几个我常用的参数值：

如果发现模型偶尔跳出“我是 OpenAI 的语言模型”这类自报家门的话，就在 system prompt 里直接声明“你是客服助手，不要介绍自己的模型身份”。下一版模型未必都遵守，但加了之后概率明显下降。

Few-shot 方案适合数据量小的起步阶段。它最大的边界在于提示词装不下太多内容，30 组示例在 4k 上下文窗口里占掉近一半。你还需要给当前会话的连续对话留空间，否则用户问几轮就超限。一旦出现这种“空间不够”的迹象，就该切到 RAG 方案了。

4. 进阶方案：对话记录构建 RAG 知识库

4.1 什么场景该上 RAG

对话记录有几千条、几万条时，Few-shot 塞不下，也不可能靠“多写点提示词”解决。这时候核心矛盾从“模型不知道风格”变成“模型不知道事实”。比如客户问“你们能不能发顺丰到付”，这个答案藏在半年前某个客服答复里，不检索根本找不出来。

RAG 的思路是用“检索 + 生成”替代“全量记忆”。先把所有对话记录切块、向量化，存进向量库；用户提问时，先把问题向量化，然后去向量库里召回最相关的若干片段；最后把这些片段作为参考资料，交给大模型组织回答。

这样做有两个直接好处：一是事实来源可追溯，每次回答都基于检索片段，而不是模型的模糊记忆；二是知识更新成本低，客服把新话术直接加进向量库，机器人立刻能用，不需要重训练。

4.2 把对话记录切块并写入向量库

切块这一步直接影响检索效果，我的经验是不要按固定字数硬切，尽量按“语义单元”切。客服对话里，一条“用户提问 + 客服回答”就是一个完整语义单元，把它作为一个块最自然。切块配合重叠能让每块的上下文更连贯。

用 OpenAI 的 embedding 接口做向量化：

from openai import OpenAI from dotenv import load_dotenv import chromadb load_dotenv() client = OpenAI() # 1. 从清洗后的结果中读入问答对 pairs = [ {"question": "这个订单什么时候发货", "answer": "您好，订单会在付款后48小时内发出，节假日延迟会另行通知，您留意物流信息即可。"}, ] # 2. 构造切块文本，问题+回答拼接 chunks = [f"问：{p['question']}\n答：{p['answer']}" for p in pairs] # 3. 批量向量化 embeddings = [] for chunk in chunks: resp = client.embeddings.create( model="text-embedding-ada-002", input=chunk, ) embeddings.append(resp.data[0].embedding) # 4. 写入 ChromaDB 本地向量库 chroma_client = chromadb.Client() collection = chroma_client.get_or_create_collection("customer_service_kb") ids = [f"doc_{i}" for i in range(len(chunks))] collection.add( ids=ids, documents=chunks, embeddings=embeddings, )

embedding 模型我用的是 text-embedding-ada-002，输出向量维度是 1536，对中文语义的支持在通用场景下够用。如果你手里的对话记录有大量行业黑话，不加说明就检索会不太准，这时候可以先做关键词扩充：把同义术语同时写入文档，例如把“退款”和“退钱”都写上。

4.3 检索增强回答的完整实现

查询阶段的核心是三步：问题向量化、相似度检索、构造提示词给生成模型。

def rag_answer(question: str, top_k: int = 4): # 第一步：问题向量化 query_resp = client.embeddings.create( model="text-embedding-ada-002", input=question, ) query_emb = query_resp.data[0].embedding # 第二步：检索最相关的对话片段 result = collection.query( query_embeddings=[query_emb], n_results=top_k, ) docs = result["documents"][0] # 第三步：拼接上下文，让模型基于资料回答 context = "\n\n---\n\n".join(docs) messages = [ { "role": "system", "content": ( "你是一个电商售后客服助手。回答时只能依据参考资料中的内容。" "如果参考资料里没有用户问题的答案，直接回复：这个情况我们需要核实一下，请您稍等。" "不要编造任何信息。回答语气简洁直接。" ), }, { "role": "user", "content": f"参考资料：\n{context}\n\n用户问题：{question}", }, ] resp = client.chat.completions.create( model="gpt-3.5-turbo", messages=messages, temperature=0.3, max_tokens=300, ) return resp.choices[0].message.content.strip()

检索结果可能包含多条，但它们不是按时间顺序排列的，而是按相似度排序。在拼接 context 时，把相似度最高的放前面，模型会更重视前面内容。top_k 我通常设 4，太少信息不足；太多会引入不相关文本，反而让模型抓不住重点。

4.4 切块与检索调优的实操方向

RAG 跑通容易，调好才是难点。我最常碰到的两个问题是“答案找不到”和“答案找错”。前者是召回率低，后者是精确率低。

切块太大，一个块里混着多个问题的答案，检索时整体相似度被拉低，导致该命中的没命中。切块太小，答案只有半句，上下文不完整，模型回答支离破碎。我的做法是：先按“一个问答对”切块，长度限制在 200 到 400 字；如果单个问答对过长，再按语义边界切成多个小段落，尽量保持“问+答”成组出现。

另一个有效手段是混合检索。很多内部知识里包含精确编码，比如“退款期限 7 天”“售后电话 400”，光靠向量相似度不够精准。我会在 ChromaDB 之外，再跑一遍关键词倒排索引，合并命中结果后去重。这样既照顾语义相似，又照顾精确匹配。

调优过程中记得把“检索到了但没答好”和“根本检索到”分开记录。我习惯在每个请求日志里打印检索到的文档 id 和相似度，跑完一批测试数据回看，能快速定位到底是提示词问题还是切块问题。

5. 常见问题与排查技巧实录

5.1 接口报错速查

OpenAI 接口看着简单，真跑起来报错类型也就那几种。我把高频错误整理成一张速查表：

最常出现在新手身上的问题是 messages 结构错误。比如忘记把 system 角色放前面，或者 messages 里传了非字符串字段。解决很简单，统一按[{"role": "...", "content": "..."}]这个结构构造。

5.2 效果问题：答非所问、风格不像、幻觉

效果不对时，不要急着骂模型，先按从数据到提示词的顺序排查。

答非所问，先看检索环节。检查 top_k 是不是太低了，尤其当知识库里某个话题的问答分布在多个小块里，只取前 3 条可能漏掉关键答案。其次看切块方式，如果一个块前半段是 A 问题、后半段是 B 问题，检索时相似度会被稀释，改为按“问答对”切块通常能好转。

风格不像，大概率是 Few-shot 样本数量不足或质量不均。最少也得 20 组，且要覆盖高频场景。如果已经用了 RAG，记得把风格指令也放进 system prompt，不要只在参考资料里体现语气。模型拿到的资料是“内容”，风格指令必须是明确要求。

幻觉问题，核心是约束不够。我要求生成模型必须“只依据参考资料回答，资料中没有就说不知道”。语气可以再硬化一点：“宁可拒绝回答，也不要编造信息。”实际测试里，加这一条能让幻觉率明显下降。不要期待模型自己具备“不知道”的自觉，你不说，它就硬编。

5.3 成本和效率的实操心得

服务上线后最直观的问题就是账单。我分享三个压成本的办法，都是实际验证过的。

第一，做问答缓存。客服场景里用户问题重复率非常高，前 20 个高频问题可能占全部提问的一半。把这些问题和答案固化到一个缓存表，命中就直接返回，不走模型接口。这能省下相当可观的费用。

第二，会话裁剪。聊天机器人多轮对话时，messages 会越积越长，成本呈线性上升。我的策略是只保留最近 10 轮原始消息，更早的内容用一个“前文摘要”替身放在 system 里，模型能理解大概背景，又不会撑爆上下文。

第三，离线 batch。如果要做知识库初始化、批量 embedding，用并发请求时注意控频。OpenAI 的速率限制是账户维度，跑太猛会触发限流。我用 asyncio 控制并发在 10 左右，配合重试机制，几千条文本二十分钟内能跑完。

最后分享一个我在实际项目里的体会：基于对话记录做聊天机器人，真正拉开差距的不是调参技巧，而是对数据的理解。我先跑通 Few-shot 验证风格，再切 RAG 承载知识，每走一步都能明显看到瓶颈在哪。清洗数据那一步花掉的时间远比调模型多，但正是这些时间决定了机器人是“像客服”还是“只是能说话”。你手里的对话记录是金矿，但挖出来还得淘洗几遍，才敢给用户端出去。