“记住谁发明了钢琴键背景智能体”这个题目乍看很像一个闲聊玩具实际上它背后是一套完整的智能体工程问题如何让 AI 在回答“谁发明了钢琴键”这类背景知识问题时既做到事实准确又能记住用户之前问过什么、偏好什么并且可以接到自己的应用里当接口用。这篇文章就用“谁发明了钢琴键”作为贯穿场景拆解一个带知识库检索和会话记忆的知识问答型智能体怎么搭。重点覆盖技术选型、本地/云端部署思路、多轮记忆测试、API 封装和批量任务验证。如果你是刚接触智能体开发或者想在 Dify、Coze 和自研 Python 方案之间做个比较这篇文章可以直接收藏。先给结论这类智能体不需要你从零训练模型核心是把大模型 API、向量知识库、会话记忆三件事拼起来。门槛不高一台普通开发机就能跑真正的难点在知识库质量、记忆策略和接口稳定性。1. 核心能力速览能力项说明项目类型知识记忆型问答智能体支持背景知识查询与多轮对话记忆核心功能知识库检索增强RAG、会话级长期记忆、问答 API 服务、批量测试典型问题示例“谁发明了钢琴键”“现代钢琴和羽管键琴的区别”“我之前问过的钢琴历史问题有哪些”技术路线大模型 API 向量数据库 会话记忆模块或直接使用 Dify/Coze 低代码平台硬件需求CPU 即可完成工程搭建推理阶段取决于大模型 API 或本地模型部署方式显存占用如果使用云端大模型 API本机基本不占显存如果本地部署开源模型显存需按实际模型确定启动方式Python 后端启动 / Dify 应用发布 / Coze Bot 发布是否支持 API支持可封装为 REST API 供其他系统调用是否支持批量任务支持可通过脚本批量写入知识库或批量测试问答质量适合读者正在学习智能体开发、想做知识问答机器人、需要给现有业务加 AI 问答能力的人从材料看“记住谁发明了钢琴键背景智能体”不是一个需要固定显卡才能跑的重型项目而是可以通过 API 方式快速实现的智能体应用。它不需要你懂复杂的模型训练重点是理解“记忆”和“知识检索”怎么接进对话流程。2. 适用场景与使用边界2.1 适合做什么这类智能体的核心使用场景是“垂直知识问答 用户偏好记忆”。比如音乐教育辅助回答钢琴、键盘乐器、作曲家背景等问题。历史知识问答围绕特定历史人物、事件、乐器演变做科普。企业内部知识库把产品文档、操作手册接入智能体让员工直接提问。个性化推荐根据用户多次提问记录记住用户偏好在后续对话中主动关联。用“谁发明了钢琴键”举例正确做法是让智能体先检索知识库再结合大模型的表达能力生成答案。知识库准备好“现代钢琴由意大利人巴托罗密欧·克里斯托弗里约 1700 年发明钢琴键盘布局继承自更早的键盘乐器”这类权威内容智能体回答时就不会只靠大模型的“记忆”编答案。2.2 不适合做什么不适合回答知识库覆盖以外的开放问题否则会退化成一个普通大模型聊天框。不适合在缺少用户授权的情况下采集、保存个人敏感信息。不适合把单一来源的网络资料直接当事实用尤其是涉及历史人物、版权、医学、法律等领域时需要人工复核。2.3 合规边界必须强调的是智能体“记住”用户问题不等于可以任意收集用户信息。保存对话记忆前要明确告知用户并设置会话清理机制。如果知识库里的资料来自书籍、论文、付费课程需要确认版权后使用。涉及真实人物、真实事件的背景知识回答内容要做好事实核查和免责提示。3. 技术方案选型搭建这个智能体有三类常见路线取舍点不一样。3.1 路线一Dify 低代码平台Dify 是目前国内开发者使用较多的智能体平台支持可视化编排、知识库上传、Agent 工具调用、工作流设计和 API 发布。适合想快速验证“知识问答 记忆”的团队。优点不需要写太多代码。自带会话记忆管理。知识库上传后自动切片、向量化。可以发布为 API供外部系统调用。缺点平台本身有一定学习成本。深度定制受平台限制。3.2 路线二Coze 扣子平台Coze 的优点是 Bot 一键发布到多种渠道内置插件和知识库能力也有记忆变量功能。适合做面向 C 端用户的对话机器人。3.3 路线三自研 Python 轻量方案自研方案更灵活适合需要深度控制检索逻辑、记忆策略和接口格式的开发者。核心组件包括大模型 API负责生成最终回答。Embedding 模型把知识点转成向量。向量数据库存储和检索知识片段。记忆模块按会话 ID 保存对话历史。Web 框架用 FastAPI 或 Flask 封装 HTTP 接口。本文后续以自研方案为主线因为它的实现过程最能说明智能体内部发生了什么。如果你不想写代码可以直接跳到第 5 节看 Dify 搭建对照思路。4. 环境准备与前置条件自研方案的环境准备并不复杂一台能联网的电脑即可操作系统不限。以下是最小依赖清单。4.1 基础环境# Python 3.9 及以上版本建议 python --version4.2 安装 Python 依赖pip install langchain langchain-community chromadb fastapi uvicorn requests这里说明一下上述包是智能体搭建中常见的工具库实际安装版本以 PyPI 当前发布为准。如果你已经有虚拟环境建议新建一个独立环境避免和已有项目冲突。python -m venv agent_env source agent_env/bin/activate # Windows 下使用 agent_env\Scripts\activate4.3 获取大模型 API Key需要一个大模型 API 服务。可以是商业 API也可以是本地部署的开源模型接口。关键是要支持 OpenAI 兼容的 Chat 接口格式这样 LangChain 接入最稳定。获取 Key 后在环境变量里配置export LLM_API_KEY你的API Key export LLM_BASE_URLhttps://your-llm-endpoint.example.com/v1 export LLM_MODELyour-model-name没有 API Key 时整个流程无法真正跑通这一步不能跳过。4.4 准备知识库文件准备几份关于钢琴发明历史的文本资料保存为 txt 或 md 格式。示例内容现代钢琴由意大利人巴托罗密欧·克里斯托弗里Bartolomeo Cristofori约1700年在佛罗伦萨发明。 他设计的击弦机构让演奏者可以通过按键力度控制音量强弱因此被视为现代钢琴的发明者。 钢琴键盘中的黑白键布局则继承自更早的键盘乐器如羽管键琴和管风琴。 钢琴键的演变经历了从管风琴键盘、羽管键琴键盘到现代钢琴键盘的过程。这份材料会进入向量库智能体回答“谁发明了钢琴键”时会优先参考这些内容。5. 安装部署与启动方式5.1 知识库索引构建先编写一个脚本把知识文档切片并写入向量数据库。本文使用 Chroma 作为向量库数据默认存储在本地目录./chroma_db。from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_core.embeddings import Embeddings # 假设你已经配置好了 Embedding 模型实例 # 这里用 llama_index 或 LangChain 自带的 OpenAI Embedding 都行 # 下面以 OpenAI 兼容接口为例 from langchain_openai import OpenAIEmbeddings embeddings OpenAIEmbeddings( modeltext-embedding-3-small, openai_api_keyLLM_API_KEY, openai_api_baseLLM_BASE_URL ) # 加载文档 loader TextLoader(./knowledge/piano_history.txt, encodingutf-8) documents loader.load() # 切片 splitter RecursiveCharacterTextSplitter(chunk_size300, chunk_overlap50) docs splitter.split_documents(documents) # 写入向量数据库 vector_store Chroma.from_documents( docs, embeddings, persist_directory./chroma_db ) print(f知识库已写入共 {len(docs)} 个片段)注意OpenAIEmbeddings是否可用取决于你的 Embedding 服务和 LangChain 版本。如果接口不兼容可以换成其他 Embedding 组件或本地模型。5.2 实现检索增强问答核心逻辑分三步接收用户问题 - 从向量库检索相关知识片段 - 把片段和问题一起交给大模型生成回答。from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI # 检索器 retriever vector_store.as_retriever(search_kwargs{k: 3}) # 提示词 prompt ChatPromptTemplate.from_messages([ (system, 你是背景知识问答助手。回答必须基于以下资料资料中没有的信息要明确说不知道。资料{context}), (human, {question}) ]) # 大模型 llm ChatOpenAI( modelLLM_MODEL, openai_api_keyLLM_API_KEY, openai_api_baseLLM_BASE_URL, temperature0.2 ) def ask(question): docs retriever.get_relevant_documents(question) context \n.join([d.page_content for d in docs]) chain prompt | llm result chain.invoke({context: context, question: question}) return result.content, docs这段代码跑通之后你已经有一个最基本的 RAG 智能体了。接下来要处理“记住”的问题。5.3 会话记忆模块“记住”不能只靠大模型上下文窗口硬扛建议按会话 ID 把多轮对话保存起来并在构造提示词时把近期对话记录一并放入。import json import os from datetime import datetime MEMORY_DIR ./memory def save_message(session_id, role, content): os.makedirs(MEMORY_DIR, exist_okTrue) path os.path.join(MEMORY_DIR, f{session_id}.jsonl) record { role: role, content: content, time: datetime.now().isoformat() } with open(path, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n) def load_history(session_id, max_rounds10): path os.path.join(MEMORY_DIR, f{session_id}.jsonl) if not os.path.exists(path): return [] history [] with open(path, r, encodingutf-8) as f: for line in f: history.append(json.loads(line.strip())) return history[-max_rounds:]生成回答时把历史记录拼进 messages。这样用户问过“我喜欢巴洛克时期的键盘音乐”之后再问“这句乐章的力度应该怎么处理”智能体才能带上上下文回答。5.4 Dify 搭建对照如果你不想写 PythonDify 上的搭建更直观在 Dify 控制台新建“聊天助手”应用。在“知识库”菜单上传钢琴历史文档。在提示词编排里加入知识库检索节点。开启“对话记忆”功能。发布应用后在“API 访问”页面拿到 API Key 和接口地址。Dify 的优点是记忆和检索都由平台托管部署成本低。适合企业做内部知识问答也适合个人快速验证智能体效果。6. 功能测试与效果验证6.1 测试一基础知识问答调用刚才的ask函数输入问题answer, docs ask(谁发明了钢琴键) print(answer)预期结果是回答“现代钢琴的发明者是巴托罗密欧·克里斯托弗里约 1700 年发明钢琴键盘布局继承自更早的键盘乐器”并且知识库中检索出对应的文档片段。判断标准回答内容能落到知识库资料上。知识库没有覆盖的问题能够坦诚回答“资料中没有提到”。6.2 测试二多轮记忆验证第一轮save_message(user-001, user, 我喜欢研究巴洛克时期的键盘音乐) ask_with_memory(user-001, 记住这个偏好)第二轮save_message(user-001, user, 刚才我说过我喜欢什么时期的音乐) answer ask_with_memory(user-001, 我刚才说过什么偏好) print(answer)预期结果第二轮的答案能回忆起“巴洛克时期键盘音乐”这个信息。判断标准回答中明确提到第一轮对话里的偏好。如果不开启记忆模块第二轮回答会完全丢失上下文。6.3 测试三知识边界测试故意问一个知识库覆盖不到的问题answer, _ ask(请告诉我梵蒂冈图书馆藏琴键的具体参数) print(answer)预期结果智能体应指出资料库中没有相关信息而不是强行编造。判断标准回答包含“根据现有资料无法确认”或类似表述。没有生成看似合理但毫无依据的数字和细节。6.4 测试四连续追问继续追问answer, _ ask(那钢琴键和羽管键琴的键盘手感有什么不同) print(answer)预期结果回答会结合知识库内容说明击弦机构和拨弦机构的差异。7. 接口 API 与批量任务7.1 用 FastAPI 封装问答接口做一个可供外部系统调用的接口实际开发中很有必要。下面是通用示例from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class ChatRequest(BaseModel): message: str session_id: str default class ChatResponse(BaseModel): reply: str session_id: str from_memory: bool False app.post(/api/chat, response_modelChatResponse) def chat(req: ChatRequest): # 调用前面实现的 ask 和记忆函数 history load_history(req.session_id) # 这里简化处理实际应把 history 带入 LLM messages reply, _ ask_with_history(req.message, req.session_id) save_message(req.session_id, user, req.message) save_message(req.session_id, assistant, reply) return ChatResponse(replyreply, session_idreq.session_id)启动服务uvicorn main:app --host 127.0.0.1 --port 80007.2 用 curl 验证接口curl -X POST http://127.0.0.1:8000/api/chat \ -H Content-Type: application/json \ -d {message: 谁发明了钢琴键, session_id: test-001}返回结果示例{ reply: 现代钢琴由意大利人巴托罗密欧·克里斯托弗里约1700年发明键盘布局继承自更早的键盘乐器。, session_id: test-001, from_memory: false }7.3 批量评测脚本批量任务的意义在于当知识库更新后要用同一组问题反复验证回答质量。写一个批量测试脚本import requests questions [ 谁发明了钢琴键, 钢琴键是什么时候出现的, 现代钢琴和羽管键琴有什么区别, 我不应该知道的信息是什么 ] url http://127.0.0.1:8000/api/chat for idx, q in enumerate(questions): resp requests.post( url, json{message: q, session_id: feval-{idx}}, timeout30 ) data resp.json() print(f问题{q}) print(f回答{data.get(reply)}) print(- * 40)批量任务建议加两个机制日志记录每个问题的回答都写入文件方便对比版本。失败重试接口超时或返回异常时间隔 2 秒重试一次。8. 资源占用与性能观察这类智能体的资源消耗集中在三块Embedding 计算、向量检索、大模型推理。如果使用云端大模型 API本机资源占用很低主要消耗在知识库切片和向量化阶段。你可以打开任务管理器观察内存Python 进程通常占用 200MB 到 1GB 不等取决于知识库切片大小和向量库加载情况。磁盘Chroma 向量库默认存在本地目录几 MB 到几十 MB 级别。显存本机不跑模型时基本不占用显存零。如果改用本地开源模型做推理CPU 方案响应慢GPU 方案需要根据模型参数量决定显存。例如 7B 量化模型一般需要 6GB 左右显存13B 模型通常需要 12GB 以上。这个数字仅供参考实际占用取决于推理框架、量化精度和上下文长度。性能观察建议首次提问存在向量库加载初始化耗时。多轮记忆开启后请求体会变长响应时间会上升。检索到的片段数量 k 值越大上下文越长回答质量不一定线性提升但延迟一定增加。建议在接口服务里加耗时日志import time start time.time() reply, _ ask(req.message, req.session_id) print(f耗时{time.time() - start:.2f}s)9. 常见问题与排查方法问题现象可能原因排查方式解决方案回答内容不在知识库范围内知识库文档未正确写入检查向量库目录是否存在切片数据重建知识库索引多轮对话记不住上文会话 ID 不一致或记忆未加载检查请求里的 session_id 和 memory 文件统一 session_id修改记忆加载逻辑API 返回 401 或 403API Key 无效或权限不足在控制台检查 Key 状态更换 Key确认模型权限接口响应超时大模型推理时间过长或网络慢查看后端耗时日志降低上下文长度使用流式输出向量库检索结果不相关切片粒度过大或文本清洗不充分打印检索片段内容调小 chunk_size清洗文档格式批量任务卡住未设置超时接口并发能力不足检查是否有限流机制增加超时参数控制并发数本地模型启动后提示显存不足模型参数量超过显存容量查看 GPU 占用换更小模型或量化版本最常踩的坑有三个第一Embedding 模型和 Chat 模型接口不兼容导致向量化失败第二session_id 每次请求都换记忆完全失效第三知识库文档格式不规范PDF 扫描件、图片检索质量很差。前两个通过统一配置可以解决第三个需要先做文本清洗再入库。10. 最佳实践与使用建议10.1 工程落地建议第一次先小参数测试不要一上来就灌上千个文档。先用 5 到 10 个片段跑通链路再逐步扩充。保持一套最小可运行配置固定的模型名、固定的 Embedding 名称、固定的向量库目录遇到问题能快速回退。模型文件、知识库原始文档、清洗后文本、向量库目录、输出结果分目录管理不要全部堆在一起。批量任务必须加日志和失败重试否则知识库更新后很难定位是检索问题还是生成问题。接口服务要限制访问范围如果只在内网使用绑定 127.0.0.1 或内网 IP不要直接暴露公网。10.2 知识库内容规范尽量使用权威来源例如教材、官方文档、学术资料。同一份知识文档保持单一主题不要在同一个文件里混入多个不相关知识点。定期更新内容并重建索引避免旧资料长期占坑。10.3 合规提醒涉及真实历史人物和音乐作品背景时建议在回答中标注“资料来源于某某知识库”。如果使用公开素材要注意版权。如果智能体会保存用户对话记录必须在产品说明中告知用户并提供“清除记忆”功能。11. 总结与下一步这个“记住谁发明了钢琴键背景智能体”最值得尝试的点是把知识检索、会话记忆和 API 服务三件事打通。它能回答“谁发明了钢琴键”这类事实问题也能记住用户的提问偏好后续无论是扩展成音乐教育助手还是改成企业内部知识问答机器人都只需要替换知识库内容不用改主流程。最先要验证的功能是基础检索问答确认知识库能准确召回文档然后再测多轮记忆最后再封装 API 和批量任务。最容易踩的坑是接口配置不一致建议写一个 config 文件统一管理模型名、API 地址和向量库路径。下一步可以考虑给智能体增加“用户身份记忆”功能或者接入工作流平台把它变成一个可被外部 Agent 调用的子工具。如果跑通了这套流程你基本就掌握了目前主流智能体平台背后的核心逻辑知识库做依据记忆做上下文大模型做表达。建议收藏备用。
“记住谁发明了钢琴键背景智能体”这个题目乍看很像一个闲聊玩具实际上它背后是一套完整的智能体工程问题如何让 AI 在回答“谁发明了钢琴键”这类背景知识问题时既做到事实准确又能记住用户之前问过什么、偏好什么并且可以接到自己的应用里当接口用。这篇文章就用“谁发明了钢琴键”作为贯穿场景拆解一个带知识库检索和会话记忆的知识问答型智能体怎么搭。重点覆盖技术选型、本地/云端部署思路、多轮记忆测试、API 封装和批量任务验证。如果你是刚接触智能体开发或者想在 Dify、Coze 和自研 Python 方案之间做个比较这篇文章可以直接收藏。先给结论这类智能体不需要你从零训练模型核心是把大模型 API、向量知识库、会话记忆三件事拼起来。门槛不高一台普通开发机就能跑真正的难点在知识库质量、记忆策略和接口稳定性。1. 核心能力速览能力项说明项目类型知识记忆型问答智能体支持背景知识查询与多轮对话记忆核心功能知识库检索增强RAG、会话级长期记忆、问答 API 服务、批量测试典型问题示例“谁发明了钢琴键”“现代钢琴和羽管键琴的区别”“我之前问过的钢琴历史问题有哪些”技术路线大模型 API 向量数据库 会话记忆模块或直接使用 Dify/Coze 低代码平台硬件需求CPU 即可完成工程搭建推理阶段取决于大模型 API 或本地模型部署方式显存占用如果使用云端大模型 API本机基本不占显存如果本地部署开源模型显存需按实际模型确定启动方式Python 后端启动 / Dify 应用发布 / Coze Bot 发布是否支持 API支持可封装为 REST API 供其他系统调用是否支持批量任务支持可通过脚本批量写入知识库或批量测试问答质量适合读者正在学习智能体开发、想做知识问答机器人、需要给现有业务加 AI 问答能力的人从材料看“记住谁发明了钢琴键背景智能体”不是一个需要固定显卡才能跑的重型项目而是可以通过 API 方式快速实现的智能体应用。它不需要你懂复杂的模型训练重点是理解“记忆”和“知识检索”怎么接进对话流程。2. 适用场景与使用边界2.1 适合做什么这类智能体的核心使用场景是“垂直知识问答 用户偏好记忆”。比如音乐教育辅助回答钢琴、键盘乐器、作曲家背景等问题。历史知识问答围绕特定历史人物、事件、乐器演变做科普。企业内部知识库把产品文档、操作手册接入智能体让员工直接提问。个性化推荐根据用户多次提问记录记住用户偏好在后续对话中主动关联。用“谁发明了钢琴键”举例正确做法是让智能体先检索知识库再结合大模型的表达能力生成答案。知识库准备好“现代钢琴由意大利人巴托罗密欧·克里斯托弗里约 1700 年发明钢琴键盘布局继承自更早的键盘乐器”这类权威内容智能体回答时就不会只靠大模型的“记忆”编答案。2.2 不适合做什么不适合回答知识库覆盖以外的开放问题否则会退化成一个普通大模型聊天框。不适合在缺少用户授权的情况下采集、保存个人敏感信息。不适合把单一来源的网络资料直接当事实用尤其是涉及历史人物、版权、医学、法律等领域时需要人工复核。2.3 合规边界必须强调的是智能体“记住”用户问题不等于可以任意收集用户信息。保存对话记忆前要明确告知用户并设置会话清理机制。如果知识库里的资料来自书籍、论文、付费课程需要确认版权后使用。涉及真实人物、真实事件的背景知识回答内容要做好事实核查和免责提示。3. 技术方案选型搭建这个智能体有三类常见路线取舍点不一样。3.1 路线一Dify 低代码平台Dify 是目前国内开发者使用较多的智能体平台支持可视化编排、知识库上传、Agent 工具调用、工作流设计和 API 发布。适合想快速验证“知识问答 记忆”的团队。优点不需要写太多代码。自带会话记忆管理。知识库上传后自动切片、向量化。可以发布为 API供外部系统调用。缺点平台本身有一定学习成本。深度定制受平台限制。3.2 路线二Coze 扣子平台Coze 的优点是 Bot 一键发布到多种渠道内置插件和知识库能力也有记忆变量功能。适合做面向 C 端用户的对话机器人。3.3 路线三自研 Python 轻量方案自研方案更灵活适合需要深度控制检索逻辑、记忆策略和接口格式的开发者。核心组件包括大模型 API负责生成最终回答。Embedding 模型把知识点转成向量。向量数据库存储和检索知识片段。记忆模块按会话 ID 保存对话历史。Web 框架用 FastAPI 或 Flask 封装 HTTP 接口。本文后续以自研方案为主线因为它的实现过程最能说明智能体内部发生了什么。如果你不想写代码可以直接跳到第 5 节看 Dify 搭建对照思路。4. 环境准备与前置条件自研方案的环境准备并不复杂一台能联网的电脑即可操作系统不限。以下是最小依赖清单。4.1 基础环境# Python 3.9 及以上版本建议 python --version4.2 安装 Python 依赖pip install langchain langchain-community chromadb fastapi uvicorn requests这里说明一下上述包是智能体搭建中常见的工具库实际安装版本以 PyPI 当前发布为准。如果你已经有虚拟环境建议新建一个独立环境避免和已有项目冲突。python -m venv agent_env source agent_env/bin/activate # Windows 下使用 agent_env\Scripts\activate4.3 获取大模型 API Key需要一个大模型 API 服务。可以是商业 API也可以是本地部署的开源模型接口。关键是要支持 OpenAI 兼容的 Chat 接口格式这样 LangChain 接入最稳定。获取 Key 后在环境变量里配置export LLM_API_KEY你的API Key export LLM_BASE_URLhttps://your-llm-endpoint.example.com/v1 export LLM_MODELyour-model-name没有 API Key 时整个流程无法真正跑通这一步不能跳过。4.4 准备知识库文件准备几份关于钢琴发明历史的文本资料保存为 txt 或 md 格式。示例内容现代钢琴由意大利人巴托罗密欧·克里斯托弗里Bartolomeo Cristofori约1700年在佛罗伦萨发明。 他设计的击弦机构让演奏者可以通过按键力度控制音量强弱因此被视为现代钢琴的发明者。 钢琴键盘中的黑白键布局则继承自更早的键盘乐器如羽管键琴和管风琴。 钢琴键的演变经历了从管风琴键盘、羽管键琴键盘到现代钢琴键盘的过程。这份材料会进入向量库智能体回答“谁发明了钢琴键”时会优先参考这些内容。5. 安装部署与启动方式5.1 知识库索引构建先编写一个脚本把知识文档切片并写入向量数据库。本文使用 Chroma 作为向量库数据默认存储在本地目录./chroma_db。from langchain_community.document_loaders import TextLoader from langchain_text_splitters import RecursiveCharacterTextSplitter from langchain_community.vectorstores import Chroma from langchain_core.embeddings import Embeddings # 假设你已经配置好了 Embedding 模型实例 # 这里用 llama_index 或 LangChain 自带的 OpenAI Embedding 都行 # 下面以 OpenAI 兼容接口为例 from langchain_openai import OpenAIEmbeddings embeddings OpenAIEmbeddings( modeltext-embedding-3-small, openai_api_keyLLM_API_KEY, openai_api_baseLLM_BASE_URL ) # 加载文档 loader TextLoader(./knowledge/piano_history.txt, encodingutf-8) documents loader.load() # 切片 splitter RecursiveCharacterTextSplitter(chunk_size300, chunk_overlap50) docs splitter.split_documents(documents) # 写入向量数据库 vector_store Chroma.from_documents( docs, embeddings, persist_directory./chroma_db ) print(f知识库已写入共 {len(docs)} 个片段)注意OpenAIEmbeddings是否可用取决于你的 Embedding 服务和 LangChain 版本。如果接口不兼容可以换成其他 Embedding 组件或本地模型。5.2 实现检索增强问答核心逻辑分三步接收用户问题 - 从向量库检索相关知识片段 - 把片段和问题一起交给大模型生成回答。from langchain_core.prompts import ChatPromptTemplate from langchain_openai import ChatOpenAI # 检索器 retriever vector_store.as_retriever(search_kwargs{k: 3}) # 提示词 prompt ChatPromptTemplate.from_messages([ (system, 你是背景知识问答助手。回答必须基于以下资料资料中没有的信息要明确说不知道。资料{context}), (human, {question}) ]) # 大模型 llm ChatOpenAI( modelLLM_MODEL, openai_api_keyLLM_API_KEY, openai_api_baseLLM_BASE_URL, temperature0.2 ) def ask(question): docs retriever.get_relevant_documents(question) context \n.join([d.page_content for d in docs]) chain prompt | llm result chain.invoke({context: context, question: question}) return result.content, docs这段代码跑通之后你已经有一个最基本的 RAG 智能体了。接下来要处理“记住”的问题。5.3 会话记忆模块“记住”不能只靠大模型上下文窗口硬扛建议按会话 ID 把多轮对话保存起来并在构造提示词时把近期对话记录一并放入。import json import os from datetime import datetime MEMORY_DIR ./memory def save_message(session_id, role, content): os.makedirs(MEMORY_DIR, exist_okTrue) path os.path.join(MEMORY_DIR, f{session_id}.jsonl) record { role: role, content: content, time: datetime.now().isoformat() } with open(path, a, encodingutf-8) as f: f.write(json.dumps(record, ensure_asciiFalse) \n) def load_history(session_id, max_rounds10): path os.path.join(MEMORY_DIR, f{session_id}.jsonl) if not os.path.exists(path): return [] history [] with open(path, r, encodingutf-8) as f: for line in f: history.append(json.loads(line.strip())) return history[-max_rounds:]生成回答时把历史记录拼进 messages。这样用户问过“我喜欢巴洛克时期的键盘音乐”之后再问“这句乐章的力度应该怎么处理”智能体才能带上上下文回答。5.4 Dify 搭建对照如果你不想写 PythonDify 上的搭建更直观在 Dify 控制台新建“聊天助手”应用。在“知识库”菜单上传钢琴历史文档。在提示词编排里加入知识库检索节点。开启“对话记忆”功能。发布应用后在“API 访问”页面拿到 API Key 和接口地址。Dify 的优点是记忆和检索都由平台托管部署成本低。适合企业做内部知识问答也适合个人快速验证智能体效果。6. 功能测试与效果验证6.1 测试一基础知识问答调用刚才的ask函数输入问题answer, docs ask(谁发明了钢琴键) print(answer)预期结果是回答“现代钢琴的发明者是巴托罗密欧·克里斯托弗里约 1700 年发明钢琴键盘布局继承自更早的键盘乐器”并且知识库中检索出对应的文档片段。判断标准回答内容能落到知识库资料上。知识库没有覆盖的问题能够坦诚回答“资料中没有提到”。6.2 测试二多轮记忆验证第一轮save_message(user-001, user, 我喜欢研究巴洛克时期的键盘音乐) ask_with_memory(user-001, 记住这个偏好)第二轮save_message(user-001, user, 刚才我说过我喜欢什么时期的音乐) answer ask_with_memory(user-001, 我刚才说过什么偏好) print(answer)预期结果第二轮的答案能回忆起“巴洛克时期键盘音乐”这个信息。判断标准回答中明确提到第一轮对话里的偏好。如果不开启记忆模块第二轮回答会完全丢失上下文。6.3 测试三知识边界测试故意问一个知识库覆盖不到的问题answer, _ ask(请告诉我梵蒂冈图书馆藏琴键的具体参数) print(answer)预期结果智能体应指出资料库中没有相关信息而不是强行编造。判断标准回答包含“根据现有资料无法确认”或类似表述。没有生成看似合理但毫无依据的数字和细节。6.4 测试四连续追问继续追问answer, _ ask(那钢琴键和羽管键琴的键盘手感有什么不同) print(answer)预期结果回答会结合知识库内容说明击弦机构和拨弦机构的差异。7. 接口 API 与批量任务7.1 用 FastAPI 封装问答接口做一个可供外部系统调用的接口实际开发中很有必要。下面是通用示例from fastapi import FastAPI from pydantic import BaseModel app FastAPI() class ChatRequest(BaseModel): message: str session_id: str default class ChatResponse(BaseModel): reply: str session_id: str from_memory: bool False app.post(/api/chat, response_modelChatResponse) def chat(req: ChatRequest): # 调用前面实现的 ask 和记忆函数 history load_history(req.session_id) # 这里简化处理实际应把 history 带入 LLM messages reply, _ ask_with_history(req.message, req.session_id) save_message(req.session_id, user, req.message) save_message(req.session_id, assistant, reply) return ChatResponse(replyreply, session_idreq.session_id)启动服务uvicorn main:app --host 127.0.0.1 --port 80007.2 用 curl 验证接口curl -X POST http://127.0.0.1:8000/api/chat \ -H Content-Type: application/json \ -d {message: 谁发明了钢琴键, session_id: test-001}返回结果示例{ reply: 现代钢琴由意大利人巴托罗密欧·克里斯托弗里约1700年发明键盘布局继承自更早的键盘乐器。, session_id: test-001, from_memory: false }7.3 批量评测脚本批量任务的意义在于当知识库更新后要用同一组问题反复验证回答质量。写一个批量测试脚本import requests questions [ 谁发明了钢琴键, 钢琴键是什么时候出现的, 现代钢琴和羽管键琴有什么区别, 我不应该知道的信息是什么 ] url http://127.0.0.1:8000/api/chat for idx, q in enumerate(questions): resp requests.post( url, json{message: q, session_id: feval-{idx}}, timeout30 ) data resp.json() print(f问题{q}) print(f回答{data.get(reply)}) print(- * 40)批量任务建议加两个机制日志记录每个问题的回答都写入文件方便对比版本。失败重试接口超时或返回异常时间隔 2 秒重试一次。8. 资源占用与性能观察这类智能体的资源消耗集中在三块Embedding 计算、向量检索、大模型推理。如果使用云端大模型 API本机资源占用很低主要消耗在知识库切片和向量化阶段。你可以打开任务管理器观察内存Python 进程通常占用 200MB 到 1GB 不等取决于知识库切片大小和向量库加载情况。磁盘Chroma 向量库默认存在本地目录几 MB 到几十 MB 级别。显存本机不跑模型时基本不占用显存零。如果改用本地开源模型做推理CPU 方案响应慢GPU 方案需要根据模型参数量决定显存。例如 7B 量化模型一般需要 6GB 左右显存13B 模型通常需要 12GB 以上。这个数字仅供参考实际占用取决于推理框架、量化精度和上下文长度。性能观察建议首次提问存在向量库加载初始化耗时。多轮记忆开启后请求体会变长响应时间会上升。检索到的片段数量 k 值越大上下文越长回答质量不一定线性提升但延迟一定增加。建议在接口服务里加耗时日志import time start time.time() reply, _ ask(req.message, req.session_id) print(f耗时{time.time() - start:.2f}s)9. 常见问题与排查方法问题现象可能原因排查方式解决方案回答内容不在知识库范围内知识库文档未正确写入检查向量库目录是否存在切片数据重建知识库索引多轮对话记不住上文会话 ID 不一致或记忆未加载检查请求里的 session_id 和 memory 文件统一 session_id修改记忆加载逻辑API 返回 401 或 403API Key 无效或权限不足在控制台检查 Key 状态更换 Key确认模型权限接口响应超时大模型推理时间过长或网络慢查看后端耗时日志降低上下文长度使用流式输出向量库检索结果不相关切片粒度过大或文本清洗不充分打印检索片段内容调小 chunk_size清洗文档格式批量任务卡住未设置超时接口并发能力不足检查是否有限流机制增加超时参数控制并发数本地模型启动后提示显存不足模型参数量超过显存容量查看 GPU 占用换更小模型或量化版本最常踩的坑有三个第一Embedding 模型和 Chat 模型接口不兼容导致向量化失败第二session_id 每次请求都换记忆完全失效第三知识库文档格式不规范PDF 扫描件、图片检索质量很差。前两个通过统一配置可以解决第三个需要先做文本清洗再入库。10. 最佳实践与使用建议10.1 工程落地建议第一次先小参数测试不要一上来就灌上千个文档。先用 5 到 10 个片段跑通链路再逐步扩充。保持一套最小可运行配置固定的模型名、固定的 Embedding 名称、固定的向量库目录遇到问题能快速回退。模型文件、知识库原始文档、清洗后文本、向量库目录、输出结果分目录管理不要全部堆在一起。批量任务必须加日志和失败重试否则知识库更新后很难定位是检索问题还是生成问题。接口服务要限制访问范围如果只在内网使用绑定 127.0.0.1 或内网 IP不要直接暴露公网。10.2 知识库内容规范尽量使用权威来源例如教材、官方文档、学术资料。同一份知识文档保持单一主题不要在同一个文件里混入多个不相关知识点。定期更新内容并重建索引避免旧资料长期占坑。10.3 合规提醒涉及真实历史人物和音乐作品背景时建议在回答中标注“资料来源于某某知识库”。如果使用公开素材要注意版权。如果智能体会保存用户对话记录必须在产品说明中告知用户并提供“清除记忆”功能。11. 总结与下一步这个“记住谁发明了钢琴键背景智能体”最值得尝试的点是把知识检索、会话记忆和 API 服务三件事打通。它能回答“谁发明了钢琴键”这类事实问题也能记住用户的提问偏好后续无论是扩展成音乐教育助手还是改成企业内部知识问答机器人都只需要替换知识库内容不用改主流程。最先要验证的功能是基础检索问答确认知识库能准确召回文档然后再测多轮记忆最后再封装 API 和批量任务。最容易踩的坑是接口配置不一致建议写一个 config 文件统一管理模型名、API 地址和向量库路径。下一步可以考虑给智能体增加“用户身份记忆”功能或者接入工作流平台把它变成一个可被外部 Agent 调用的子工具。如果跑通了这套流程你基本就掌握了目前主流智能体平台背后的核心逻辑知识库做依据记忆做上下文大模型做表达。建议收藏备用。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
