Dify平台的美食点评生成口味还原度测试-平芜编程栈

Dify平台的美食点评生成口味还原度测试

在内容为王的时代，一条生动真实的美食点评，可能比十张精修图片更能打动人心。然而，当企业需要批量生成高质量、具象化、有“人味儿”的餐饮内容时，传统人工撰写效率低下，而直接调用大模型又常产出“味道不错”“口感丰富”这类空洞描述——既无细节，也无灵魂。

有没有一种方式，能让AI写出“外皮酥到掉渣，咬下去油脂香瞬间迸发，蘸上甜面酱和葱丝才够地道”这样的真实体验？这正是我们设计“口味还原度测试”的初衷。我们选择Dify作为实验平台，不是因为它只是个提示词编辑器，而是它提供了一套完整的工程化路径，让我们能系统性地逼近“人类感知级”的内容生成。

从“写出来”到“写得像”：一场关于感官真实的挑战

要让AI真正理解“麻、辣、鲜、香”，光靠模型参数远远不够。我们需要构建一个以语义记忆为核心、具备动态决策能力的内容引擎。在Dify中，这个引擎由三大支柱支撑：可视化流程编排、RAG增强检索、以及Agent式推理机制。

先看最直观的部分——流程设计。你不需要写一行代码，就能在画布上拖出这样一个链条：

用户输入 → 检索相似菜品 → 注入上下文 → 调用大模型 → 格式化输出

听起来简单？但关键在于每个节点之间的“数据流动”。比如，当用户输入“螺蛳粉”时，系统不会立刻生成文字，而是先去知识库里找那些高赞点评里反复出现的关键词：“酸笋发酵感”“汤底浓郁带骨香”“米粉滑弹略带阻力”。这些片段不是关键词匹配出来的，而是通过向量化后在语义空间中被“嗅”到的。

我们使用的是 OpenAI 的text-embedding-3-small模型进行嵌入，配合内置的轻量级向量引擎。虽然不如 Milvus 或 Weaviate 那样适合超大规模部署，但对于十万条以内的点评数据集，响应速度稳定在 800ms 以内，且召回结果的相关性明显优于传统 TF-IDF 方法。

{ "nodes": [ { "id": "input_1", "type": "input", "data": { "variable": "dish_name" } }, { "id": "retrieval_1", "type": "retrieval", "data": { "query_variable": "dish_name", "dataset_id": "ds_chinese_food_v3", "top_k": 3, "score_threshold": 0.62 } }, { "id": "llm_1", "type": "llm", "data": { "model": "gpt-4-turbo", "prompt_template": "请根据以下真实描述风格，写一条关于【{{dish_name}}】的新点评：\n\n参考内容：\n{{#context}}\n- {{content}}\n{{/context}}\n\n要求：\n1. 使用生活化语言，避免广告腔；\n2. 至少包含两个具体口感词（如绵密、焦脆、回甘等）；\n3. 提及一种典型配料或吃法。" } } ], "edges": [ { "source": "input_1", "target": "retrieval_1" }, { "source": "retrieval_1", "target": "llm_1" } ] }

