14.1
把需求限定为信息查找与核验
校园菜品系统可以作为连接两篇核心文章的具体设计对象。目标不是自动决定学生应该吃什么，而是帮助查找某窗口某版本菜品的已知信息、相关图片和待确认事项。用户可以问“哪些记录提到鸡肉”“这张图可能对应哪道菜”“两个同名商品是否属于同一版本”。这些问题既涉及对象与关系，也涉及图文身份与证据。系统输出应包括结论、来源、时间以及仍未知的部分，避免把常见配方当成当前食堂的实际配料表。
需求阶段可访谈学生与管理人员，收集真实问题并分类：精确商品查询、食材相关查找、图片匹配、反馈主题和信息冲突。不同类别设置不同验收标准。对无法由现有资料可靠回答的问题，应标明需要窗口确认或补充当前版本资料。范围越清楚，越容易选择适当技术：并非每个问题都需要全局社区分析，也并非每次都要调用视觉模型。一个有价值的最小系统，可以只处理少量窗口与明确日期，在数据更新和纠错上形成闭环。报告后文的模拟资料用于验证这种信息逻辑，不代表任何真实校园供餐情况。
14.2
建模菜品版本与观察来源
建议区分菜品概念、窗口商品和商品版本。宫保鸡丁作为概念可以连接常见做法，窗口A的宫保鸡丁是具体商品，某日期生效的配方则是版本。食材关系应优先连接到版本，而不是无限期连接到菜名。菜单、窗口确认、图片和评论作为不同来源产生观察；图片中疑似食材不直接覆盖已确认配料。评论中的口味反馈也应连接到体验事件，避免一条评价变成所有时间都成立的属性。
这个模型能表达变化与不一致。例如，一次配方调整后，旧图片仍可能出现在页面上；系统应发现图片与当前版本的时间不匹配，而不是把两者合并。若只知道拍摄时间而不知道适用版本，可以保留待关联状态。菜单名称变化不一定代表商品变化，同名也不保证同一商品，因此身份判断需要窗口、时间和管理记录。数据维护界面应允许工作人员更新版本、确认属性和撤回错误图片。图谱面向用户的视图可以简化显示，但底层证据关系应完整。这样用户看到的是清楚的当前信息，维护者仍能追踪它如何形成。
本报告原创设计
14.3
文字图像与人工确认的融合流程
接入菜单后，文本抽取器识别菜名、食材和做法，并保留原文位置。图片处理先检查清晰度与商品关联，再生成可能的食材类别与区域。融合阶段比较商品身份、版本和语义条件，把一致信息作为支持，把不一致信息交给核验队列。对不可见调味料，图片不提供排除证据；对文字中的否定，抽取器必须保留否定状态。人工确认记录应独立保存，并说明确认范围，例如只确认公开配料描述，而不声称验证所有加工过程。
流程可以采用低风险自动通过与高影响人工核验相结合。明确商品编号和当前菜单之间的匹配可以按规则处理，模糊图片或冲突配料则保留候选。审核界面并排展示菜单文字、图片区域和旧版本信息，减少来回查找。每次确认后生成可查询视图，同时保留原始候选以便研究错误。质量抽样应覆盖不同窗口、菜类与拍摄条件，而不只抽最清楚图片。这个流程的重点是把多模态补充转化为可管理证据，而不是把视觉识别分数直接当作可信程度。模型帮助发现线索，确认规则决定哪些线索进入当前知识。
14.4
为不同问题选择检索路径
精确商品问题先查当前版本与已确认属性，再返回菜单或确认记录。食材查找从食材实体反向连接相关商品，同时区分已确认、仅文字提及和视觉候选。图片匹配先产生候选，再检查窗口与时间；若用户没有提供这些条件，结果可以是候选列表而非唯一身份。反馈主题问题可以汇总评论事件，但需要说明样本时间和来源覆盖，不把少量评论概括为全体学生意见。这些路径可以共享证据标识，却不必使用完全相同的检索算法。
答案界面应让用户看到信息状态。例如“记录中有鸡肉”与“确认不含某食材”是不同陈述，后者需要明确排除证据。对于冲突记录，可以列出双方来源与时间，并提示尚待确认。系统应避免把未检索到关系显示为无该属性，也应避免把评论中的个人感受变成客观商品标签。若问题需要全局比较，可以先说明可比较的窗口与日期，再生成结论；缺乏同条件数据时不强行排名。这个设计将GraphRAG的关系组织能力用于缩小信息差，而不是制造超出资料支持范围的确定答案。
14.5
数据运营与反馈主题分析
校园应用需要持续维护菜单与图片，不只是一次构图。可以设置每日或按变更更新的资源清单，由窗口人员确认当前商品版本，学生反馈进入待审核队列。更新频率应取决于真实变化，不必为追求实时而持续重复处理不变文件。反馈分类可以区分信息错误、图片不匹配、版本过期和体验意见，分别交给合适责任人。系统应记录从发现到修复的时间，让维护能力成为可测指标。
主题分析可以帮助发现重复问题，例如某些窗口图片长期过期或菜单描述缺少关键属性，但需要防止重复提交放大声量。可按独立事件和时间聚合，并保留少数不同意见。对于经营分析，系统只能描述资料中的模式，不能仅凭评论共现断言经营原因。若某窗口晚高峰订单多且等待久，可以提出待核查关联，而不是直接认定订单量导致全部延迟。改善建议还需要结合排班、设备和现场流程等资料。多源图谱的作用是把这些核查路径组织起来，帮助管理人员提出更准确的问题，而不是自动替代现场判断。
14.6
试点验收与扩展条件
试点可选择少量窗口、固定日期范围和一组高频问题。验收同时检查信息正确、证据可追踪、冲突不被隐藏和更新能够生效。可以让工作人员与学生分别完成查找任务，记录耗时、错误和是否理解回答中的不确定性。若系统只提高查找速度却让用户误以为所有属性都已确认，仍需改进界面。无答案问题也必须纳入测试，确保系统能引导补充资料。最终评估应把自动指标、人工任务结果和维护负担放在一起。
扩展到更多窗口之前，应确认身份规则、本体和更新流程是否仍适用。不同商家可能使用不同命名方式，图片质量和配料公开程度也不同。可以先增加一组差异较大的窗口作为迁移测试，而不是只增加相似数据。若质量下降，应定位是数据不足、身份歧义还是流程无法维持。报告建议设定停止条件：关键错误无法及时修复、版本长期失效或证据来源不足时，应缩小回答范围。一个可信应用可以在有限范围内稳定工作，并清楚表达边界。扩展的依据应是新范围中的实测表现，而不是已有图谱节点数量达到某个规模。