1. 项目缘起当“今天吃什么”遇上大模型“今天中午吃什么”——这大概是每个上班族、学生党甚至每个家庭每天都要面对的“灵魂拷问”。过去我们依赖大众点评、小红书、朋友推荐或者干脆凭感觉。但这些方式总有些局限点评榜单可能被营销影响朋友口味不一定和你一致而“凭感觉”在陌生的城市或面对琳琅满目的选择时常常失灵。我最近在做一个有趣的尝试能不能让大语言模型LLM来当我的“私人美食顾问”不是简单地让它从网上扒拉一堆餐厅列表而是希望它能像一个真正懂行的本地朋友那样结合实时天气、我的具体位置、甚至当下的心情和场景给出真正“应景”的推荐。比如炎炎夏日午后在CBD开会间隙我需要的是步行可达、环境清凉、能快速补充能量的轻食而阴雨绵绵的周末傍晚在家附近可能就想找一家氛围温馨、有热汤热菜的小馆子。这个想法催生了“Weather- and Location-Aware Agentic Dining Recommendation”这个项目。它的核心目标是构建一个具备“智能体”Agent特性的餐饮推荐系统。这个智能体不仅能理解用户用自然语言表达的模糊需求“想吃点暖和的”、“附近人少环境好的”还能主动调用外部知识天气API、地理位置服务、LLM自身的世界知识库进行区域敏感的上下文推理最终生成个性化、情境化的推荐方案。“Agentic”在这里是关键。它意味着这个系统不是被动的问答机器而是能主动规划、调用工具、进行多步推理的智能体。而“Leveraging LLM World Knowledge for Region-Sensitive Contextual Reasoning”则点明了技术核心利用大模型内嵌的、关于全球各地饮食文化、餐厅类型、菜品风味乃至消费水平的庞杂“世界知识”再结合具体的区域如“上海静安寺商圈” vs. “成都宽窄巷子周边”和实时上下文如天气、时间进行深度推理。这超越了传统基于协同过滤或内容标签的推荐系统更像是一个融合了常识、地理文化和实时感知的决策大脑。2. 系统架构设计一个会“思考”的推荐智能体要实现上述目标一个简单的提示词工程Prompt Engineering是远远不够的。我们需要设计一个能够自主运作的智能体系统架构。整个系统的核心流程可以分解为感知、规划、执行与合成四个阶段其架构概览如下图所示注以下为逻辑架构描述非具体代码。整个系统围绕一个“智能体中枢”展开其工作流如下用户输入与意图解析用户提出自然语言请求如“下雨天在公司附近找个能聊天的地方吃饭”。智能体中枢首先调用LLM将这句模糊的话解析成结构化的意图包括核心需求用餐、场景下雨天、工作日午间、位置约束公司附近、氛围偏好适合聊天。上下文感知与信息收集根据解析出的意图智能体中枢会并行触发两个关键的动作调用天气API获取用户指定位置或根据IP自动获取的实时天气状况如小雨气温18°C。调用地理位置服务将“公司附近”这样的模糊描述通过地理编码Geocoding转换为具体的经纬度坐标再通过地点搜索Places SearchAPI获取该坐标周边一定范围内如步行15分钟的餐饮POI兴趣点信息包括名称、类型、评分、大致价格等基础元数据。知识增强与候选池生成获取到原始的餐厅列表后直接将其丢给用户选择依然很粗糙。这时LLM的“世界知识”就派上用场了。智能体中枢会将餐厅列表例如[“A川菜馆” “B日式拉面” “C西式简餐”]和当前的上下文下雨、午后、想聊天一起构造一个提示词Prompt要求LLM对每个候选餐厅进行“情境适配度”评估和知识补充。提示这一步的Prompt设计至关重要。例如“基于以下上下文天气为小雨且微凉18°C时间是工作日下午茶时段用户想找一个能轻松聊天的场所。请对以下餐厅进行评估1. 从菜品特性是否有热汤、暖食、2. 店内环境是否拥挤、嘈杂、3. 该品类在此时此景下的普遍适宜度三个方面进行分析并为每个餐厅生成一段简短的情境化描述。” LLM可能会输出“A川菜馆麻辣口味能驱寒但通常环境热闹适合多人聚餐而非安静聊天。B日式拉面热汤面非常适合雨天但吧台座位居多私密交谈稍弱。C西式简餐通常有卡座环境相对安静但菜品可能不够‘暖和’。” 这样我们就将干巴巴的列表转化为了富含情境推理的、可读性强的描述。排序与最终推荐生成智能体中枢综合地理位置距离、LLM生成的情境适配度描述、以及原有的评分价格数据通过一个加权排序算法生成最终的推荐列表。最后再次调用LLM将排序后的结果组织成一段友好、自然、有说服力的推荐语呈现给用户。这个架构的关键在于LLM不仅是最终的回答生成器更在中间环节扮演了“情境推理器”和“知识增强器”的角色。它把冰冷的API数据和用户的主观感受连接了起来。3. 核心技术实现细节拆解3.1 上下文感知天气与位置API的集成与数据清洗感知层是系统准确性的基石。我们主要集成两类API天气API选择如OpenWeatherMap、和风天气等提供丰富数据的服务。关键不在于获取“晴雨”而在于获取能影响饮食决策的精细化参数温度与体感温度这是决定“想吃点暖和”还是“想吃点清爽”的核心。降水类型与强度小雨可能让人想喝杯热饮暴雨则更关注餐厅是否易达、有无遮挡。空气质量指数AQI雾霾天可能会优先推荐室内环境好、有空气净化设备的餐厅。紫外线强度晴天午后户外座位或有落地窗的餐厅可能更受欢迎。集成时需要注意API的调用频率限制、成本以及如何处理用户位置的模糊性如用户只说“我在市中心”。一个实用的策略是默认使用用户设备IP解析的粗略位置获取天气如果用户提供了更精确的地标则以后者为准。地理位置服务这里主要使用如Google Places API、高德地图API或百度地图API。流程分两步地理编码将“北京国贸三期”、“上海静安寺”等地标文字通过Geocoding API转换为经纬度坐标。这里要处理歧义例如“南京路”在上海和武汉都有需要结合用户历史位置或城市上下文进行消歧。周边地点搜索使用Places Nearby Search以上一步得到的坐标为中心按半径如1000米搜索类型为“餐馆”的地点。返回的数据需要清洗去重不同API或不同数据源可能返回同一家店的不同条目。营业状态过滤必须过滤掉“永久关闭”或“临时歇业”的场所。信息补全基础API可能只返回名称、坐标和类型。需要通过Place Details API获取更丰富的详情如用户评分、价格等级、联系电话、当前繁忙度等。这一步是后续LLM进行深度推理的重要数据来源。3.2 智能体中枢LLM的提示词工程与推理链设计这是项目的灵魂。我们不能只问LLM“下雨天推荐什么餐厅”这太宽泛。我们需要设计一套结构化的提示词引导LLM进行多步推理。一个高效的提示词模板通常包含以下部分角色定义你是一位资深的美食生活顾问精通各地饮食文化善于结合天气、场合和人的心情给出餐饮建议。任务与上下文清晰列出所有已知信息。用户需求寻找一个适合在雨天、用于商务便餐的场所。 用户位置上海市静安区南京西路经纬度[121.46, 31.23]。 实时天气小雨气温15°C湿度85%。 时间工作日下午1点。 候选餐厅列表来自地图API - 餐厅A本帮菜距离200米评分4.2人均150 - 餐厅B意大利菜距离500米评分4.5人均300 - 餐厅C粤式茶餐厅距离800米评分4.0人均80推理步骤指令这是核心要求LLM按步骤思考。请按以下步骤分析 步骤1分析当前天气和场景对餐饮选择的潜在影响。例如雨天是否更需要靠近地铁站或提供雨具的餐厅商务便餐对环境和上菜速度有何要求 步骤2针对列表中的每一家餐厅结合其菜系特点、人均价格和距离评估它与步骤1中分析出的需求的匹配程度。请利用你对这些菜系的常识例如本帮菜偏甜鲜适合慢聊意大利菜环境通常较正式茶餐厅上菜快、氛围随意。 步骤3根据匹配度对餐厅进行排序并为你排名第一的餐厅撰写一段推荐语。推荐语需直接回应天气和场景例如“雨天微凉这家本帮菜馆的暖胃浓汤和静谧的包间正好适合您的商务洽谈。”输出格式约束要求以指定的JSON格式输出便于程序后续解析。请以以下JSON格式输出你的分析结果 { weather_impact_analysis: ..., restaurant_assessments: [ {name: 餐厅A, cuisine: 本帮菜, match_reasoning: ..., suitability_score: 0-10}, ... ], top_recommendation: { name: ..., reasoning: ..., suggested_mention: 给用户的推荐语 } }通过这样的链式思考Chain-of-Thought提示我们迫使LLM将其内部的世界知识如菜系特点、商务场合礼仪与外部的实时数据天气、位置进行关联从而做出有据可依的推荐。这比单纯让LLM生成一个餐厅名字要可靠得多。3.3 区域敏感性实现让LLM理解“地方特色”“Region-Sensitive”是标题中的另一个重点。中国幅员辽阔饮食文化差异巨大。LLM虽然拥有世界知识但我们需要在提示词中激活其对特定区域的认知。注入地域知识在提示词的上下文部分明确指明区域。例如不仅说“上海”可以说“上海静安寺商圈这里以精品咖啡馆、小众西餐和高端本帮菜闻名”。这能引导LLM调用更相关的知识。利用本地化数据将从地图API获取的餐厅信息中的“用户评论精选”或“特色标签”作为输入的一部分喂给LLM。例如一家餐厅的标签是“老上海经典”、“弄堂里的味道”这些本地用户产生的标签是极强的区域信号。处理区域差异对于连锁店LLM需要理解其在不同城市的定位可能不同。在提示词中可以加入指令“请注意这家‘南京大牌档’在南京本地以传统小吃为主但在上海的分店可能环境更精致菜品有所调整。”这需要前期对LLM进行一些微调Fine-tuning或提供更丰富的上下文。一个常见的陷阱是LLM的“平均主义”倾向。它可能知道四川菜辣但无法感知“成都的辣”和“重庆的辣”在具体菜品上的细微差别。为了缓解这个问题可以在系统提示词中强调“请特别注意地域差异例如在推荐广州的早茶时优先考虑虾饺、烧卖等经典茶点而在推荐北京的涮肉时需提及麻酱蘸料的特色。”4. 实战挑战与优化策略在实际构建和调试这个系统的过程中我遇到了几个颇具代表性的挑战也总结出一些优化策略。4.1 挑战一LLM的“幻觉”与事实性核查LLM在描述餐厅时可能会“捏造”细节例如将一家普通的快餐店描述成“拥有百年历史的宫廷秘方”。这是致命的。解决方案严格的信息锚定提供给LLM进行推理的餐厅基础信息名称、菜系、评分、价格必须严格来自可信的API如官方地图服务。在提示词中明确指令“你的分析必须严格基于我提供的以下餐厅信息不得自行添加或编造这些餐厅不存在的特性。”关键事实提取与验证对于LLM生成的推荐理由中涉及的具体事实如“该店招牌菜是XX”可以设计一个二次验证流程。例如调用搜索引擎或餐饮平台的API以“餐厅名招牌菜”为关键词进行快速检索验证该说法是否存在广泛提及。置信度标注在LLM的输出格式中要求其对每个判断点提供一个置信度分数。对于低置信度的描述在最终呈现给用户时可以弱化处理或添加“据网络信息”等免责说明。4.2 挑战二多目标权衡与排序算法系统收到了多个有时相互冲突的信号用户要“便宜”但天气冷又想“吃火锅”而最近的火锅店评分只有3.5分。如何权衡解决方案构建可解释的评分体系不要设计一个黑箱模型。我们可以为每个维度设立子分数S_distance基于距离的分数越近分越高。S_price基于价格匹配度的分数用户预算与人均价。S_weather基于LLM天气适配度分析的分数0-10分。S_scenario基于LLM场景适配度分析的分数0-10分。S_rating基于客观评分的分数如4.0分映射为8分。动态权重分配权重不应固定。我们可以通过分析用户查询的语义来动态调整。例如当用户查询中包含“急需”、“快点”时S_distance的权重应大幅提高当查询强调“庆祝”、“纪念日”时S_scenario和S_rating的权重应增加。这可以通过一个轻量级的文本分类器或直接在给LLM的指令中实现“用户明确表达了对方便性的极高要求请在排序时给予距离因素最高优先级”。最终分数计算Final_Score w1*S_distance w2*S_price w3*S_weather w4*S_scenario w5*S_rating。根据动态权重计算后排序。4.3 挑战三性能、成本与实时性LLM API调用尤其是GPT-4等高级模型成本较高且耗时。如果对几十家候选餐厅逐一进行深度推理响应时间和费用都无法接受。解决方案两级过滤与推理粗筛先用简单的规则如距离、价格区间、营业状态从地图API返回的几十个结果中快速过滤出5-8个最相关的候选者。这个阶段不用LLM。精评只对这5-8个候选者使用LLM进行上文所述的深度情境推理。这大大减少了LLM的调用次数。提示词优化与缓存精心设计提示词力求简洁、准确减少不必要的token消耗。对于常见、通用的场景组合如“下雨天商务餐”、“晴天朋友聚会”其LLM推理结果可以缓存一段时间例如1小时。因为天气和餐厅基础信息在短时间内变化不大同一地点相似场景的查询可以直接使用缓存结果极大提升响应速度并降低成本。模型选型在保证效果的前提下优先考虑性价比更高的模型。例如对天气、场景的基础分析可以使用较小的开源模型如Qwen系列、DeepSeek系列仅在最终生成推荐语时使用能力最强的大模型。5. 效果评估与迭代方向如何判断这个系统真的比大众点评的榜单更好我们需要一套评估体系。人工评估邀请测试用户针对一系列设计好的场景如“暴雨天加班后在公司3公里内找一个能让人放松的独处吃饭地点”进行查询将系统推荐结果与大众点评的“附近”“评分排序”结果进行盲测对比让用户从相关性、说服力、惊喜度等方面打分。A/B测试如果集成在更大的应用内可以进行A/B测试一组用户看到传统推荐另一组看到智能体推荐比较两者的点击率、收藏率乃至实际到店核销率。关键指标推荐接受率用户在看到推荐后进行下一步操作查看详情、导航、收藏的比例。情境契合度通过后续反馈问卷询问用户“该推荐是否考虑了当时的天气/场合”。响应时间95%的查询应在多少秒内返回结果。基于初期测试我发现这个系统在“非标准需求”和“复合条件需求”上优势明显。对于“随便吃吃”的需求它可能和榜单区别不大。但对于“下雨天想找一个有露天座位但又有雨棚、能看到街景、适合一个人发呆的咖啡馆”这种非常具体、多维的需求传统推荐系统基本无能为力而智能体通过LLM的推理能力却能尝试从咖啡馆的评论标签“街景阳台”、“安静”、“单人友好”中挖掘出匹配项。未来的迭代方向可以包括个性化长期记忆引入用户历史行为数据让系统记住用户偏爱菜系、常去区域、消费习惯实现越用越懂你。多模态输入允许用户上传图片如路过一家店的门脸由LLM进行图像识别并结合上下文分析。供应链与实时信息整合接入餐厅的实时座位信息、今日特色菜甚至厨余材料推动可持续消费让推荐更具时效性和独特性。构建这样一个系统的过程让我深刻体会到LLM的价值远不止于聊天和生成文本。当它被设计成能够主动感知环境、调用工具、进行多步推理的“智能体”时就能在像餐饮推荐这样高度依赖上下文和常识的领域创造出真正智能、贴心的用户体验。它不再是一个工具而是一个数字世界的“生活伙伴”。
