待分析的内容：

• 如何显示已经预测/标注的记录中由规则标注函数生成的实体
• 规则标注函数处理必须由服务器API计算，否则，UI应用程序和Python客户端将存在重复逻辑。

请求：

GET http://.../labeling/rules/dd:search?label=ALF&labeling_function=lab_D

将返回：

{
  "total": 1,
  "records": [
    {
      "id": "522a4e28-57fd-4f58-8da8-0b5117f716de",
      "status": "Default",
      "annotation": {
        "agent": "lab_D",
        "entities": [
          {
            "start": 0,
            "end": 4,
            "label": "ALF",
            "score": 1
          }
        ]
      },
      "annotations": {
        "lab_D": {
          "entities": [
            {
              "start": 0,
              "end": 4,
              "label": "ALF",
              "score": 1
            }
          ]
        }
      },
      "metrics": {},
      "text": "what do you think?",
      "tokens": [
        "what",
        "do",
        "you",
        "think?"
      ]
    }
  ]
}

通过使用新的 annotations 字段，API可以将标注函数匹配与原始注解结合在一起。

谢谢！是的，让我们周五一起看一下。
需要分析的内容：

• 如何显示规则标注函数为已有预测/注解的记录生成的实体

您是指由标注规则生成的"materialized"实体还是仅指在弱标注模式中定义的匹配/选定的标记？目前，我理解我们正在使用粉红色字体高亮器来指示匹配的标记，对吗？

• 规则标注函数处理必须由服务器API计算，否则，UI应用程序和Python客户端将存在重复逻辑。

请求：

GET http://.../labeling/rules/dd:search?label=ALF&labeling_function=lab_D

将返回：

{
  "total": 1,
  "records": [
    {
      "id": "522a4e28-57fd-4f58-8da8-0b5117f716de",
      "status": "Default",
      "annotation": {
        "agent": "lab_D",
        "entities": [
          {
            "start": 0,
            "end": 4,
            "label": "ALF",
            "score": 1
          }
        ]
      },
      "annotations": {
        "lab_D": {
          "entities": [
            {
              "start": 0,
              "end": 4,
              "label": "ALF",
              "score": 1
            }
          ]
        }
      },
      "metrics": {},
      "text": "what do you think?",
      "tokens": [
        "what",
        "do",
        "you",
        "think?"
      ]
    }
  ]
}

通过使用新的 annotations 字段，API可以将标注函数匹配与原始注解结合在一起。
这确实非常棒。同时，也同意统一服务器和客户端对标注函数的计算。

决策说明
记录列表

• 保持视图
• 提高查询对记录的可见性

设置规则的模块

• 改进信息架构：1. 从查询开始(目前这一步还有些害羞)
• 在主视图上应用更改。移除或调整从注解/探索模式继承的组件。例如：移除标签图例，在标签按钮上添加信息颜色等。

这是一个很好的特性。我想问一下，在这种情况下，弱标签之间的冲突将如何解决？如果我们有一个弱标签为 Par* 的记录，将其标记为 ANIMAL,另一个记录 Paris 被标记为 LOCATION,那么对于这个记录：Paris is the city of light,应该应用哪个标签？我建议使用类似多数投票的方法，如果票数相等，则随机选择。

当验证记录时，我们是否能够同时验证预测和弱标签(它们的并集),还是我们必须做出选择，要么验证预测，要么验证弱标签？

@issam9 感谢您的反馈！这两个问题是我们之前没有考虑到的。
我们仍然需要制定一个路线图和优先级，但所有的想法和输入都会有所帮助。
您对多令牌匹配的使用有何看法？
同样，您是否觉得类似POS匹配的方法可能有所帮助？
@Amelie-V 您有任何具体的问题吗？也许我们可以分享一个UI的草图以获取一些输入？

另外，请考虑包括文档和参考TextClassification用例。

我还想从用户界面提出一种半自动的标签方法。类似于每个标记的"批量模式"。
注解者搜索 -> 显示匹配的记录(标记已经用红色高亮显示)-> 选择要应用的标签 -> 然后选择要将它们应用到哪些记录上 -> 批量应用。
将其想象成“查找并替换下一个”流程。
可能会将在此过程中使用的查询保存到某个地方。

你好，@cceyda,很好的建议。所以的想法是直接将弱标签作为注解应用吗？我制作了一个类似的插件作为背景插件，可能对你的用例有帮助。我们仍在微调这个插件的工作，但请告诉我你的想法。

@davidberenstein1957 由于可能存在错误的匹配，我希望标注器能够从UI中检查弱标签(搜索过滤结果),并选择哪些可以安全地应用为注解。
因此，而不是执行“查找”->“替换(注解)所有”，您可以执行“查找”->“注解|跳过”并继续处理下一条记录。