Observer 与输入集

背景复制章节链接

Orisumi 保存采集到的数据，也保存模型的推断和用户的确认、否定、陈述。观测可以依据其他观测，层级不固定。

追溯一份推断时，要看到它实际用了什么。一份“下午在写代码”的推断可能读过几千条前台时段和键鼠事件，而且通常一天的数据放进一次模型调用，产生多份结果。

用户本身是业务实体，例如 VRChat 的玩家。同一个人可以凭亲身经历陈述，也可以读完日志再推理。一个程序可能读取多种来源，也可能只转发别人的观测。观测出错时，需要知道是谁作出了陈述。

决定复制章节链接

• 采集、整理、推断、确认、否定和陈述都是 Observation，层级由输入集之间的引用形成。
• Observer 是 observerVersionId 引用的业务实体，对观测负责。程序实例和人都是业务实体。
• Observer 按负责的陈述划分。只传输或组合已有观测的程序不改变原 Observer。
• 一次处理实际使用的版本由 InputSet 列出，实际输入相同的多份观测共用一个 InputSet 版本。
• 输入由 Observer 在处理时列出。
• 确认和否定的对象写在观测内容中。
• 输入被更新或删除后，已有的观测保持原样，是否重新处理由业务规则决定。

理由复制章节链接

Observer 是一种角色，任何业务实体都可以承担，同一个实体也可以在另一份观测中被观测。按负责的陈述划分 Observer，观测出错时才能找到作出陈述的一方。

是否依据已保存的数据，是一次陈述的性质，不是人或程序的类型，所以由每份观测是否引用输入集表达。

输入不能由时间推算。模型十点读取输入，十点零一分收到一条补录，十点零二分保存观测：以保存时间为上限，会把没读过的补录算进去；按事实时间重叠推算，读过和没读过的数据也分不开。所以由 Observer 列出实际使用的版本。

成员固定到版本，输入后来被修改，观测仍指向当时读到的内容。十份结果共用一个输入集，几千个成员只存一次。

用户否定推断时，被否定的观测写在内容中，参考过的日志写在输入集中，两种关系各有位置。

处理已经发生，依据就是当时的输入。是否重新处理由业务规则决定。

放弃的方案：

• 由事实时间和保存时间推算读过的数据。 会算进没读过的数据，输入被补全后结果还会变。
• 每条输入保存一个关系实体。 一天的推断要保存几千条有独立身份的关系，多份结果还要各存一遍。
• 在 EntitySchema 上声明 Observer 是否依据已保存的数据。 这是一次陈述的性质，不属于类型。
• 新增断言、关键证据或模型运行类型。 Observation 已经能表达推断和确认；模型、提示词和参数由业务内容表达。
• 按进程、接口或数据源划分 Observer。 同一进程里不相关的陈述会混在一个身份下。
• 保留 Observer 作为 Core 类型。 用户和代表用户的 Observer 会成为两个实体，Observer 也不能被观测。

代价复制章节链接

• Observer 必须如实列出实际使用的版本。后端只检查结构，无法验证列出的就是实际读过的。
• 输入集保存版本的身份，不是全库快照；重新调用模型可能得到不同的结果。
• 输入被删除后，追溯不再完整。
• 程序实例是业务实体，需要为它定义 EntitySchema。

规则位置复制章节链接

• Observer、InputSet、Evidence
• Observation