1. 项目概述当推荐系统学会“聊天”你有没有过这样的体验打开一个内容平台首页推荐给你的内容要么是几天前看过的同类视频要么就是一些完全不感兴趣的信息。传统的推荐系统就像一个沉默的“数据管家”它根据你过去的行为点击、观看、停留来猜测你的喜好然后一股脑地把相似的东西推给你。这种模式的问题在于它缺乏“即时”的互动和“意图”的澄清。你此刻想放松一下看个搞笑视频但系统可能还在给你推送上周你研究某个技术问题时的严肃内容。“Shape Your Feed”这个项目正是为了解决这个痛点。它不是一个简单的算法优化而是一个基于大语言模型的智能体系统目标是把单向的“推送”变成双向的“对话式推荐”。简单来说它试图打造一个能和你聊天的推荐引擎。你不再是被动接收信息而是可以通过自然语言像和朋友交流一样主动地、动态地“塑造”你的信息流。它的核心价值在于意图理解和动态协同。想象一下你可以对系统说“今天心情不好给我找点轻松治愈的短片不要太长5分钟以内。” 或者在工作间隙说“我想快速了解下最近AI绘画有什么新玩法用3个最典型的案例告诉我。” 传统的推荐系统面对这样的指令几乎无能为力但一个由LLM驱动的智能体系统可以理解这些复杂的、多条件的请求并协调背后的搜索、过滤、排序、内容理解等多个模块为你生成一个高度个性化的、即时的推荐列表。这个项目适合所有对下一代人机交互和个性化服务感兴趣的人无论是推荐算法工程师、产品经理还是希望将LLM能力落地到具体业务场景的开发者。它不仅仅是一个技术Demo更代表了一种产品思维范式的转变从“猜你喜欢”到“听你说要什么”。2. 系统核心架构与设计思路拆解一个能聊天的推荐系统绝不是把ChatGPT的对话接口和现有的推荐算法简单拼接。它需要一套全新的架构让LLM从一个“文本生成器”转变为一个能感知环境、调用工具、完成复杂任务的“智能体”。下面我们来拆解“Shape Your Feed”系统可能的核心设计思路。2.1 智能体范式从工具调用者到流程编排者系统的核心是“智能体”。这里的智能体不是单一模块而是一个由LLM作为“大脑”的协同系统。其设计通常遵循“感知-规划-行动”的循环。感知系统接收用户的自然语言输入。例如“我想看一些关于城市徒步路线的视频最好是国内小众的有实际路线规划的。”规划与理解LLM的核心任务在这里是意图解析与槽位填充。它需要将模糊的用户语句转化为机器可执行的、结构化的查询意图。意图识别判断用户是想“探索新内容”、“过滤现有信息流”、“获取特定知识”还是“混合操作”。槽位填充从语句中提取关键约束条件并填充到预定义的“槽位”中。以上述语句为例内容主题城市徒步内容类型视频地域范围国内特性标签小众、有路线规划操作类型探索/搜索生成执行计划LLM根据解析出的意图和槽位规划一系列需要调用的工具或模块。例如调用[内容检索工具]搜索“城市徒步 视频” - 调用[标签过滤工具]筛选“小众”、“路线规划”标签 - 调用[地域过滤工具]限定“国内” - 调用[排序工具]按相关度排序 - 组织结果并生成自然语言回复。行动系统根据LLM生成的计划调用相应的工具函数。这些工具是后端能力的封装例如向量检索工具将用户查询或内容描述转换为向量从向量数据库中寻找语义最相近的内容。元数据过滤工具基于标签、分类、地域、时长等结构化字段进行筛选。实时热度/趋势计算工具获取当前热门内容。用户画像查询工具获取用户长期兴趣标签在获得用户同意和数据合规的前提下。内容摘要生成工具为每个推荐结果生成一两句话的亮点摘要。观察与迭代执行工具后LLM会观察返回的结果如检索到的内容列表、过滤后的数量。如果结果不理想如数量为0LLM可以自主调整查询策略例如放宽某个条件将“小众”改为“热门”或重新解释用户意图进入下一个“规划-行动”循环直到获得满意结果或达到迭代上限。设计心得这里的LLM不是万能的。它的强项是理解和规划但具体的检索、计算、排序等重型操作必须交给专门化的工具。这种“大脑LLM 手脚工具”的架构既发挥了LLM的灵活性又保证了系统的效率和准确性。一个常见的坑是让LLM直接生成SQL或复杂查询语句这在大规模生产环境中极易出错且难以优化。更好的做法是让LLM输出结构化的查询参数如JSON由后端的、经过严格测试的API来执行。2.2 对话状态管理与上下文理解单轮对话相对简单真正的挑战在于多轮对话。用户可能会说“刚才那些徒步视频不错但有没有更偏重美食探索的” 系统必须记住之前的上下文。这就需要对话状态管理模块。该模块会维护一个会话级别的上下文窗口通常包括用户当前显式意图最新的请求。历史对话记录精简后的几轮对话历史。持久化的用户偏好在本轮对话中用户表现出的临时偏好例如本轮对话中用户多次点击了“慢节奏”标签。系统已执行的操作避免重复调用或逻辑冲突。LLM在每一轮都需要基于完整的对话状态来规划新的动作。例如当用户提出“更偏重美食探索”时LLM需要理解这是一个在“城市徒步”基础上的属性叠加请求而不是一个全新的搜索。它可能会规划这样的动作从上一轮的结果缓存中读取内容ID - 调用[内容关联工具]寻找这些内容中带有“美食”标签或与之相似的内容 - 混合排序。实操要点直接给LLM喂完整的、未经处理的对话历史会快速消耗token并可能导致关键信息被淹没。实践中需要对历史对话进行摘要或关键信息提取。例如将上一轮的交互摘要为“用户请求了国内小众的城市徒步视频系统返回了5个结果用户对结果A和B表示了兴趣。” 再将这个摘要和当前query一起送入LLM效率和质量更高。2.3 工具集的精心设计与协同工具集的设计决定了系统的能力边界。一个好的工具集应该是模块化、可扩展且功能明确的。内容检索工具这是基石。通常结合关键词搜索和向量语义搜索。关键词搜索保证召回率和对明确实体如“黄山”的准确性向量搜索则能理解“让人放松的风景”这类抽象语义。两者结果融合后作为候选池。属性过滤工具处理结构化约束。如“时长5分钟”、“发布时间7天内”、“分辨率1080p”。这些过滤应在检索后快速执行以缩小范围。排序与混排工具这是推荐系统的精髓。简单的做法是按相关度排序。但更智能的系统会引入多目标排序相关性与当前query的匹配度。多样性避免结果同质化不能全是同一个博主的视频。新颖性适当引入用户未看过但可能感兴趣的内容。实时性平衡经典内容和热点内容。 LLM可以参与排序权重的动态调整。例如用户说“多给我看点不一样的”LLM可以在调用排序工具时传入一个更高的“多样性”权重参数。内容理解与摘要工具为了让回复更人性化系统需要对推荐的内容有更深的理解。可以调用另一个轻量级的LLM或摘要模型为每个候选内容生成一个吸引人的“推荐理由”例如“这个视频详细拆解了从杭州九溪到龙井村的徒步路线中途穿插了三家特色茶馆的探店正好符合您‘徒步美食’的需求。”避坑指南工具调用存在失败风险网络超时、API限制、数据异常。系统必须有完善的错误处理与降级策略。例如当向量检索服务不可用时自动降级到纯关键词检索并让LLM在回复中说明“为了更快地响应本次主要根据关键词为您搜索。” 这比直接报错或返回空结果体验好得多。3. 关键技术细节与实现解析理解了架构我们深入到几个关键的技术实现细节这些是决定系统是否“智能”和“可用”的核心。3.1 基于LLM的意图解析与槽位填充实战这是对话的起点也是精度要求最高的一环。我们不会依赖复杂的标注数据和训练模型而是利用LLM的零样本/少样本能力。提示词工程是关键。我们需要设计一个结构化的提示词Prompt来引导LLM输出我们想要的格式。你是一个对话式推荐系统的意图解析模块。请将用户的自然语言请求解析为以下JSON格式。 JSON格式说明 { intent: explore | filter | refine | compare, // 探索新内容、过滤现有流、细化条件、比较内容 slots: { topic: 字符串描述核心主题, content_type: [video, article, audio, any] // 内容类型 filters: { // 过滤条件 duration_max: 整数单位分钟, time_range: day | week | month | any, tags_include: [字符串数组必须包含的标签], tags_exclude: [字符串数组希望排除的标签], // ... 其他自定义过滤字段 }, preference: diversity | novelty | popularity // 结果偏好多样性、新颖性、热度 } } 用户请求{user_query} 请只输出JSON不要有任何其他解释。示例用户输入“推荐几个最近一周内发布的、关于Python异步编程的实战教程视频不要太基础的。”LLM理想输出{ intent: explore, slots: { topic: Python异步编程实战, content_type: [video], filters: { time_range: week, tags_include: [tutorial, advanced], tags_exclude: [beginner] }, preference: diversity } }注意事项LLM的输出可能不稳定。在生产环境中必须对输出进行后处理校验。包括JSON格式合法性检查、槽位值有效性校验如content_type是否在允许的枚举值内、逻辑冲突检查如同时要求duration_max为5和content_type为“长文章”。校验失败应触发重试或使用默认值降级。3.2 动态工作流编排LLM作为调度器解析出结构化的意图后LLM需要决定调用哪些工具以及调用顺序。我们可以采用两种模式预定义工作流模板为每种intent预设一个工具调用流程。例如对于intent: explore固定流程是检索 - 过滤 - 排序 - 摘要。这种方式稳定、可控但灵活性稍差。动态规划给予LLM所有可用工具的描述名称、功能、输入输出格式让它根据当前的具体slots动态生成调用链。这更灵活但对LLM的要求更高且需要更鲁棒的错误处理。实践中常采用混合模式。为常见意图预设模板保证基线同时允许LLM在特定场景下如用户提出了非常规的复合请求进行动态调整或插入额外的工具调用。示例动态规划提示词片段可用工具 - search_by_semantic(query: str, top_k: int): 根据语义向量搜索内容。 - filter_by_metadata(content_ids: list, filters: dict): 根据元数据过滤内容。 - rerank_by_diversity(content_ids: list): 对内容进行多样性重排。 - get_trending_topics(): 获取当前热门话题。 ... 当前用户请求解析结果{parsed_intent_and_slots} 请规划为了满足该请求需要调用哪些工具以及调用顺序。输出格式为工具名列表。3.3 结果生成与个性化回复拿到最终推荐的内容列表后最后一步是生成友好、自然且个性化的回复。这同样由LLM完成但需要注入足够的上下文。提示词设计示例你是一个亲切的推荐助手。请根据以下信息生成一段回复给用户。 用户原始请求{original_query} 系统推荐的结果最多5条 {result_list_in_json_format} 其中每条结果包含标题、创作者、推荐理由、链接占位符。 请组织语言先总结你根据他的要求做了什么例如“根据你想看轻松治愈短片的需求我找到了以下几个5分钟以内的视频...”然后逐一介绍推荐内容突出其与用户需求匹配的亮点。语气自然、热情但不要夸张。最后可以邀请用户反馈或进行下一步交互例如“如果对某个感兴趣我可以带你深入了解”或“需要调整条件的话随时告诉我哦”。通过这种方式系统不再是冷冰冰地抛出一堆链接而是完成了一次有头有尾的“服务对话”。4. 系统搭建实操与核心环节实现假设我们要为一个技术博客社区搭建一个简易版的“Shape Your Feed”系统。下面是一个基于Python和开源组件的实现路径。4.1 基础环境与组件选型LLM服务考虑到可控性和成本使用开源模型本地部署如Qwen2.5-7B-Instruct或Llama 3.1-8B。使用vLLM或Ollama进行高性能推理部署。如果追求更佳效果且能接受API成本也可使用DeepSeek-V3、GPT-4o-mini或Claude 3.5 Haiku的API。智能体框架使用LangChain或LlamaIndex。它们提供了智能体、工具链、记忆管理等高层抽象能极大简化开发。这里我们以LangChain为例。向量数据库用于存储博客文章的嵌入向量实现语义搜索。选用ChromaDB轻量简单或Qdrant性能强大。后端框架FastAPI用于构建提供对话接口的Web服务。数据源假设我们已有博客文章的元数据数据库MySQL/PostgreSQL包含id, title, author, content, tags, publish_date等字段。4.2 核心模块实现步骤4.2.1 知识库构建与向量化首先需要让系统“知道”有什么内容可推荐。# 伪代码示例 from langchain.vectorstores import Chroma from langchain.embeddings import HuggingFaceEmbeddings import json # 1. 从数据库读取博客文章 articles fetch_articles_from_db() # 返回列表每项为字典 # 2. 准备文本用于生成嵌入。通常结合标题、摘要和关键标签 texts_to_embed [] metadatas [] for article in articles: composite_text f标题{article[title]}\n标签{, .join(article[tags])}\n摘要{article[abstract]} texts_to_embed.append(composite_text) metadatas.append({ id: article[id], title: article[title], author: article[author], publish_date: str(article[publish_date]), tags: article[tags] }) # 3. 加载嵌入模型 embedding_model HuggingFaceEmbeddings(model_nameBAAI/bge-small-zh-v1.5) # 中文小模型 # 4. 创建并持久化向量库 vectorstore Chroma.from_texts( textstexts_to_embed, embeddingembedding_model, metadatasmetadatas, persist_directory./chroma_db ) vectorstore.persist()4.2.2 工具函数定义在LangChain中工具是可以被智能体调用的函数。from langchain.tools import tool from typing import List, Dict import some_search_client # 假设的搜索客户端 tool def semantic_search_tool(query: str, top_k: int 10) - List[Dict]: 根据查询语句进行语义搜索返回相关的博客文章列表。 # 使用之前创建的vectorstore docs vectorstore.similarity_search(query, ktop_k) results [] for doc in docs: results.append({ id: doc.metadata[id], title: doc.metadata[title], author: doc.metadata[author], tags: doc.metadata[tags], snippet: doc.page_content[:200] ..., # 片段 score: doc.score # 相似度分数如果有 }) return results tool def filter_by_tags_tool(article_list: List[Dict], include_tags: List[str] None, exclude_tags: List[str] None) - List[Dict]: 根据标签包含或排除来过滤文章列表。 filtered [] for article in article_list: article_tags set(article.get(tags, [])) include_ok not include_tags or any(tag in article_tags for tag in include_tags) exclude_ok not exclude_tags or not any(tag in article_tags for tag in exclude_tags) if include_ok and exclude_ok: filtered.append(article) return filtered tool def get_trending_articles_tool(timeframe: str week) - List[Dict]: 获取近期热门的博客文章。timeframe可选day, week, month。 # 这里调用实际的热度计算逻辑例如基于阅读数、点赞数、评论数 # 返回格式与semantic_search_tool类似 pass4.2.3 智能体组装与对话链构建使用LangChain的ReAct代理框架。from langchain.agents import AgentExecutor, create_react_agent from langchain.prompts import PromptTemplate from langchain_community.llms import VLLM # 假设使用vLLM集成 # 1. 初始化LLM llm VLLM(modelQwen/Qwen2.5-7B-Instruct, ...) # 2. 定义工具列表 tools [semantic_search_tool, filter_by_tags_tool, get_trending_articles_tool] # 3. 定义ReAct风格的提示词模板 agent_prompt PromptTemplate.from_template( 你是一个技术博客推荐助手。请通过思考Thought、行动Action、观察Observation的步骤来回答用户问题。 你可以使用的工具 {tools} 用户问题{input} 开始你必须使用指定的JSON格式输出。 Thought: 分析用户需求决定使用哪个工具。 Action: 工具调用的JSON如 {{tool: tool_name, tool_input: {{arg1: value}} }} Observation: 工具返回的结果 ... (这个循环可以重复多次) Thought: 我现在有足够信息回答用户了。 Final Answer: 给用户的最终回复应友好、详细并引用你找到的具体文章信息。 {agent_scratchpad} # LangChain会自动填充历史步骤 ) # 4. 创建智能体 agent create_react_agent(llm, tools, agent_prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) # 5. 运行示例 result agent_executor.invoke({ input: 我想找一些最近关于LangChain高级用法的文章最好是实战案例不要纯理论。 }) print(result[output])在这个流程中LLM会自主决定先调用semantic_search_tool搜索“LangChain 高级用法 实战”然后可能调用filter_by_tags_tool来排除带有“理论”标签的文章最后组织语言回复。4.3 前端交互界面简易版使用Gradio快速构建一个聊天界面。import gradio as gr from your_agent_module import agent_executor # 导入上面定义的执行器 def chat_with_agent(message, history): 处理用户消息调用智能体返回回复。 history history or [] # 将历史记录格式化为LangChain Agent需要的上下文简化处理 full_input message # 调用智能体 response agent_executor.invoke({input: full_input}) answer response[output] # 将本次交互加入历史 history.append((message, answer)) return history, history # 创建Gradio界面 with gr.Blocks() as demo: chatbot gr.Chatbot(label博客推荐助手) msg gr.Textbox(label请输入你的问题) clear gr.Button(清空对话) def respond(message, chat_history): bot_message agent_executor.invoke({input: message})[output] chat_history.append((message, bot_message)) return , chat_history msg.submit(respond, [msg, chatbot], [msg, chatbot]) clear.click(lambda: None, None, chatbot, queueFalse) demo.launch()5. 常见问题、挑战与优化策略实录在实际构建和调试这样一个系统时你会遇到一系列预料之中和预料之外的问题。以下是我从实践中总结的一些核心挑战与应对策略。5.1 意图解析不准与幻觉问题问题LLM可能会错误解析用户意图例如将“不要基础的”解析为tags_include: [基础]或者完全捏造幻觉出不存在的过滤器。解决方案结构化输出强化在提示词中严格要求输出格式并使用类似Pydantic的库进行输出解析。LangChain的create_structured_output_runnable能很好地处理这个问题。后处理与兜底设计一套规则对解析结果进行清洗和修正。例如如果intent字段不在预定义列表中则默认为explore如果content_type包含不支持的媒体类型则过滤掉。少样本示例在提示词中提供2-3个清晰、正确的解析示例能显著提升LLM输出的稳定性和准确性。多轮澄清当解析出的关键槽位置信度低或为空时系统可以主动提问澄清。例如用户说“找点AI相关的”LLM可以规划一个特殊动作ask_clarification(topicAI, options[机器学习, 深度学习, AIGC, AI工具])让用户选择细分方向。5.2 工具调用效率与延迟问题智能体在决定行动前需要“思考”工具调用尤其是网络I/O也存在延迟导致单轮响应时间可能超过数秒体验差。优化策略LLM推理加速使用量化模型如GPTQ、AWQ、更高效的推理引擎vLLM, TensorRT-LLM以及缓存Cache常见query的意图解析结果。并行工具调用分析工具间的依赖关系对无依赖的工具进行并行调用。例如semantic_search和get_trending可以同时进行然后合并结果。流式响应不要等所有步骤完成再回复。可以采用“边思考边输出”的模式。例如先快速回复“我正在帮你寻找关于Python异步编程的实战视频...”然后在后台执行工具调用找到结果后再以追加消息的形式发送“找到了这里有几个不错的...”。设置超时与熔断为每个工具调用设置严格的超时时间。如果某个工具如外部API响应过慢或失败立即使用降级方案如使用缓存数据或跳过该工具。5.3 结果质量与多样性平衡问题系统可能过度迎合用户当前query导致推荐结果同质化严重形成“信息茧房”或者为了多样性而推荐了不相关的内容。调优方法在排序层引入多目标优化设计一个打分函数综合考虑相关性分数、内容的新鲜度、创作者多样性、用户历史行为差异度等。可以给LLM一个接口让它根据对话上下文动态调整这些目标的权重。探索与利用策略在系统中内置一个小的“探索”比例如5%。无论用户query是什么都固定拿出一小部分流量来推荐与用户长期兴趣相关但未明确表达过的内容或当前热门内容。用户反馈闭环在对话中设计轻量的反馈机制。例如在每个推荐结果后加上“”和“”按钮。用户的显式反馈点击、跳过、负反馈是优化推荐质量最宝贵的信号可以实时用于调整当前会话的推荐策略。5.4 对话状态管理与长期记忆问题简单的上下文窗口只能记住最近几轮对话用户如果隔了很久再回来或者提到很久以前聊过的内容系统就无法理解。进阶方案向量化记忆将每轮对话的核心信息如用户表达的关键偏好、系统推荐过的内容ID生成摘要并转换为向量存入一个独立的“对话记忆”向量库。当新对话开始时除了最近的上下文还可以从这个记忆库中检索相关的历史会话片段作为补充上下文提供给LLM。显式偏好管理允许用户通过指令管理偏好。例如用户说“记住我喜欢看前端框架React的内容。” 系统可以解析这个指令将“偏好React”持久化到用户配置中并在后续的推荐中作为一个长期因子进行考虑。会话总结与压缩在对话轮次较长时主动触发一个总结动作用LLM将之前的对话浓缩成几个关键点替换掉冗长的原始历史以节省上下文窗口。5.5 安全与合规风险问题用户可能输入恶意、诱导性或不合规的查询LLM可能生成不合适的内容推荐的内容本身可能存在风险。防护措施输入过滤与审查在用户query进入LLM之前进行敏感词过滤和意图安全分类。对于明显违规的请求如涉及暴力、歧视等直接拦截并返回标准提示。输出内容安全审查对LLM生成的最终回复以及工具返回的内容摘要进行二次安全检查。可以使用一个轻量级的文本分类模型来快速判断。内容源治理确保被推荐的内容本身来自合规、可信的源并建立内容审核机制。这是整个系统的基石。透明度与可控性在回复中可以适当说明推荐的理由“因为您提到了XX所以为您找到了这些...”让用户感觉可控。提供明确的指令让用户能重置对话或清除偏好。构建“Shape Your Feed”这样的系统是一个持续迭代和平衡的过程。它不是在追求一个完美的、全能的AI而是在打造一个可用、可靠、可控的对话式协作界面。技术是手段最终目标是让用户能更轻松、更高效地获取他们真正需要的信息重新掌握对自己信息流的“塑造权”。从简单的关键词搜索到今天的智能对话推荐人机交互的方式正在发生深刻变化而这个项目正是站在了这个浪潮的前沿。