为什么要实现语义层在agent落地场景中我们发现即使切片和解说策略做得再好依然会有一些bad case。往往其中很大一部分原因是因为AI无法去理解我们的业务。比如课程有多少节课要上在教务那边说一个课有多少个排课单元销售会说我们一节课多少个课时其实都指代的是一个同样的概念。还有就是实体之间的联系大模型也无法去理解。比如说课程对应课时课时又对应教学的内容教学内容又对应的教学点教学点又对应的教学大纲。这是从教务的维度进行说的。还有就是一节课有多少个课时每个课时的时长是多少它的一个师资需要进行什么样的配比。就决定了它的定价是多少。如何去实现语义层实现方案要从问题本身开始说起。实体的语义也无法统一实体之间的联系未知。解决方案如下本体(Ontology)—— 解决概念之间的关系。词表(Vocabulary)—— 解决叫法不统一。Schema —— 解决输出格式统一例如本体词表课时时(LessonPeriod)教学最小排课单位规范名课时定义……。课时 ← {排课单元(教务), 节课(销售), 课(口语)}用 git 里的一份 YAML/JSON实体别名关系加一个轻量图多跳多了再上 Neo4j就够关键是可评审、可版本化。词表(Vocabulary)# vocabulary.yaml —— 标准词 ↔ 别名映射 concepts: - concept_id: C001 standard_term: 排课单元 aliases: [课时, 课程时间, 课节, 上几次课, 多少节] domain: 教务 - concept_id: C002 standard_term: Python入门课 aliases: [蟒蛇课, py课, 编程启蒙课, 那个初级编程] domain: 课程 - concept_id: C003 standard_term: 续费率 aliases: [复购率, 再报率, 接着报的比例] domain: 销售 - concept_id: C004 standard_term: 试听课 aliases: [体验课, 免费课, 先听听那个] domain: 销售本体(Ontology)# 课程结构关系 (Python入门课) --包含-- (变量) (Python入门课) --包含-- (循环) (Python入门课) --包含-- (函数) (Python入门课) --排课单元-- (16节) (Python入门课) --适合年龄-- (8-12岁) (Python入门课) --难度-- (初级) # 知识点前置关系(学生问能不能跳着学时用) (循环) --前置知识-- (变量) (函数) --前置知识-- (变量) # 课程衔接关系(销售做课程推荐/续报时用) (Python入门课) --进阶课程-- (Python算法课) (Scratch启蒙课) --进阶课程-- (Python入门课) # 学员标签关系(个性化推荐时用) (学员标签:零基础) --推荐-- (Scratch启蒙课) (学员标签:有基础) --推荐-- (Python入门课)大规模落地用 Neo4j 图数据库存这些三元组,小规模用一张关系表(head, relation, tail)就行。四、三者如何在一次对话里协同(把上面串成故事)家长:这个py课要上几次课?而且感觉有点贵啊,我娃还完全没基础 │ ▼ ① 词表归一:py课→Python入门课, 几次课→排课单元 │ ▼ ② 查本体:Python入门课16个排课单元;零基础→推荐先上Scratch启蒙 │ ▼ ③ Schema分类:LLM输出 {objection_type:价格太贵, confidence:0.92, ...} │ (异议分类体系Schema在Prompt前缀,吃Prefix Cache) ▼ ④ 组合回复:Python入门课是16节。不过孩子零基础的话,我更建议先从 Scratch启蒙入手(查本体得到衔接关系),而且现在有试听课可以先体验 (查词表知道体验课试听课),觉得合适再报,价格上...约束型语义 上面的异议分类体系 Schema(小、稳、每次都要)→ 注入 Prompt 前缀,吃 Prefix Cache数据型语义 上面的本体(课程/知识点关系) 词表 学员标签(大、常变、按需取)→ 封装成 MCP 工具,走项目3网关按需查