Langchain-Chatchat美食探店推荐：基于口味偏好的餐厅筛选-编程实验室

Langchain-Chatchat 美食探店推荐：基于口味偏好的餐厅筛选

在城市街头巷尾穿梭的美食爱好者，是否曾为“今晚吃啥”纠结良久？翻遍社交平台、点评网站，信息繁杂却难辨真伪；自己写的探店笔记越积越多，回头想找某家“辣得过瘾还不上火”的川菜馆时，却只能靠模糊记忆在文档里全文搜索。这不仅是个人困扰，更是非结构化知识管理的一个缩影。

有没有可能让 AI 成为你的私人美食顾问，不仅能听懂“微辣带麻、适合家庭聚餐”这种细腻表达，还能从你过往的探店记录中精准找出匹配项？答案是肯定的——借助Langchain-Chatchat，我们完全可以在本地构建一个专属的智能推荐系统，既保护隐私，又高度定制。

这个系统的本质，不是简单地做关键词匹配，而是将自然语言理解能力下沉到个人数据层面。它把散落的文本片段变成可检索的知识资产，再通过大模型进行语义级推理，最终输出有依据、可溯源的个性化推荐。整个过程无需联网上传任何内容，所有计算都在本地完成。

从一句话提问到一份可信推荐：系统如何工作？

想象这样一个场景：你刚结束加班，打开自家部署的 Chatchat Web 界面，输入：“想找一家环境安静、不太油腻的川菜馆，最好有包间。” 几秒钟后，系统返回：

推荐餐厅：蜀韵阁（珠江新城店）
推荐理由：该店多次被提及“麻辣鲜香但不燥热”，后厨采用控油工艺，菜单中标注“轻油”选项；设有三个独立包间，适合朋友小聚或家庭聚餐；人均消费约130元。
数据来源：2024年3月探店笔记《春日三访蜀韵阁》段落 #2

这背后其实经历了一套精密协作流程。用户的提问首先被送入 LangChain 的处理引擎，系统自动将其转化为向量表示，并在 FAISS 构建的向量数据库中查找语义最相近的文档片段。这些片段通常来自你之前导入的 Markdown 或 PDF 格式探店笔记，每一篇都已被切分、嵌入、索引。

关键在于，“不太油腻”这样的表达，在传统搜索引擎中可能毫无意义——没有哪个餐厅会主动标注“本店较油”。但语义向量空间能捕捉到类似“少油清爽”“吃完不会反胃”“适合健身人群”的上下文关联，从而实现跨词汇的精准匹配。

检索出的 top-3 相关段落后，它们会被拼接到原始问题之后，形成一条富含上下文的 Prompt，例如：

请根据以下真实探店记录，回答用户关于餐厅推荐的问题。 用户问题：想找一家环境安静、不太油腻的川菜馆，最好有包间。 相关记录： 1. [来自《春日三访蜀韵阁》] “这次尝试了他们新推出的‘轻油系列’，连水煮牛肉都用了低温慢炸技术减少吸油量……特别适合我这种怕长痘的人。” 2. [来自《周末聚餐实录》] “包间隔音很好，说话不用提高音量……服务员说很多公司团建会选择这里。” 请综合以上信息生成推荐结果，格式如下： > 推荐餐厅：XXX > 推荐理由：YYY > 数据来源：ZZZ

这条完整的 Prompt 被送入本地运行的大语言模型（如量化后的 Llama 或 Qwen），模型基于上下文生成结构化回答。由于训练数据中已包含大量中文餐饮语境，它能自然理解“包间=私密性好”、“轻油=健康取向”等隐含逻辑，而非机械拼接句子。

最终结果不仅给出建议，还附带引用出处，让用户可以点击溯源，查看完整原文。这种“可解释性”极大增强了推荐的可信度，也避免了“幻觉式推荐”的风险。

技术底座：LangChain 如何串联起碎片组件？

这套看似流畅的交互，其核心驱动力来自LangChain 框架。它并非一个单一工具，而是一套模块化的“AI 应用组装件”，就像乐高积木一样，允许开发者灵活组合不同功能单元。

以本例中的RetrievalQA链为例，它本质上是一个预定义的工作流：接收问题 → 检索相关文档 → 构造 Prompt → 调用 LLM → 返回答案。但它的强大之处在于每个环节均可替换和扩展。比如你可以：