这段 JSON 看似平淡，但它定义了一个“会学习”的生成逻辑。{{#context}}...{{/context}}是 Mustache 模板语法，在运行时会被替换成三条最相关的用户原声点评。这意味着每次生成都有据可依，而不是凭空想象。

RAG 不是“加点参考资料”那么简单

很多人以为 RAG 就是把几段文本塞进 prompt 里。但在实际应用中，如果处理不当，反而会导致信息过载、重点模糊，甚至引发模型困惑。

我们在测试初期就遇到了这个问题：输入“水煮牛肉”，系统返回了关于“刀工”“摆盘”“配菜种类”的信息，却忽略了最关键的“麻”与“辣”的层次表达。原因出在分块策略上。

原始数据是一整篇长评，切片时若按固定长度（如 256 tokens），很容易把“入口微麻，随后热辣席卷舌尖，最后留下淡淡花椒清香”这样一句话拆成两半，导致语义断裂。

解决方案是改用语义边界切分。我们在预处理阶段加入 NLP 规则，优先在句号、分号、转折连词处断开，并确保每一块尽量围绕单一感官维度组织。例如将“汤头醇厚，猪骨熬足十二小时”归为“香气/浓度”类，“面条筋道，咬劲十足”归为“质地”类。这样检索时不仅能命中更多相关段落，还能实现“按需调用”。

我们也尝试调整top_k和similarity_threshold参数组合：

top_k	threshold	召回率	冗余度	生成质量评分（人工盲测）
3	0.70	较低	低	3.8 / 5.0
5	0.65	中等	中	4.3 / 5.0 ✅
5	0.60	高	高	3.9 / 5.0

最终选定top_k=5,threshold=0.65为最优配置。低于此阈值的内容虽有关联性，但往往偏离主题；高于则遗漏太多细节。

更进一步，我们发现可以利用 Dify 的标签过滤功能，实现个性化口味适配。例如针对“不能吃辣”的用户，切换至“温和版知识子集”，避开“火辣冲鼻”“辣到流泪”等描述，转而强调“豆瓣酱的发酵香”“汤汁的复合咸鲜”。

from dify_client import DatasetClient client = DatasetClient(api_key="your_api_key") # 按用户偏好加载不同数据集 if user_profile.get("spicy_tolerance") == "low": dataset_id = "ds_sichuan_mild_v2" else: dataset_id = "ds_sichuan_authentic_v3" results = client.retrieve( dataset_id=dataset_id, query=f"正宗 {dish_name} 应有的风味特点", top_k=5, score_threshold=0.65 )

这种细粒度控制，使得同一模型能输出截然不同的“人格化”表达，而这正是商业场景中最需要的能力。

当 AI 开始“思考”：Agent 如何补全信息缺口

即便有了 RAG，依然会有“资料不足”的情况。比如面对“缙云烧饼”这种地方小众小吃，知识库中的样本稀少，仅靠检索难以支撑完整描述。

这时，传统的流水线式流程就会失败。但如果我们赋予系统一点“自主意识”呢？

Dify 支持基于 ReAct 范式的 Agent 构建。我们可以设定这样一个行为模式：当模型察觉信息不足时，主动发起二次检索，甚至模拟追问。

虽然目前主要通过界面配置，但我们用 SDK 实现了一个简化版闭环逻辑：

def generate_review_with_agent(dish_name): messages = [{"role": "user", "content": f"写一条关于【{dish_name}】的真实美食点评"}] for step in range(5): resp = client.create_chat_completion( model="gpt-4-turbo", messages=messages, tools=[{"type": "retrieval", "dataset_ids": ["ds_local_snacks"]}] ) output = resp["choices"][0]["message"]["content"] tool_calls = resp["choices"][0]["message"].get("tool_calls", []) if tool_calls and "retrieve" in str(tool_calls): # 自动触发检索并注入结果 retrieval_result = simulate_retrieval(dish_name, k=4) system_msg = {"role": "system", "content": f"补充信息来自本地小吃数据库：{retrieval_result}"} messages.append(system_msg) continue if contains_generic_phrases(output): # 检测到模糊表达，引导细化 messages.append({ "role": "system", "content": "请增加具体口感描述，例如‘酥脆’‘软糯’‘多汁’等" }) continue return output return post_process(output)

在这个流程中，模型不再是被动执行者，而是变成了一个“探店记者”：看到陌生菜品，先查资料；觉得描述太泛，自我修正；直到输出满意结果。虽然增加了约 1.8 秒的平均延迟，但生成内容的信息密度提升了近 40%。

更重要的是，它开始表现出某种“判断力”。有一次输入“锅巴土豆”，模型在第一轮输出后自行追加了一句：“需要确认是否添加折耳根？”——尽管训练数据中并未明确教它这么做，但它从大量川渝点评中学会了这是该菜品的关键争议点。