Context Mark Language（简称CML）（或Contextual Markup Language），面向AI时代的上下文标记需要，提供符合自然语义的全新标记架构。
Context Mark Language标记语法的核心特征，是用单字符串表示多维度、可组合、隐含上下文关系的语义性标记结构，提供更简单的编写、嵌入、传输、存储、运算、命名体验。
中文文档 | English document
当前语言规范为 v1.0-beta.1，预发布状态。详细规范可以在 spec1.0/zh.md 中查看。
CML阐释了Context Structure Expression模型。该表达模型有望成为AI时代语义标记的新基石。论文详见：
Context Mark Language最初是伴随Model Doc Protocol（MDP-模型文档协议）而生，旨在提供一种接近自然语言表达的、可自由定义、任意嵌入的上下文语义结构基础架构。
自然语言是一种1维标记语言，负责高熵压缩语义，但存储效率极低。而LLM的向量空间是一个数千维的高维标记语言，具有相反的特征：低熵、高存储效率。
站在语义建模的角度:
- 单个“点”无法独立锁定语义，重要的是点与点之间的关系，那是真正锁定语义的片段。
- 所有标记语言都需要解决两个问题：语义存储（标记、压缩）、可计算。
就像这个人类世界不是只有英语一种自然语言，只要你能找到一种数学工具，能直接或间接操作关系结构，那么，理论上就一定能定义一种新的语义计算范式，从而创造出新的LLM、新的自然语言。
而CML是一种1.5维、原生关系驱动范式的语义标记语言。CML的设计提供了关系分形树的无损组合，可以支持大规模的动态拓扑图计算。有道是"一图胜千言"，在接近自然语言的体验上，可以借助拓扑结构提供了极高的熵减价值，另一方面，由于维度很低，他不像LLM的隐式语义黑箱，这为推理过程的可解释性提供了新的协同工具。
自然语言标记不是不可计算，只是它的计算模型极端简陋，人类实际遵循的计算规则是：字词增减、顺序调整、语气加权。顺序在自然语言中承担了太多职责：
- 因果
- 主从
- 修饰
- 时间
- 强弱
- 条件
- 流程
- ......
但它却只有三个可运算的自由度：有无、位置、强弱。
所以自然语言的建模本质是，用一维的拓扑标记，三维的计算工具，来模拟高维的语义组合关系。这种高熵范式的表达效率极高，但熵越高，越没结构约束，对接收侧的上下文共识背景的要求越高，独立计算性就越低，没有任何大规模拓扑计算的可能。
这就是CML选择1.5维的关键哲学差异，虽然怎么计算尚且未知，但必须引入可大规模计算的结构约束！
未来可解释性、可追溯性、可组合性的知识治理架构蓝图里，需要知识数据源主动提供一部分显式上下文，而不是全部隐式冻结在LLM的权重黑箱里，或者RAG的向量黑箱里。
但不需要类似下面这样伪精确、不便存储传输的静态标记：
{
"original-text":"这是关于MDP协议的知识点原文,知识提供者向LLM主动声明了建议加权的上下文标记......",
"title-context":[
{
"token":"协议",
"weight":0.3,
"object_token":[{
"token":"Model Doc Protocol",
"weight":0.9,
"property-token":{
"token":"下一代文档架构基础",
"weight":0.2,
}
}]
},
{
"token":"为AI时代而生",
"weight":0.4,
},
],
"lifecycle-context":[
{
"token":"知识提供",
"weight":0.1,
},
{
"token":"知识分发",
"weight":0.1,
},
]
}LLM时代，知识数据源真正需要的只是语义化的标记结构，是语义关系本身，且最好是自然语言表达、易于存储和传输、可运算。
而借助CML，我们只需要书写一串语义化的单一字符串，即可极简的表达上述复杂的上下文结构，且天然可组合运算：
`title-context`:`协议`.`Model Doc Protocol`@`下一代文档架构基础`+`为AI时代而生` `lifecycle-context`:`知识提供`.`知识分发`这个明文CML字符串本身就是一个合法的markdown格式，因此可以在任意支持Markdown的主流编辑器中被实时渲染成下面的自然语义效果，一目了然：
title-context:协议.Model Doc Protocol@下一代文档架构基础+为AI时代而生 lifecycle-context:知识提供.知识分发
CML的其中一个设计目标是接近香农极限，无论信息表达维度还是语义表达维度，实现最低的成本。
示例JSON表达权重语义，使用了711个字符（209个token），而CML字符串只需要122个字符（13个token）。信息容量提升了580%，token稀松率高达94%，很显然，在大规模token计算场景，CML可以在存储、内存、CPU层面带来成本的量级下降。
CML的另一个设计目标是安全和性能。
CML支持4种编码模式，确保无论在大规模场景还是短串场景，都具有最高的适应性。
其中经过Base58或Base64URL编码和首位模式字母附加之后的字符串，几乎可以被安全用于任何嵌入、嵌套、存储、传输、命名场景。包括但不限于，在html标签、模版字符串、 JSON、URL、数据库存储、序列化编码、日志输出、配置文件、shell/命令行、正则表达式、key命名、变量命名等所有主流场景下，免除转义、格式错乱的困扰。
比如：
在html中使用alt、data-cml来承载图片语义，方便LLM、搜索引擎低成本识别。
<img
src="mountain-sunset.jpg"
alt="这张流程图使用了cml语言公开了语义"
data-cml="a3EkzyE8r5SqnU6KSbLS98LVLJxFoNvskzaazkuEEryWminqaGwJz13YoatvfoRWoDyrofwUCQ"
>在json的key位置使用cml编码字符串
{
"a3EkzyE8r5SqnU6KSbLS98LVLJxFoNvskzaazkuEEryWminqaGwJz13YoatvfoRWoDyrofwUCQ":"key是本图片的上下文语义，用cml标记",
"name":"doc-war",
"semantic":"文档战争",
}在模板字符串中原文出现，或者在自然语言上下文中出现
const knowledge = "这是知识原文，我们用CML格式，给他提供了一些上下文标记"
const text = `这是知识点${Knowledge}一个CML字符串：a3EkzyE8r5SqnU6KSbLS98LVLJxFoNvskzaazkuEEryWminqaGwJz13YoatvfoRWoDyrofwUCQ`;安全拼接出sql语句
SELECT * FROM `knowledge_mark` WHERE `tokens` = 'a3EkzyE8r5SqnU6KSbLS98LVLJxFoNvskzaazkuEEryWminqaGwJz13YoatvfoRWoDyrofwUCQ';