换成不同的嵌入模型（如text2vec-large-chinese提升中文表现）；
使用 Milvus 替代 FAISS 实现分布式向量检索；
在链中插入自定义节点，比如先判断用户意图是否属于“找餐厅”类别，再决定是否启用美食知识库。

下面这段代码就是整个系统的骨架：

from langchain.chains import RetrievalQA from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import FAISS from langchain.llms import CTransformers # 初始化中文优化的嵌入模型 embeddings = HuggingFaceEmbeddings(model_name="GanymedeNil/text2vec-large-chinese") # 加载本地构建的知识库 vectorstore = FAISS.load_local("food_knowledge_db", embeddings, allow_dangerous_deserialization=True) # 调用本地量化模型（支持CPU/GPU混合推理） llm = CTransformers( model="models/qwen-7b-chat-q4_0.gguf", model_type="qwen", config={'max_new_tokens': 512, 'temperature': 0.7, 'context_length': 4096} ) # 创建检索问答链，限定返回3个最相关文档 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=vectorstore.as_retriever(search_kwargs={"k": 3}), return_source_documents=True ) # 执行查询 query = "有没有适合老人小孩的清淡粤菜馆？" result = qa_chain(query) print("推荐结果：", result["result"]) print("参考来源：", [doc.metadata.get('source') for doc in result["source_documents"]])

值得注意的是，这里的CTransformers并不要求高端显卡。通过 GGUF 量化格式，7B 参数级别的模型可在 RTX 3060 这类消费级 GPU 上流畅运行，甚至可在无独显的笔记本上以 CPU 模式低速响应。这对于个人用户来说极为友好。

另外，search_kwargs={"k": 3}的设置也很讲究。返回太多文档容易引入噪声，导致 LLM 注意力分散；太少则可能遗漏关键信息。实践中发现，对于餐饮类短文本，top-3 是个不错的平衡点。

Chatchat：为什么它是中文用户的理想选择？

如果说 LangChain 是发动机，那Chatchat就是整车——它提供了完整的驾驶舱（前端）、仪表盘（后台）和油箱管理系统（知识处理流水线）。相比其他开源项目，它的最大优势在于“开箱即用的中文体验”。

许多同类系统在处理中文文档时会出现乱码、分词断裂、编码错误等问题，而 Chatchat 内置了针对简体中文优化的文本处理器。无论是微信聊天截图转的文字、还是扫描版 PDF 中的菜单描述，它都能较好地还原语义块。

更贴心的是它的可视化界面。你不需要敲命令行就能完成文档上传、知识库重建、参数调试等操作。点击“测试问答”按钮，即可实时观察不同设置对输出质量的影响。比如调整“分块大小”后重新索引，看看是否提升了对“服务态度”这类抽象维度的识别准确率。

我还特别喜欢它的“元数据过滤”功能。假设你只关心广州地区的餐厅，可以在检索时加入过滤条件：

retriever = vectorstore.as_retriever( search_kwargs={ "k": 3, "filter": {"city": "广州", "cuisine": "川菜"} } )

这样一来，即便知识库里混杂了北京、上海的记录，也不会干扰当前查询。这种细粒度控制在实际应用中非常实用。

当然，部署前也要做好心理准备：首次构建知识库确实耗时较长。一篇 10 页的 PDF 可能需要几十秒才能走完整个解析—分块—向量化流程。建议采用增量更新策略，新增笔记单独处理后再合并进主库，避免每次全量重建。

实战经验：如何打造高质量的美食知识库？

系统的上限，往往取决于输入数据的质量。我在实践中总结了几条关键原则：

1. 文档质量 > 数量

宁可只有 10 篇写得详尽的探店笔记，也不要 100 篇“味道不错”“环境挺好”的空洞评价。理想的记录应包含多个维度：
-口味：辣度、咸淡、创新程度、是否有隐藏菜品
-环境：灯光、噪音水平、座位舒适度、是否适合拍照
-服务：响应速度、主动加水频率、能否提供儿童椅
-性价比：人均消费、分量大小、套餐是否划算

这些细节能显著提升向量表示的丰富性，也让 LLM 更容易做出差异化推荐。