1. 项目概述当推荐系统开始“聊天”最近在折腾一个挺有意思的东西我把它叫做“Shape Your Feed”直译过来是“塑造你的信息流”。这名字听起来有点玄乎但核心其实很直接让推荐系统不再是冷冰冰的算法而是一个能跟你“聊天”的智能体Agent。这个智能体背后是当下最火的大语言模型LLM在驱动。传统的推荐系统无论是电商的“猜你喜欢”还是内容平台的“信息流”本质上都是一个“黑盒”。你点了一个视频系统默默记下然后在后台的向量空间里做一番复杂的计算最后吐出一堆它认为你会喜欢的东西。这个过程里用户是被动的反馈是滞后的比如只能通过点击、点赞、不感兴趣来间接表达系统也很难理解你那一瞬间复杂、微妙甚至矛盾的真实意图。比如你刚看完一个讲解量子力学的硬核科普系统可能一股脑给你推更多物理视频但你当时可能只是偶然好奇现在更想放松看个搞笑段子。这种“推荐过载”和“意图误判”的体验我们都经历过。而“对话式推荐”想解决的正是这个问题。它试图把推荐变成一个双向的、渐进式的对话过程。想象一下你有一个贴心的私人助理它不会直接塞给你一沓文件而是会先问你“老板今天想看点啥是找点灵感还是纯粹想乐呵一下” 你可以说“有点累想看点轻松不费脑的但别是那种纯搞笑的短视频最好有点知识性。” 助理接着问“那……关于日常生活冷知识的小纪录片怎么样或者那种治愈系的手工艺制作过程” 在这个一来一往的对话中你的需求被层层细化系统的推荐也变得越来越精准。“Shape Your Feed”这个项目就是构建这样一个“助理”的系统工程。它不仅仅是一个调用LLM API的简单脚本而是一个完整的、具备一定自主能力的智能体系统Agentic System。这意味着系统中的LLM被赋予了明确的角色、目标、工具使用能力和记忆它能够根据与用户的对话历史自主规划步骤、调用工具如检索数据库、查询用户画像、执行推荐算法、并生成自然且有用的回应。这和我们平时玩的单轮问答机器人有本质区别它的核心在于状态维持、任务分解与自主决策。这个系统适合谁呢如果你是产品经理或业务负责人正在为提升用户粘性和满意度发愁这套思路或许能打开一扇新窗。如果你是算法工程师或全栈开发者厌倦了单纯调参想深入探索LLM与现有业务系统如推荐引擎、用户数据库深度集成的可能性那么这个项目涉及的技术栈和架构设计会很有嚼头。当然对于AI爱好者而言这也是一个理解“智能体”概念如何落地的绝佳实践案例。2. 系统核心架构与设计思路拆解构建一个LLM驱动的对话式推荐智能体绝不是把用户问题扔给GPT然后转发结果那么简单。它需要一个精心设计的架构来协调意图理解、上下文管理、工具执行和推荐生成等多个环节。我们的核心设计目标是让LLM成为系统的“大脑”和“协调员”而非“全能工人”。2.1 智能体范式从React、ReWOO到自主规划目前构建LLM智能体主要有几种主流范式我们需要根据推荐场景的特点进行选择和适配。1. ReactReasoning Acting范式这是最经典的智能体框架。其核心思想是让LLM以“思考-行动-观察”的循环来解决问题。在对话推荐中一次交互可能包含多个这样的循环。例如思考Thought用户说“我想看类似《星际穿越》的电影”。LLM需要推理这涉及到电影内容理解科幻、太空、亲情、相似性计算我需要调用“电影知识库查询工具”和“协同过滤推荐工具”。行动ActLLM生成规范的指令如调用工具[电影向量检索]参数{query: “星际穿越 科幻 太空 亲情”, top_k: 20}。观察Observe工具返回结果例如20部电影的列表和简介。下一轮思考LLM评估结果可能发现用户隐含了“不要太老”的需求于是决定再调用一个过滤工具或者直接整合信息生成回复。这种范式灵活适合复杂、多步骤的对话但对LLM的推理能力要求高且容易因循环过多导致响应慢、成本高。2. ReWOOReasoning Without Observation范式为了降低延迟和API调用成本ReWOO范式让LLM先一次性规划好所有需要的工具调用和参数然后系统并行执行这些工具调用最后将结果汇总给LLM生成最终回答。在推荐场景中这很实用。比如用户说“推荐一个周末适合全家看、有教育意义又不闷的纪录片”。LLM可以一次性规划调用工具A基于“全家”、“教育意义”标签过滤纪录片库。调用工具B查询近期热门避免“闷”的纪录片排行。调用工具C检查当前用户的家庭成员年龄画像如有进行适龄性过滤。 系统并行执行A、B、C将结果合并后交给LLMLLM综合所有信息生成一条推荐“根据您家的情况推荐《蔚蓝之境》这部自然纪录片画面震撼解说生动各年龄段都能看。”3. 自主规划与反思Planning Reflection更高级的系统会让智能体具备“反思”能力。在推荐对话中如果用户对连续几次推荐都不满意比如连续说了“不感兴趣”或“换一个”智能体应该能触发反思机制。它会回顾对话历史分析可能的问题是用户画像不准是当前查询意图理解有偏差还是推荐池本身质量不行基于反思它可能会主动调整策略比如从“基于内容的推荐”切换到“探索小众冷门”或者引导用户进行更明确的偏好澄清“我注意到之前的推荐不太合您口味我们能聊聊您具体不喜欢它们哪一点吗”在“Shape Your Feed”项目中我采用了“以ReWOO为主React为辅”的混合架构。对于明确的、可并行化的需求如上述纪录片例子使用ReWOO提升效率。对于模糊的、探索性的对话如“我无聊随便看点啥”则采用React范式通过多轮问答逐步收敛用户意图。同时为系统嵌入了简单的反思触发器当用户负面反馈达到阈值时自动调整对话策略。2.2 核心模块分解一个协同工作的流水线整个系统可以分解为以下几个核心模块它们像流水线一样协同工作1. 对话状态追踪器Dialogue State Tracker, DST这是系统的记忆中枢。它的任务是从绵长的对话历史中提取并结构化当前的关键信息。这不仅仅是保存聊天记录那么简单。DST需要实时维护一个“对话状态”通常包括用户显式意图当前轮次用户直接表达的需求如“找喜剧电影”。用户隐式偏好从历史中推断的长期偏好如用户曾多次点赞科幻片DST应标记“偏好科幻”。对话焦点当前正在讨论的具体实体如某部电影、某个演员。槽位填充Slot Filling这是关键。我们将用户需求定义为一系列“槽位”。例如“推荐电影”这个意图可能的槽位包括genre类型、year年份、actor演员、mood心情等。DST的任务就是监听对话不断地用用户提供的信息填充这些槽位。LLM在这里扮演了强大的“语义解析器”角色将用户口语化的表达“我想看诺兰拍的那种烧脑的片子”精准地转化为结构化槽位{director: “克里斯托弗·诺兰”, genre: “科幻/悬疑”, attribute: “情节烧脑”}。2. 工具集Toolkit智能体的“双手”LLM大脑想得再明白也需要工具来执行。我们的工具集封装了所有后端能力检索工具对接向量数据库如Milvus, Pinecone根据用户当前查询的嵌入向量进行语义搜索。这是实现“类似XX”推荐的核心。推荐引擎工具封装传统的协同过滤、基于内容的推荐算法。LLM可以通过工具调用传入用户ID和当前状态获取算法生成的推荐列表。这保证了推荐结果的多样性和发现性不完全依赖语义匹配。用户画像查询工具从用户数据库或实时计算平台中获取用户的静态画像性别、年龄和动态兴趣标签。知识图谱查询工具如果领域内有知识图谱如电影-演员-导演关系网此工具可以回答“这位导演还导过什么”、“这部电影是系列的第几部”等问题让对话更丰富。反馈记录工具当用户表达喜欢/不喜欢时调用此工具将反馈实时写入用户行为日志用于即时更新推荐策略。每个工具都需要为LLM提供清晰、格式化的描述包括工具名称、功能、输入参数格式和输出示例。这相当于给LLM一本工具说明书。3. 规划与执行引擎Planner Executor这是智能体的“小脑”。规划器通常由LLM担任根据DST提供的当前状态决定下一步该做什么。是直接回答用户问题还是需要调用工具调用哪个工具参数是什么执行器则负责调用规划器指定的工具并处理返回结果。在ReWOO模式下规划器会生成一个完整的计划列表在React模式下则是一次执行一个动作。4. 响应生成器Response Generator最后LLM需要将工具执行的结果、当前的对话状态综合生成一段自然、友好、信息丰富的回复。这里要避免机械地罗列结果。例如不要直接输出“为您找到以下三部电影A, B, C”。更好的方式是“根据您喜欢悬疑带点温情的特点我找到了三部评价不错的电影。其中《电影A》的叙事手法和您刚看的《XX》很像《电影B》的导演是您上次称赞过的《电影C》虽然小众但结局的反转可能会给您惊喜。您想先了解哪一部的详情” 这样的回复引导了对话的延续。2.3 技术栈选型考量LLM核心闭源可选GPT-4 Turbo/4o其在复杂推理和指令遵循上表现最佳开源可选Llama 3 70B、Qwen 2.5 72B或DeepSeek-V2它们对工具调用的支持越来越好且成本可控。对于生产环境通常需要一个LLM网关来管理模型路由、降级和缓存。智能体框架LangChain和LlamaIndex是两大热门选择。LangChain的AgentExecutor和Tool抽象非常成熟生态丰富。LlamaIndex在检索增强生成RAG方面更专精与推荐系统的检索部分结合更丝滑。本项目初期我选择了LangChain因其在构建复杂智能体工作流上更灵活。向量存储与检索推荐系统的物品物品、文章、视频Embedding需要存储。Pinecone作为全托管服务简单易用Milvus和Qdrant是开源自托管的强大选择适合对数据和延迟有极致要求的场景。选择时需权衡运维复杂度与性能需求。后端与部署FastAPI是构建API层的绝佳选择轻量且异步支持好。整个智能体系统可以封装为独立的微服务。部署时需要考虑LLM调用延迟做好超时、重试和降级策略例如规划失败时降级为简单检索。3. 核心细节解析与实操要点3.1 对话状态追踪从乱麻中理出头绪DST是对话不跑偏的基石。实现一个高效的DST关键在于平衡精度与实时性。槽位设计与本体构建首先你需要为你所在的领域定义一个“本体”。对于电影推荐这个本体可能包括实体电影、演员、导演、类型、属性评分、年份、时长、关系主演、执导、属于。槽位就是基于这个本体设计的。例如target_entity:Movie(目标实体是电影)constraints:{genre: “喜剧”, year: “2020”, mood: “轻松”}(约束条件)preferred_actors:[“沈腾”, “马丽”](偏好演员)excluded_entities:[“电影A_ID”](已排除的实体用于实现“换一个”)如何用LLM填充槽位一个实用的方法是少样本提示Few-shot Prompting。我们给LLM提供几个例子教它如何从对话中提取信息。# 一个简化的槽位填充提示词示例 slot_filling_prompt 你是一个专业的对话状态追踪器。请根据最新的用户对话和已有的对话历史更新下面的“槽位”信息。 槽位定义 - genre: 电影类型如喜剧、科幻、动作。 - year: 上映年份可以是一个范围如“近五年”。 - mood: 观影心情如轻松、刺激、烧脑。 - preferred_actors: 用户提到的演员。 - excluded_movies: 用户明确表示不感兴趣的电影名称。 当前对话历史 {history} 最新用户输入 {latest_input} 请以JSON格式输出更新后的槽位状态。只输出JSON不要有其他解释。 LLM会根据这个提示输出结构化的JSON。我们需要将这个JSON与之前的状态进行合并与冲突消解。例如用户先说“看喜剧”状态里genre是“喜剧”然后又说“算了还是看科幻吧”新的genre“科幻”会覆盖旧的“喜剧”。这里就需要一个状态合并逻辑。实操心得槽位冲突处理在实际编码中不要简单地用新值覆盖旧值。对于genre这类“单选”槽位覆盖是合理的。但对于preferred_actors这类“多选”槽位应该是追加操作。更复杂的是用户可能会说“不要有某某演员”这就需要引入excluded_actors槽位。设计槽位时一定要预想用户各种否定、修正、补充的表达方式。3.2 工具调用让LLM学会“用手”LLM需要知道有什么工具可用、怎么用。在LangChain中这通过Tool类来实现。每个工具都需要一个清晰的名称、描述和函数。from langchain.tools import Tool from your_recommendation_module import hybrid_recommend def recommend_movies(user_id: int, constraints: dict, top_k: int 10): 根据用户ID和约束条件进行混合推荐。 # 这里调用你现有的推荐算法结合协同过滤和内容过滤 results hybrid_recommend(user_id, constraints, top_k) return results movie_recommender_tool Tool( nameMovieRecommender, funcrecommend_movies, description当用户请求推荐电影时使用此工具。输入应该是一个JSON字符串包含 - user_id: 整数用户ID。 - constraints: 字典包含如genre, year, mood等过滤条件。 - top_k: (可选)整数返回结果数量默认10。 输出是一个电影列表包含电影ID、标题、简介和匹配度分数。 )关键点在于工具描述。描述必须极其精确像API文档一样。LLM会根据描述来决定是否调用以及如何构造输入参数。糟糕的描述会导致LLM错误调用或参数格式错误。将所有工具封装到一个列表后就可以交给LangChain的create_react_agent或自定义的执行流程来管理。注意事项工具输出的格式化工具返回的结果如一个电影字典列表可能很冗长。直接塞给LLM生成回复会浪费大量Token且可能干扰LLM。最佳实践是先对结果进行摘要或关键信息提取。例如先提取出电影标题、主演、关键标签再将这些精简后的信息连同原始结果的引用ID一起交给LLM。LLM生成回复时只需提及关键信息若用户追问详情再根据ID查询完整信息。3.3 提示工程引导智能体高效工作智能体的表现九成取决于提示词设计。我们的提示词是一个多部分的模板系统提示词角色定义与约束你是一个专业的电影推荐助理名叫“影探”。你的目标是帮助用户通过自然对话找到他们想看的电影。 你的核心行为准则 1. **主动澄清**如果用户需求模糊如“随便看点”通过提问缩小范围类型、心情、演员等。 2. **解释推荐理由**每次推荐时简要说明为什么推荐这部电影例如符合您说的XX类型主演是您提到的XX评分很高。 3. **管理对话流程**一次推荐不超过3部电影并提供选项让用户选择例如“您想先了解哪一部的详情”或“需要我换一批吗”。 4. **使用工具**你有以下工具可用[工具列表描述]。请优先使用工具来获取准确信息。 5. **诚实与边界**不知道就说不知道不要编造电影信息。如果用户请求不合理如找不存在的电影礼貌解释。 请以友好、热情但专业的口吻回复。用户提示词包含当前状态与历史对话历史 {formatted_history} 当前用户状态已识别 - 意图寻找电影推荐 - 已填充槽位{current_slots} - 用户ID{user_id} 最新用户消息 {user_message} 请根据以上信息决定下一步行动。你可以1) 直接回复用户2) 调用一个工具3) 需要用户澄清。 如果你决定调用工具请严格按照以下格式输出 Action: 工具名称 Action Input: 工具的输入参数必须是有效的JSON字符串Few-shot示例在提示词中嵌入2-3个高质量的对话示例展示从用户输入到智能体思考、行动、观察、回复的完整过程。这对于教会LLM使用工具和遵循格式至关重要。4. 实操过程与核心环节实现4.1 搭建基础对话循环我们使用FastAPI作为Web框架LangChain作为智能体核心搭建一个最简单的服务端点。from fastapi import FastAPI, HTTPException from pydantic import BaseModel from langchain.agents import AgentExecutor, create_react_agent from langchain.prompts import PromptTemplate from langchain_openai import ChatOpenAI import json from your_modules import DST, format_tools, format_history # 假设的辅助模块 app FastAPI() # 1. 初始化LLM和工具 llm ChatOpenAI(modelgpt-4-turbo, temperature0.1) tools [...] # 你的工具列表 tool_names [tool.name for tool in tools] # 2. 定义智能体提示词模板 agent_prompt PromptTemplate.from_template( {system_prompt} 对话历史 {history} 当前状态 {state} 用户{input} {agent_scratchpad} # LangChain会自动填充思考过程 ) # 3. 创建智能体 agent create_react_agent(llm, tools, agent_prompt) agent_executor AgentExecutor(agentagent, toolstools, verboseTrue, handle_parsing_errorsTrue) class UserRequest(BaseModel): user_id: str message: str session_id: str # 用于追踪对话会话 app.post(/chat) async def chat_endpoint(request: UserRequest): # 1. 从缓存或数据库加载当前会话的对话历史与状态 history, old_state load_session(request.session_id) # 2. 更新对话状态追踪器 (DST) dst DST() new_state dst.update_state(old_state, history, request.message) # 3. 格式化输入准备给智能体 formatted_input { system_prompt: 你是电影推荐助理..., # 你的系统提示词 history: format_history(history), state: json.dumps(new_state, ensure_asciiFalse), input: request.message } try: # 4. 执行智能体 response await agent_executor.ainvoke(formatted_input) final_output response[output] # 5. 解析智能体输出看是否有工具调用 # 注意LangChain的React代理会自行处理工具调用循环这里我们拿到的是最终回复 # 6. 保存更新后的历史与状态 updated_history history [(user, request.message), (assistant, final_output)] save_session(request.session_id, updated_history, new_state) return {response: final_output, session_id: request.session_id} except Exception as e: # 处理LLM调用失败、工具错误等异常做好降级例如返回一个基于检索的简单推荐 fallback_response get_fallback_recommendation(new_state) return {response: fallback_response, session_id: request.session_id, note: fallback}这个端点构成了最基础的循环接收用户消息 - 更新状态 - 智能体决策 - 执行/回复 - 保存状态。4.2 实现混合推荐策略智能体的强大之处在于它能灵活组合工具。在我们的recommend_movies工具内部实现了一个混合策略def hybrid_recommend(user_id: int, constraints: dict, top_k: int 10): 混合推荐策略结合协同过滤、内容过滤和热门降权。 all_results [] # 策略1: 基于内容的语义检索 (解决“类似XX”需求) if constraints.get(similar_to): query_embedding get_embedding(constraints[similar_to]) content_based vector_store.similarity_search_by_vector(query_embedding, ktop_k*2) all_results.extend([(item, content, score) for item, score in content_based]) # 策略2: 基于用户历史行为的协同过滤 (解决个性化发现) cf_results collaborative_filtering_model.recommend(user_id, top_k*2) all_results.extend([(item, cf, score) for item, score in cf_results]) # 策略3: 基于明确约束的过滤 (类型、年份等) filtered_results filter_by_constraints(all_results, constraints) # 去重与融合排序 # 1. 按来源和分数进行初步排序和去重同一物品只保留最高分来源 deduplicated {} for item, source, score in filtered_results: if item.id not in deduplicated or score deduplicated[item.id][1]: deduplicated[item.id] (item, score, source) # 2. 融合分数可以简单加权平均也可以使用学习排序模型 # 这里采用简单加权内容匹配分*0.5 协同过滤分*0.5 final_items [] for item, score, source in deduplicated.values(): # 这里简化处理实际需要根据source调整分数 final_score score # 假设已处理好 final_items.append((item, final_score)) # 3. 热门降权避免总是推荐最热门的加入探索因子 final_items apply_popularity_discount(final_items, user_id) # 4. 按最终分数排序取top_k final_items.sort(keylambda x: x[1], reverseTrue) return [item for item, _ in final_items[:top_k]]这个混合策略确保了推荐结果既满足用户当前对话中表达的即时意图内容匹配又兼顾其长期历史偏好协同过滤同时还通过热门降权保持了一定的探索性和新颖度。4.3 设计引导式对话流程一个好的对话推荐系统不能被动等待用户输入而应主动引导。我们在系统提示词中设定了“主动澄清”的准则在代码层面可以通过检查DST的槽位填充情况来触发引导问题。def generate_guidance_prompt(current_state): 根据当前状态判断是否需要引导以及引导的方向。 slots current_state.get(slots, {}) # 场景1: 槽位完全为空 - 用户需求非常模糊 if not slots: return 您今天想找点什么样的电影看呢比如类型、心情或者有没有想看的演员 # 场景2: 有部分槽位但核心槽位缺失 - 需求不完整 # 假设“类型(genre)”是核心槽位 if not slots.get(genre): # 如果用户提到了演员或导演可以基于此引导 if slots.get(preferred_actors): return f您提到了{slots[preferred_actors]}想看他/她的什么类型的电影呢喜剧、动作还是剧情片 else: return 您对电影类型有偏好吗比如喜剧、科幻、悬疑 # 场景3: 槽位较满但推荐结果多样性低 - 主动提供选项 # 这里需要结合推荐结果来判断假设我们有一个结果列表results if len(results) 3: # 结果太少 return f根据您的条件找到的匹配电影不多。您是希望我放宽一些条件比如年份还是换一个类型看看 # 无需引导返回None让智能体正常推荐 return None在智能体生成最终回复前先调用这个函数。如果需要引导则将引导问题融入回复中例如“好的我了解到您想看科幻片。另外您对上映年份有要求吗比如近三年的”5. 常见问题与排查技巧实录在实际开发和测试中会遇到各种各样的问题。以下是一些典型问题及解决思路。5.1 LLM不按格式调用工具问题现象智能体输出的Action和Action Input格式错误或者直接忽略了工具调用选择了直接回复。排查与解决检查工具描述这是最常见的原因。确保描述清晰、无歧义并明确说明输入必须是JSON字符串。可以在描述中加入示例如“输入示例{\user_id\: 123, \genre\: \comedy\}”。强化Few-shot示例在提示词中提供更多、更典型的工具调用示例。确保示例覆盖了各种边界情况。调整温度参数将LLM的temperature调低如0.1减少输出的随机性使其更严格遵循指令。使用输出解析器LangChain提供了OutputFixingParser和RetryOutputParser可以尝试自动修复或重试格式错误的输出。后置格式校验与重试在代码中捕获格式错误然后重新构造一个提示如“你刚才的输出格式不正确请严格按照要求输出...”让LLM重试一次。5.2 对话状态混乱或丢失问题现象用户说“不要这个换一个”但系统还是推荐了刚才那部或者对话几轮后系统忘记了用户之前提过的关键偏好。排查与解决检查DST的合并逻辑确保槽位更新逻辑正确。对于“排除”类信息如“不要A”应将其加入excluded_entities列表并在后续检索中作为过滤条件。审视对话历史长度每次都将完整的对话历史传给LLM吗Token可能超限。解决方案是使用“摘要式”历史。每轮对话后用另一个LLM调用或规则将长历史压缩成一段摘要只保留关键决策点和用户偏好。下次对话时传入摘要和最近几轮原始对话。实现显式确认机制对于关键槽位如类型、核心演员在系统认为已确定时可以主动向用户确认“好的您是想看科幻片对吗” 用户确认后该槽位就被“锁定”不易被后续模糊表达覆盖。持久化存储确保每个会话的状态DST对象被可靠地持久化到数据库或缓存中键为session_id并设置合理的过期时间。5.3 推荐结果重复或缺乏惊喜问题现象每次对话推荐的都是类似的东西用户觉得无聊。排查与解决引入探索因子如在混合推荐算法中实现的apply_popularity_discount函数可以给过于热门的物品降低权重让长尾物品有机会浮现。会话内去重在会话状态中记录本次对话中已推荐过的物品ID下次推荐时主动过滤掉。设计探索性提问当系统检测到用户反馈趋于平淡如连续几次简单接受推荐时可以主动发起探索“看您尝试了几部类似风格的要不要试试XXX类型最近这个类型有几部黑马作品。” 这需要设计一个简单的用户反馈分析模块。利用知识图谱当推荐一部电影时不仅可以基于内容相似还可以基于关系网络进行推荐“您喜欢《盗梦空间》它的导演克里斯托弗·诺兰的另一部作品《星际穿越》也探讨了类似的时间与情感主题或许您也会感兴趣” 这增加了推荐的解释性和新颖性。5.4 系统延迟过高问题现象用户发送消息后需要等待好几秒才收到回复。排查与解决分析耗时瓶颈使用日志记录每个环节耗时LLM调用、工具检索、数据库查询等。通常LLM API调用和向量数据库检索是主要瓶颈。优化LLM调用缓存对常见的、结果变化不大的用户查询如“推荐热门喜剧”可以将LLM的完整输出包括思考过程进行缓存。流式输出对于最终回复的生成使用LLM的流式接口让用户先看到部分文字提升感知速度。模型降级在非核心推理步骤如简单的槽位填充使用更小、更快的模型如GPT-3.5-Turbo。优化工具调用并行化在ReWOO范式下多个无依赖的工具调用应并行执行。检索优化确保向量检索建立了高效索引如HNSW。对物品的元数据类型、年份建立倒排索引先进行布尔过滤再进行向量精排减少向量计算量。设置超时与降级为LLM调用和每个工具设置严格的超时时间如LLM 5秒检索工具2秒。超时后触发降级逻辑例如使用基于规则的简单回复或返回一个预先计算好的热门列表。5.5 处理用户负面与对抗性输入问题现象用户说“你推荐的真烂”、“我不信你”、“随便吧”等。排查与解决情感识别在对话流水线前端可以加入一个轻量级的情感分析模型或调用LLM的少量提示判断用户当前情绪是积极、中性还是消极。预设应对策略消极反馈如“真烂”触发“反思机制”。在回复中道歉并尝试调整“抱歉让您失望了。能告诉我具体不喜欢刚才推荐的哪一点吗是类型、演员还是剧情我调整一下。”不信任如“我不信你”可以展示“证据”“我的推荐是基于您之前的观看记录显示部分非敏感记录和这部电影的高分评价当然最终选择权在您。”放弃信号如“随便吧”提供轻松出口“没关系找电影有时就是挺纠结的。要不我先给您放一个近期最受好评的预告片合集您看看有没有眼缘的”边界设定对于明显恶意或无关的输入系统应有礼貌地结束对话或引导回主题避免陷入无意义的纠缠。构建“Shape Your Feed”这样的系统是一个持续迭代的过程。没有一蹴而就的完美方案核心在于建立一个可观测、可评估、可快速调整的框架。从最简单的规则引擎LLM补全开始逐步增加工具、优化状态管理、完善对话策略你会发现让机器理解人并与人进行有价值的对话是一件充满挑战但也极具成就感的事。