wenmo8 发布的文章

前言

在项目开发过程中,理解数据结构和算法如同掌握盖房子的秘诀。算法不仅能帮助我们编写高效、优质的代码,还能解决项目中遇到的各种难题。

给大家推荐一个支持C#的开源免费、新手友好的数据结构与算法入门教程:Hello算法。

项目介绍

《Hello Algo》是一本开源免费、新手友好的数据结构与算法入门教程,采用了动画图解的方式,并支持一键运行代码。

该教程覆盖了 Python、Java、C++、C、C#、JS、Go、Swift、Rust、Ruby、Kotlin、TypeScript 和 Dart 等多种编程语言,每种语言都有单独的版本,并且每个版本都提供了 PDF 格式的文档。

下载开源项目后,在仓库的 codes 文件夹中可以找到对应的源代码文件,这些源代码均可一键运行。

项目特点

本项目在打造一本开源免费、新手友好的数据结构与算法入门教程。

全书采用动画图解,内容清晰易懂、学习曲线平滑,引导初学者探索数据结构与算法的知识地图。

源代码可一键运行,帮助读者在练习中提升编程技能,了解算法工作原理和数据结构底层实现。

提倡读者互助学习,欢迎大家在评论区提出问题与分享见解,在交流讨论中共同进步。

项目展示

1、内容导图

2、部分目录

3、源码示例

项目地址

Github

https://github.com/krahets/hello-algo

在线阅读

https://www.hello-algo.com/chapter_hello_algo/

下载PDF

https://github.com/krahets/hello-algo/releases

可以选择C#版本进行下载学习,具体如下图所示:

最后

如果你觉得这篇文章对你有帮助,不妨点个赞支持一下!你的支持是我继续分享知识的动力。如果有任何疑问或需要进一步的帮助,欢迎随时留言。

也可以加入微信公众号
[DotNet技术匠]
社区,与其他热爱技术的同行一起交流心得,共同成长!
优秀是一种习惯,欢迎大家留言学习!

argoworkflow-4-artifacts-archive.png

上一篇我们分析了argo-workflow 中的 artifact,包括 artifact-repository 配置以及 Workflow 中如何使用 artifact。本篇主要分析流水线 GC 以及归档,防止无限占用集群中 etcd 的空间。

1. 概述

因为 ArgoWorkflow 是用 CRD 方式实现的,不需要外部存储服务也可以正常运行:

  • 运行记录
    使用 Workflow CR 对象存储
  • 运行日志
    则存放在 Pod 中,通过 kubectl logs 方式查看
    • 因此需要保证 Pod 不被删除,否则就无法查看了

但是也正因为所有数据都存放在集群中,当数据量大之后
etcd
存储压力会很大,最终影响到集群稳定性

为了解决该问题 ArgoWorkflow 提供了归档功能,将历史数据归档到外部存储,以降低 etcd 的存储压力。

具体实现为:

  • 1)将 Workflow 对象会存储到 Postgres(或 MySQL)
  • 2)将 Pod 对应的日志会存储到 S3,因为日志数据量可能会比较大,因此没有直接存 PostgresQL。

为了提供归档功能,需要依赖两个存储服务:

  • Postgres:外部数据库,用于存储归档后的工作流记录
  • minio:提供 S3 存储,用于存储 Workflow 中生成的 artifact 以及已归档工作流的 Pod 日志

因此,如果不需要存储太多 Workflow 记录及日志查看需求的话,就不需要使用归档功能,定时清理集群中的数据即可。

2.Workflow GC

Argo Workflows 有个工作流执行记录(Workflow)的清理机制,也就是 Garbage Collect(GC)。GC 机制可以避免有太多的执行记录, 防止 Kubernetes 的后端存储 Etcd 过载。

开启

我们可以在 ConfigMap 中配置期望保留的工作执行记录数量,这里支持为不同状态的执行记录设定不同的保留数量。

首先查看 argo-server 启动命令中指定的是哪个 Configmap

# kubectl -n argo get deploy argo-workflows-server -oyaml|grep args -A 5
      - args:
        - server
        - --configmap=argo-workflows-workflow-controller-configmap
        - --auth-mode=server
        - --secure=false
        - --loglevel

可以看到,这里是用的
argo-workflows-workflow-controller-configmap
,那么修改这个即可。

配置如下:

apiVersion: v1
data:
  retentionPolicy: |
    completed: 3
    failed: 3
    errored: 3
kind: ConfigMap
metadata:
  name: argo-workflows-workflow-controller-configmap
  namespace: argo

需要注意的是,这里的清理机制会将多余的 Workflow 资源从 Kubernetes 中删除。如果希望能更多历史记录的话,建议启用并配置好归档功能。

然后重启 argo-workflow-controller 和 argo-server

kubectl -n argo rollout restart deploy argo-workflows-server
kubectl -n argo rollout restart deploy argo-workflows-workflow-controller

测试

运行多个流水线,看下是否会自动清理

for ((i=1; i<=10; i++)); do
cat <<EOF | kubectl create -f -
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hello-world-
spec:
  entrypoint: whalesay
  templates:
  - name: whalesay
    container:
      image: docker/whalesay
      command: [cowsay]
      args: ["hello world $i"]
EOF
done

创建了 10 个 Workflow,看一下运行完成后会不会自动清理掉

[root@lixd-argo archive]# k get wf
NAME                STATUS      AGE   MESSAGE
hello-world-6hgb2   Succeeded   74s
hello-world-6pl5w   Succeeded   37m
hello-world-9fdmv   Running     21s
hello-world-f464p   Running     18s
hello-world-kqwk4   Running     16s
hello-world-kxbtk   Running     18s
hello-world-p88vd   Running     19s
hello-world-q7xbk   Running     22s
hello-world-qvv7d   Succeeded   10m
hello-world-t94pb   Running     23s
hello-world-w79q6   Running     15s
hello-world-wl4vl   Running     23s
hello-world-znw7w   Running     23s

过一会再看

[root@lixd-argo archive]# k get wf
NAME                STATUS      AGE    MESSAGE
hello-world-f464p   Succeeded   102s
hello-world-kqwk4   Succeeded   100s
hello-world-w79q6   Succeeded   99s

可以看到,只保留了 3 条记录,其他的都被清理了,说明 GC 功能 ok。

3. 流水线归档

https://argo-workflows.readthedocs.io/en/stable/workflow-archive/

开启 GC 功能之后,会自动清理 Workflow 以保证 etcd 不被占满,但是也无法查询之前的记录了。

ArgoWorkflow 也提供了流水线归档功能,来解决该问题。

通过将 Workflow 记录到外部 Postgres 数据库来实现持久化,从而满足查询历史记录的需求。

部署 Postgres

首先,简单使用 helm 部署一个 AIO 的Postgres

REGISTRY_NAME=registry-1.docker.io
REPOSITORY_NAME=bitnamicharts
storageClass="local-path"
# postgres 账号的密码
adminPassword="postgresadmin"

helm install pg-aio oci://$REGISTRY_NAME/$REPOSITORY_NAME/postgresql \
--set global.storageClass=$storageClass \
--set global.postgresql.auth.postgresPassword=$adminPassword \
--set global.postgresql.auth.database=argo

配置流水线归档

同样的,在 argo 配置文件中增加 persistence 相关配置即可:

persistence: 
  archive: true
  postgresql:
    host: pg-aio-postgresql.default.svc.cluster.local
    port: 5432
    database: postgres
    tableName: argo_workflows
    userNameSecret:
      name: argo-postgres-config
      key: username
    passwordSecret:
      name: argo-postgres-config
      key: password

argo-workflows-workflow-controller-configmap 完整内容如下:

apiVersion: v1
data:
  retentionPolicy: |
    completed: 3
    failed: 3
    errored: 3
  persistence: |
    archive: true
    archiveTTL: 180d
    postgresql:
      host: pg-aio-postgresql.default.svc.cluster.local
      port: 5432
      database: argo
      tableName: argo_workflows
      userNameSecret:
        name: argo-postgres-config
        key: username
      passwordSecret:
        name: argo-postgres-config
        key: password
kind: ConfigMap
metadata:
  name: argo-workflows-workflow-controller-configmap
  namespace: argo

然后还要创建一个 secret

kubectl create secret generic argo-postgres-config -n argo --from-literal=password=postgresadmin --from-literal=username=postgres

可能还需要给 rbac,否则 Controller 无法查询 secret

kubectl create clusterrolebinding argo-workflow-controller-admin --clusterrole=admin --serviceaccount=argo:argo-workflows-workflow-controller

然后重启 argo-workflow-controller 和 argo-server

kubectl -n argo rollout restart deploy argo-workflows-server
kubectl -n argo rollout restart deploy argo-workflows-workflow-controller

在启用存档的情况下启动工作流控制器时,将在数据库中创建以下表:

  • argo_workflows
  • argo_archived_workflows
  • argo_archived_workflows_labels
  • schema_history

归档记录 GC

配置文件中的
archiveTTL
用于指定压缩到 Postgres 中的 Workflow 记录存活时间,argo Controller 会根据该配置自动删除到期的记录,若不指定该值则不会删除。

具体如下:

func (r *workflowArchive) DeleteExpiredWorkflows(ttl time.Duration) error {
	rs, err := r.session.SQL().
		DeleteFrom(archiveTableName).
		Where(r.clusterManagedNamespaceAndInstanceID()).
		And(fmt.Sprintf("finishedat < current_timestamp - interval '%d' second", int(ttl.Seconds()))).
		Exec()
	if err != nil {
		return err
	}
	rowsAffected, err := rs.RowsAffected()
	if err != nil {
		return err
	}
	log.WithFields(log.Fields{"rowsAffected": rowsAffected}).Info("Deleted archived workflows")
	return nil
}

不过删除任务默认每天执行一次,因此就算配置为 1m 分钟也不会立即删除。

func (wfc *WorkflowController) archivedWorkflowGarbageCollector(stopCh <-chan struct{}) {
	defer runtimeutil.HandleCrash(runtimeutil.PanicHandlers...)

	periodicity := env.LookupEnvDurationOr("ARCHIVED_WORKFLOW_GC_PERIOD", 24*time.Hour)
	if wfc.Config.Persistence == nil {
		log.Info("Persistence disabled - so archived workflow GC disabled - you must restart the controller if you enable this")
		return
	}
	if !wfc.Config.Persistence.Archive {
		log.Info("Archive disabled - so archived workflow GC disabled - you must restart the controller if you enable this")
		return
	}
	ttl := wfc.Config.Persistence.ArchiveTTL
	if ttl == config.TTL(0) {
		log.Info("Archived workflows TTL zero - so archived workflow GC disabled - you must restart the controller if you enable this")
		return
	}
	log.WithFields(log.Fields{"ttl": ttl, "periodicity": periodicity}).Info("Performing archived workflow GC")
	ticker := time.NewTicker(periodicity)
	defer ticker.Stop()
	for {
		select {
		case <-stopCh:
			return
		case <-ticker.C:
			log.Info("Performing archived workflow GC")
			err := wfc.wfArchive.DeleteExpiredWorkflows(time.Duration(ttl))
			if err != nil {
				log.WithField("err", err).Error("Failed to delete archived workflows")
			}
		}
	}
}

需要设置环境变量
ARCHIVED_WORKFLOW_GC_PERIOD
来调整该值,修改 argo-workflows-workflow-controller 增加 env,就像这样:

        env:
        - name: ARCHIVED_WORKFLOW_GC_PERIOD
          value: 1m

测试

接下来创建 Workflow 看下是否测试

for ((i=1; i<=10; i++)); do
cat <<EOF | kubectl create -f -
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hello-world-
spec:
  entrypoint: whalesay
  templates:
  - name: whalesay
    container:
      image: docker/whalesay
      command: [cowsay]
      args: ["hello world $i"]
EOF
done

查看下是 postgres 中是否生成归档记录

export POSTGRES_PASSWORD=postgresadmin

kubectl run postgresql-dev-client --rm --tty -i --restart='Never' --namespace default --image docker.io/bitnami/postgresql:14.1.0-debian-10-r80 --env="PGPASSWORD=$POSTGRES_PASSWORD" --command -- psql --host pg-aio-postgresql -U postgres -d argo -p 5432

按 Enter 进入 Pod 后直接查询即可

# 查询表
argo-# \dt
                     List of relations
 Schema |              Name              | Type  |  Owner
--------+--------------------------------+-------+----------
 public | argo_archived_workflows        | table | postgres
 public | argo_archived_workflows_labels | table | postgres
 public | argo_workflows                 | table | postgres
 public | schema_history                 | table | postgres
(4 rows)

# 查询记录
argo=# select name,phase from argo_archived_workflows;
       name        |   phase
-------------------+-----------
 hello-world-s8v4f | Succeeded
 hello-world-6pl5w | Succeeded
 hello-world-qvv7d | Succeeded
 hello-world-vgjqr | Succeeded
 hello-world-g2s8f | Succeeded
 hello-world-jghdm | Succeeded
 hello-world-fxtvk | Succeeded
 hello-world-tlv9k | Succeeded
 hello-world-bxcg2 | Succeeded
 hello-world-f6mdw | Succeeded
 hello-world-dmvj6 | Succeeded
 hello-world-btknm | Succeeded
(12 rows)

# \q 退出
argo=# \q

可以看到,Postgres 中已经存储好了归档的 Workflow,这样需要查询历史记录时到 Postgres 查询即可。

将 archiveTTL 修改为 1 分钟,然后重启 argo,等待 1 至2 分钟后,再次查看

argo=#  select name,phase from argo_archived_workflows;
 name | phase
------+-------
(0 rows)

argo=#

可以看到,所有记录都因为 TTL 被清理了,这样也能保证外部 Postgres 中的数据不会越累积越多。

4. Pod 日志归档

https://argo-workflows.readthedocs.io/en/stable/configure-archive-logs/

流水线归档实现了流水线持久化,即使把集群中的 Workflow 对象删除了,也可以从 Postgres 中查询到记录以及状态等信息。

但是流水线执行的日志却分散在对应 Pod 中的,如果 Pod 被删除了,日志就无法查看了,因此我们还需要做日志归档。

配置 Pod 归档

全局配置

在 argo 配置文件中开启 Pod 日志归档并配置好 S3 信息。

具体配置如下:

和第三篇配置的 artifact 一样,只是多了一个
archiveLogs: true

artifactRepository:
  archiveLogs: true
  s3:
    endpoint: minio.default.svc:9000
    bucket: argo
    insecure: true
    accessKeySecret:
      name: my-s3-secret
      key: accessKey
    secretKeySecret:
      name: my-s3-secret
      key: secretKey

完整配置如下:

apiVersion: v1
data:
  retentionPolicy: |
    completed: 3
    failed: 3
    errored: 3
  persistence: |
    archive: true
    postgresql:
      host: pg-aio-postgresql.default.svc.cluster.local
      port: 5432
      database: argo
      tableName: argo_workflows
      userNameSecret:
        name: argo-postgres-config
        key: username
      passwordSecret:
        name: argo-postgres-config
        key: password
  artifactRepository: |
    archiveLogs: true
    s3:
      endpoint: minio.default.svc:9000
      bucket: argo
      insecure: true
      accessKeySecret:
        name: my-s3-secret
        key: accessKey
      secretKeySecret:
        name: my-s3-secret
        key: secretKey
kind: ConfigMap
metadata:
  name: argo-workflows-workflow-controller-configmap
  namespace: argo

注意:根据第三篇分析 artifact,argo 中关于 artifactRepository 的信息包括三种配置方式:

  • 1)全局配置
  • 2)命名空间默认配置
  • 3)Workflow 中指定配置

这里是用的全局配置方式,如果 Namespace 级别或者 Workflow 级别也配置了 artifactRepository 并指定了不开启日志归档,那么也不会归档的。

然后重启 argo

kubectl -n argo rollout restart deploy argo-workflows-server
kubectl -n argo rollout restart deploy argo-workflows-workflow-controller

在 Workflow & template 中配置

配置整个工作流都需要归档

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: archive-location-
spec:
  archiveLogs: true
  entrypoint: whalesay
  templates:
  - name: whalesay
    container:
      image: docker/whalesay:latest
      command: [cowsay]
      args: ["hello world"]

配置工作流中的某一个 template 需要归档。

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: archive-location-
spec:
  entrypoint: whalesay
  templates:
  - name: whalesay
    container:
      image: docker/whalesay:latest
      command: [cowsay]
      args: ["hello world"]
    archiveLocation:
      archiveLogs: true

小结

3 个地方都可以配置是否归档,就还挺麻烦的,根据官方文档,各个配置优先级如下:

workflow-controller config (on) > workflow spec (on/off) > template (on/off)

Controller Config Map Workflow Spec Template are we archiving logs?
true true true true
true true false true
true false true true
true false false true
false true true true
false true false false
false false true true
false false false false

对应的代码实现:

// IsArchiveLogs determines if container should archive logs
// priorities: controller(on) > template > workflow > controller(off)
func (woc *wfOperationCtx) IsArchiveLogs(tmpl *wfv1.Template) bool {
	archiveLogs := woc.artifactRepository.IsArchiveLogs()
	if !archiveLogs {
		if woc.execWf.Spec.ArchiveLogs != nil {
			archiveLogs = *woc.execWf.Spec.ArchiveLogs
		}
		if tmpl.ArchiveLocation != nil && tmpl.ArchiveLocation.ArchiveLogs != nil {
			archiveLogs = *tmpl.ArchiveLocation.ArchiveLogs
		}
	}
	return archiveLogs
}

建议配置全局的就行了。

测试

接下来创建 Workflow 看下是否测试

cat <<EOF | kubectl create -f -
apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: hello-world-
spec:
  entrypoint: whalesay
  templates:
  - name: whalesay
    container:
      image: docker/whalesay
      command: [cowsay]
      args: ["hello world"]
EOF

等待 Workflow 运行完成

# k get po
NAME                     READY   STATUS      RESTARTS   AGE
hello-world-6pl5w        0/2     Completed   0          53s
# k get wf
NAME                STATUS      AGE   MESSAGE
hello-world-6pl5w   Succeeded   55s

到 S3 查看是否有日志归档文件

argo-archive-log.png

可以看到,在指定 bucket 里已经存储了一个日志文件,以
$bucket/$workflowName/$stepName
格式命名。

正常一个 Workflow 都会有多个 Step,每一个 step 分一个目录存储

内容就是 Pod 日志,具体如下:

 _____________ 
< hello world >
 ------------- 
    \
     \
      \     
                    ##        .            
              ## ## ##       ==            
           ## ## ## ##      ===            
       /""""""""""""""""___/ ===        
  ~~~ {~~ ~~~~ ~~~ ~~~~ ~~ ~ /  ===- ~~~   
       \______ o          __/            
        \    \        __/             
          \____\______/   

5. 小结


【ArgoWorkflow 系列】
持续更新中,搜索公众号【
探索云原生
】订阅,阅读更多文章。


总结一下,本文主要分析了以下 3 部分内容:

  • 1)开启 GC,自动清理运行完成的 Workflow 记录,避免占用 etcd 空间
  • 2)开启流水线归档,将 Workflow 记录存储到外部 Postgres,便于查询历史记录
  • 3)开启 Pod 日志归档,将流水线每一步 Pod 日志记录到 S3,便于查询,否则 Pod 删除就无法查询了

生产使用,一般都建议开启相关的清理和归档功能,如果全存储到 etcd,难免会影响到集群性能和稳定性。

现实世界的数据通常表现为长尾分布,常跨越多个类别。这种复杂性突显了内容理解的挑战,特别是在需要长尾多标签图像分类(
LTMLC
)的场景中。在这些情况下,不平衡的数据分布和多物体识别构成了重大障碍。为了解决这个问题,论文提出了一种新颖且有效的
LTMLC
方法,称为类别提示精炼特征学习(
CPRFL
)。该方法从预训练的
CLIP
嵌入初始化类别提示,通过与视觉特征的交互解耦类别特定的视觉表示,从而促进了头部类和尾部类之间的语义关联建立。为了减轻视觉-语义领域的偏差,论文设计了一种渐进式双路径反向传播机制,通过逐步将上下文相关的视觉信息纳入提示来精炼提示。同时,精炼过程在精炼提示的指导下促进了类别特定视觉表示的渐进纯化。此外,考虑到负样本与正样本的不平衡,采用了非对称损失作为优化目标,以抑制所有类别中的负样本,并可能提升头部到尾部的识别性能。

来源:晓飞的算法工程笔记 公众号,转载请注明出处

论文: Category-Prompt Refined Feature Learning for Long-Tailed Multi-Label Image Classification

Introduction


随着深度网络的快速发展,近年来计算机视觉领域取得了显著的进展,尤其是在图像分类任务中。这一进展在很大程度上依赖于许多主流的平衡基准(例如
CIFAR

ImageNet ILSVRC

MS COCO
),这些基准具有两个关键特征:
1
)它们提供了在所有类别之间相对平衡且数量充足的样本,
2
)每个样本仅属于一个类别。然而,在实际应用中,不同类别的分布往往呈现长尾分布模式,深度网络往往在尾部类别上表现不佳。同时,与经典的单标签分类不同,实际场景中图像通常与多个标签相关联,这增加了任务的复杂性和挑战。为了应对这些问题,越来越多的研究集中在长尾多标签图像分类(
LTMLC
)问题上。

由于尾部类别的样本相对稀少,解决长尾多标签图像分类(
LTMLC
)问题的主流方法主要集中在通过采用各种策略来解决头部与尾部的不平衡问题,例如对每个类别的样本数量进行重采样、为不同类别重新加权损失、以及解耦表示学习和分类头的学习。尽管这些方法做出了重要贡献,但它们通常忽略了两个关键方面。首先,在长尾学习中,考虑头部和尾部类别之间的语义相关性至关重要。利用这种相关性可以在头部类别的支持下显著提高尾部类别的性能。其次,实际世界中的图像通常包含多种对象、场景或属性,这增加了分类任务的复杂性。上述方法通常从全局角度考虑提取图像的视觉表示。然而,这种全局视觉表示包含了来自多个对象的混合特征,这阻碍了对每个类别的有效特征分类。因此,如何在长尾数据分布中探索类别之间的语义相关性,并提取局部类别特定特征,仍然是一个重要的研究领域。

最近,视觉-语言预训练(
VLP
)模型已成功适应于各种下游视觉任务。例如,
CLIP
在数十亿对图像-文本样本上进行预训练,其文本编码器包含了来自自然语言处理(
NLP
)语料库的丰富语言知识。文本编码器在编码文本模态中的语义上下文表示方面展示了巨大的潜力。因此,可以利用
CLIP
的文本嵌入表示来编码头部和尾部类别之间的语义相关性。此外,在许多研究中,
CLIP
的文本嵌入已成功作为语义提示,用于将局部类别特定的视觉表示与全局混合特征解耦。

为了应对长尾多标签分类(
LTMLC
)固有的挑战,论文提出了一种新颖且有效的方法,称为类别提示精炼特征学习(
Category-Prompt Refined Feature Learning

CPRFL
)。
CPRFL
利用
CLIP
的文本编码器的强大的语义表示能力提取类别语义,从而建立头部和尾部类别之间的语义相关性。随后,提取的类别语义用于初始化所有类别的提示,这些提示与视觉特征交互,以辨别与每个类别相关的上下文视觉信息。

这种视觉-语义交互可以有效地将类别特定的视觉表示从输入样本中解耦,但这些初始提示缺乏视觉上下文信息,导致在信息交互过程中语义和视觉领域之间存在显著的数据偏差。本质上,初始提示可能不够精准,从而影响类别特定视觉表示的质量。为了解决这个问题,论文引入了一种渐进式双路径反向传播(
progressive Dual-Path Back-Propagation
)机制来迭代精炼提示。该机制逐步将与上下文相关的视觉信息积累到提示中。同时,在精炼提示的指导下,类别特定的视觉表示得到净化,从而提高其相关性和准确性。

最后,为了进一步解决多类别中固有的负样本与正样本不平衡问题,论文引入了在这种情况下常用的重新加权(
Re-Weighting
,
RW
)策略。具体来说,采用了非对称损失(
Asymmetric Loss

ASL
)作为优化目标,有效抑制了所有类别中的负样本,并可能改善
LTMLC
任务中头部与尾部类别的性能。

论文贡献总结如下:

  1. 提出了一种新颖的提示学习方法,称为类别提示精炼特征学习(
    CPRFL
    ),用于长尾多标签图像分类(
    LTMLC
    )。
    CPRFL
    利用
    CLIP
    的文本编码器提取类别语义,充分发挥其强大的语义表示能力,促进头部和尾部类别之间的语义关联的建立。提取的类别语义作为类别提示,用于实现类别特定视觉表示的解耦。这是首次利用类别语义关联来缓解
    LTMLC
    中的头尾不平衡问题,提供了一种针对数据特征量身定制的开创性解决方案。

  2. 设计了一种渐进式双路径反向传播机制,旨在通过在视觉-语义交互过程中逐步将与上下文相关的视觉信息融入提示中,从而精炼类别提示。通过采用一系列双路径梯度反向传播,有效地抵消了初始提示带来的视觉-语义领域偏差。同时,精炼过程促进了类别特定视觉表示的逐步净化。

  3. 在两个
    LTMLC
    基准测试上进行了实验,包括公开可用的数据集
    COCO-LT

    VOC-LT
    。大量实验不仅验证了方法的有效性,还突显了其相较于最近先进方法的显著优越性。

Methods


Overview

CPRFL
方法包括两个子网络,即提示初始化(
PI
)网络和视觉-语义交互(
VSI
)网络。首先,利用预训练的
CLIP
的文本嵌入来初始化
PI
网络中的类别提示,利用类别语义编码不同类别之间的语义关联。随后,这些初始化的提示通过
VSI
网络中的
Transformer
编码器与提取的视觉特征进行交互。这个交互过程有助于解耦类别特定的视觉表示,使框架能够辨别与每个类别相关的上下文相关的视觉信息。最后,在类别层面计算类别特定特征与其对应提示之间的相似性,以获得每个类别的预测概率。为了减轻视觉-语义领域偏差,采用了一个逐步的双路径反向传播机制,由类别提示学习引导,以细化提示并在训练迭代中逐步净化类别特定的视觉表示。为进一步解决负样本与正样本的不平衡问题,采用了重加权策略(即非对称损失(
ASL
)),这有助于抑制所有类别中的负样本。

  • Feature Extraction

给定来自数据集
\(D\)
的输入图像
\(x\)
,首先利用一个主干网络提取局部图像特征
\(f_{loc}^x \in \mathbb{R}^{h \times w \times d_0}\)
,其中
\(d_0,h,w\)
分别表示通道数、高度和宽度。论文采用了如
ResNet-101
的卷积网络,并通过去除最后的池化层来获取局部特征。之后,添加一个线性层
\(\varphi\)
,将特征从维度
\(d_0\)
映射到维度
\(d\)
,以便将其投影到一个视觉-语义联合空间,从而匹配类别提示的维度:

\[\begin{equation}
\mathcal{F} = \varphi(f_{loc}^x) = \{f_1,f_2,...,f_v\} \in \mathbb{R}^{v \times d}, v = h \times w.
\label{eq:1}
\end{equation}
\]

利用局部特征,我们在它们与初始类别提示之间进行视觉-语义信息交互,以辨别类别特定的视觉信息。

  • Semantic Extraction

形式上,预训练的
CLIP
包括一个图像编码器
\(f(\bullet)\)
和一个文本编码器
\(g(\bullet)\)
。为了论文的目的,仅利用文本编码器来提取类别语义。具体来说,采用一个经典的预定义模板 "
a photo of a
[
CLASS
]" 作为文本编码器的输入文本。然后,文本编码器将输入文本(类别
\(i\)

\(i=1,...,c\)
)映射到文本嵌入
\(\mathcal{W} = g(i) =\{w_1,w_2,...,w_c\}\in \mathbb{R}^{c \times m}\)
,其中
\(c\)
表示类别数,
\(m\)
表示嵌入的维度长度。提取的文本嵌入作为初始化类别提示的类别语义。

Category-Prompt Initialization

为了弥合语义领域和视觉领域之间的差距,近期的研究尝试使用线性层将语义词嵌入投影到视觉-语义联合空间。论文选择了非线性结构来处理来自预训练
CLIP
文本嵌入的类别语义,而不是直接使用线性层进行投影。这种方法能够实现从语义空间到视觉-语义联合空间的更复杂的投影。

具体来说,论文设计了一个提示初始化(
PI
)网络,该网络由两个全连接层和一个非线性激活函数组成。通过
PI
网络执行的非线性变换,将预训练
CLIP
的文本嵌入
\(\mathcal{W}\)
映射到初始类别提示
\(\mathcal{P} = \{p_1,p_2,...,p_c\}\in \mathbb{R}^{c \times d}\)

\[\begin{equation}
\mathcal{P} = GELU(\mathcal{W}W_1+b_1)W_2+b_2,
\label{eq:2}
\end{equation}
\]

其中,
\(W_1\)

\(W_2\)

\(b_1\)

\(b_2\)
分别表示两个线性层的权重矩阵和偏置向量,而
\(GELU\)
表示非线性激活函数。这里,
\(W_1 \in \mathbb{R}^{m \times t}\)

\(W_2 \in \mathbb{R}^{t \times d}\)

\(t = \tau \times d\)

\(\tau\)
是控制隐藏层维度的扩展系数。通常情况下,
\(\tau\)
被设置为
0.5

PI
网络在从预训练
CLIP
的文本编码器中提取类别语义方面发挥了至关重要的作用,利用其强大的语义表示能力,在不依赖真实标签的情况下建立不同类别之间的语义关联。通过用类别语义初始化类别提示,
PI
网络促进了从语义空间到视觉-语义联合空间的投影。此外,
PI
网络的非线性设计增强了提取类别提示的视觉-语义交互能力,从而改善了后续的视觉-语义信息交互。

Visual-Semantic Information Interaction

随着
Transformer
在计算机视觉领域的广泛应用,近期的研究展示了典型注意力机制在增强视觉-语义跨模态特征交互方面的能力,这激励论文设计了一个视觉-语义交互(
VSI
)网络。该网络包含一个
Transformer
编码器,以初始类别提示和视觉特征作为输入。
Transformer
编码器执行视觉-语义信息交互,以辨别与每个类别相关的上下文特定视觉信息。这个交互过程有效地解耦了类别特定的视觉表示,从而促进了每个类别的更好特征分类。

为了促进类别提示与视觉特征之间的视觉-语义信息交互,将初始类别提示
\(\mathcal{P} \in \mathbb{R}^{c \times d}\)
与视觉特征
\(\mathcal{F} \in \mathbb{R}^{v \times d}\)
进行连接,形成一个组合嵌入集
\(Z = (\mathcal{F},\mathcal{P}) \in \mathbb{R}^{(v+c) \times d}\)
,输入到
VSI
网络中进行视觉-语义信息交互。在
VSI
网络中,每个嵌入
\(z_i \in Z\)
通过
Transformer
编码器固有的多头自注意力机制进行计算和更新。值得注意的是,仅关注更新类别提示
\(\mathcal{P}\)
,因为这些提示代表了类别特定视觉表示的解耦部分。注意力权重
\(\alpha_{ij}^p\)
和随后的更新过程计算如下:

\[\begin{equation}
\alpha_{ij}^p = softmax\left((W_qp_i)^T(W_kz_i)/\sqrt{d}\right),
\label{eq:3}
\end{equation}
\]

\[\begin{equation}
\bar{p}_i = \sum_{j=1}(\alpha_{ij}^pW_vz_j),
\label{eq:4}
\end{equation}
\]

\[\begin{equation}
p_i' = GELU(\bar{p}_iW_r+b_3)W_o+b_4,
\end{equation}
\]

其中,
\(W_q, W_k, W_v\)
分别是查询、键和值的权重矩阵,
\(W_r, W_o\)
是变换矩阵,
\(b_3, b_4\)
是偏置向量。为了简化
VSI
网络的复杂度,选择了单层
Transformer
编码器而不是堆叠层。
VSI
网络的输出结果和类别特定的视觉特征分别记作
\(Z' = \{f_1', f_2', ..., f_v', p_1', p_2', ..., p_c'\}\)

\(\mathcal{P}' = \{p_1', p_2', ..., p_c'\}\)
。在自注意力机制下,每个类别提示嵌入综合考虑了其对所有局部视觉特征和其他类别提示嵌入的注意力。这种综合注意力机制有效地辨别了样本中的上下文相关视觉信息,从而实现了类别特定视觉表示的解耦。

Category-Prompt Refined Feature Learning

在通过
VSI
网络实现视觉特征与初始提示的交互后,得到的输出
\(\mathcal{P}'\)
作为分类的类别特定特征。在传统的基于
Transformer
的方法中,从
Transformer
获得的具体输出特征通常通过线性层投影到标签空间,用于最终分类。与这些方法不同,将类别提示
\(\mathcal{P}\)
作为分类器,并计算类别特定特征与类别提示之间的相似性,以在特征空间内进行分类。类别
\(i\)
的分类概率
\(s_i\)
可以通过以下计算:

\[\begin{equation}
s_i = sigmoid(p_i' \cdot p_i).
\label{eq:6}
\end{equation}
\]

在多标签设置中,由于数据特性的独特性,需要计算每个类别的类别特定特征向量与相应提示向量之间的点积相似度来确定概率(
softmax
一下),这种计算方法体现了绝对相似性。而论文偏离了传统的相似性模式,而是使用类别特定特征向量与所有提示向量之间的相对测量。这种做法的原因在于减少了计算冗余,因为计算每个类别的特征向量与无关类别提示之间的相似度是不必要的。

初始提示缺乏关键的视觉上下文信息,导致在信息交互过程中语义域与视觉域之间存在显著的数据偏差。这种差异导致初始提示不准确,从而影响类别特定视觉表示的质量。为了解决这个问题,论文引入了一种由类别提示学习引导的渐进式双路径反向传播机制。该机制在模型训练过程中涉及两个梯度优化路径(如图
2a
所示):一条通过
VSI
网络,另一条直接到
PI
网络。前者路径还优化
VSI
网络,以增强其视觉语义信息交互的能力。通过采用一系列双路径梯度反向传播,提示在训练迭代中逐渐得到优化,从而逐步积累与上下文相关的视觉信息。同时,优化后的提示指导生成更准确的类别特定视觉表示,从而实现类别特定特征的渐进净化。论文将这一整个过程称为“提示精炼特征学习”,反复进行直到收敛,如图
2b
所示。

Optimization

为了进一步解决多类别中固有的负样本与正样本不平衡问题,论文整合了在这种情况下常用的重新加权(
Re-Weighting
,
RW
)策略。具体而言,采用不对称损失(
Asymmetric Loss
,
ASL
)作为优化目标。
ASL
是一种焦点损失(
focal loss
)的变体,对正样本和负样本使用不同的
\(\gamma\)
值。给定输入图像
\(x_i\)
,模型预测其最终类别概率
\(S_i = \{s_1^i,s_2^i,...,s_c^i\}\)
,其真实标签为
\(Y_i = \{y_1^i,y_2^i,...,y_c^i\}\)

使用
ASL
训练整个框架,如下所示:

\[\begin{equation}
\mathcal{L}_{cls} = \mathcal{L}_{ASL} = \sum_{x_i \in X}\sum_{j=1}^c
\begin{cases}
(1-s_j^i)^{\gamma^{+}}log(s_j^i),&s_j^i=1,\\
(\tilde{s}_j^i)^{\gamma^{-}}log(1-\tilde{s}_j^i),&s_j^i=0,\\
\end{cases}
\label{eq:7}
\end{equation}
\]

其中,
\(c\)
是类别的数量。
\(\tilde{s}_j^i\)

ASL
中的硬阈值,表示为
\(\tilde{s}_j^i = \max(s_j^i - \mu, 0)\)

\(\mu\)
是一个用于过滤低置信度负样本的阈值。默认情况下,设置
\(\gamma^{+} = 0\)

\(\gamma^{-} = 4\)
。在论文的框架中,
ASL
有效地抑制了所有类别中的负样本,可能改善了
LTMLC
任务中的头尾类别性能。

Experiments




如果本文对你有帮助,麻烦点个赞或在看呗~
更多内容请关注 微信公众号【晓飞的算法工程笔记】

work-life balance.

经过前面章节的学习,可以说大家已经算Redis开发入门了。已经可以去到项目上磨砺了。

但是今天我还想和大家分享一章:封装自己的Redis C#库,然后打包成Nuget包。

首先要说明的是:不是要自己开发一个Redis客户端库,而是基于上篇文章中介绍的6大库,做一个简单封装,真的很简单的那种,就是包个壳子。

再来说说为什么要做这个事情。

01
、原因

1.可测试

我希望代码是以服务的方式注入到程序中,而不是静态方法的方式去调用。使用依赖注入来提供服务使得程序可测试性增强,如果做单元测试,依赖注入的服务很容易通过mock来测试,而静态方法往往很难被模拟,测试起来很不灵活;

2.解耦

对于一个系统来说会使用到各种技术来达到某种能力,实现一个功能可能会有很多种方法,我们在意的是实现这个功能,而不是你用了什么方法。回到主题,我们需要的是使用Redis来实现业务功能,而具体用那个客户端库并不重要。

再举个例子比如今天我们选择了ServiceStack.Redis库接过遇到问题我们解决不了怎么办?难道业务不做了?不可能吧!而恰巧这个时候CSRedisCore库可以解决,你会怎么选?

这时候可能会想换的成本有多大?两种库方法名不统一,功能也不一样,如果系统中到处散落Redis方法调用,这可怎么换啊。

试想如果我们封装了一层,提供了一组接口,打包成Nuget包,这个时候大家用的就是这个Nuget包,而我们只需要把Nuget包里用ServiceStack.Redis实现的方法换成用CSRedisCore实现一下,大家直接更新一下Nuget包,可能一行代码都不用改就完成了替换。

因为我们依赖的是我们自己封装的接口,而不是具体Redis客户端库,因此可以解耦轻松替换。

3.扩展

Redis的原生功能可以理解为基础功能,表明Redis有这种能力。但是我们怎么使用,怎么更好的发挥它的价值,这就是我们自己能力的体现了。

大家相过想过没有,为什么有的库商业化做的特别好,特别简单容易上手。商业化好说明提供的服务好,也就是说明它能帮你做很多事情,它在原生功能上加了很多自己的创作。

项目做多了,我们自己也会遇到一些相似的功能,如果这个时候我们想把这些相似功能封装一下,要放哪里呢?怎么给别人用?如果我们遇到一个功能现有库都没有相应能力,需要我们基于原生自己开发实现又应该在哪做呢?

这些功能积累的多了总要有个地方放吧,而这时如果我们自己封装了一层,放哪的问题是不是一下子就解决了,说不定做着做着就成了一个产品了呢。

不知道到这里,大家有没有感觉思路一下子被打开了。可能我们没写几行代码,但是这个格局一下子就打开了,而这几行代码也可能产生意想不到的收获,可能是无限可能,也可能就是你实现自己Redis客户端库的开端。

当然这也是我自己对编码,对封装的个人拙见。说这么多也是希望可以给大家一些帮助。

02
、实现

下面闲话少说进入正题,如果来封装呢?

我们先梳理一下大致思路:

1.我们需要一个接口,里面包含:原库原生能力Client、其他我们自定义功能。

2.一个入口,别人要用,总要有个入口吧。

其实要求就这么简单。

下面我们就以封装CSRedisClient为例,首先定义IRedisService接口,里面包含Client字段以及两个演示的自定义方法

using CSRedis;
namespace Redis.RedisExtension
{
    public interface IRedisService
    {
        /// <summary>
        /// RedisClient
        /// </summary>
        /// <returns></returns>
        CSRedisClient Client { get; }
        #region 自定义方法
        /// <summary>
        /// 获取指定 key 的值
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <param name="key"></param>
        /// <returns></returns>
        T Get<T>(string key);
        /// <summary>
        /// 获取指定 key 的值
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <param name="key"></param>
        /// <returns></returns>
        Task<T> GetAsync<T>(string key);
        #endregion
    }
}

然后需要实现IRedisService,同时以CSRedisClient为构造函数入参,具体代码如下:

using CSRedis;
namespace Redis.RedisExtension
{
    public class RedisService : IRedisService
    {
        /// <summary>
        /// 构造函数
        /// </summary>
        /// <param name="redisClient"></param>
        public RedisService(CSRedisClient redisClient)
        {
            Client = redisClient;
        }
        /// <summary>
        /// CSRedis
        /// </summary>
        /// <returns></returns>
        public CSRedisClient Client { get; }
        #region 自定义方法
        /// <summary>
        /// 获取指定 key 的值
        /// </summary>
        /// <returns></returns>
        public T Get<T>(string key)
        {
            return Client.Get<T>(key);
        }
        /// <summary>
        /// 获取指定 key 的值
        /// </summary>
        /// <returns></returns>
        public Task<T> GetAsync<T>(string key)
        {
            return Client.GetAsync<T>(key);
        }
        #endregion
    }
}

到这里第一个问题就解决了,对于第二个问题我们,我们可以对IServiceCollection进行扩展添加启动扩展方法AddRedisClientSetup,具体代码如下:

using CSRedis;
using Microsoft.Extensions.Configuration;
using Microsoft.Extensions.DependencyInjection;
namespace Redis.RedisExtension
{
    public static class RedisSetupExtensions
    {
        /// <summary>
        /// Redis客户端启动项
        /// </summary>
        /// <param name="services"></param>
        /// <returns></returns>
        public static IServiceCollection AddRedisClientSetup(this IServiceCollection services)
        {
            services.AddSingleton<CSRedisClient>(serviceProvider =>
            {
                var configuration = serviceProvider.GetRequiredService<IConfiguration>();
                var setting = configuration["RedisConnectionString"];
                return new CSRedisClient(setting);
            });
            services.AddSingleton<IRedisService, RedisService>();
            return services;
        }
        /// <summary>
        /// Redis客户端启动项
        /// </summary>
        /// <param name="services"></param>
        /// <param name="connectionString"></param>
        /// <returns></returns>
        public static IServiceCollection AddRedisClientSetup(this IServiceCollection services, string connectionString)
        {
            services.AddSingleton<CSRedisClient>(serviceProvider =>
            {
                return new CSRedisClient(connectionString);
            });
            services.AddSingleton<IRedisService, RedisService>();
            return services;
        }
    }
}

为什么要提供两个重载方法,因为如果用户基于我们的约定,在配置文件中以"RedisConnectionString"命名Redis连接字符串,用户直接调用AddRedisClientSetup()方法即可完成Redis启动,但是可能因为各种原因用户没法遵守约定,因此我们也要提供一个用户可以指定Redis连接字符串方法的入口。

下面我们就用基于约定的方式,在配置文件中加入以下配置:

{
  "RedisConnectionString": "127.0.0.1:6379"
}

然后使用Client.Set方法设置key1,再用自定义方法Get
方法读取,代码如下:

public static void Run()
{
    var configuration = new ConfigurationBuilder()
        .SetBasePath(AppContext.BaseDirectory)
        .AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
        .Build();
    var services = new ServiceCollection();
    services.AddSingleton<IConfiguration>(configuration);
    services.AddRedisClientSetup();
    var redisService = services.BuildServiceProvider().GetService<IRedisService>();
    var setResult = redisService.Client.Set("key1", "value1");
    Console.WriteLine($"redisService.Client.Set(\"key1\",\"value1\")执行结果:{setResult}");
    var value = redisService.Get<string>("key1");
    Console.WriteLine($"redisService.Get<string>(\"key1\")执行结果:{value}");
    redisService.Client.Del("key1");
}

执行结果如下:

是不是很简单,然后我们只需要把上面三个文件IRedisService、RedisService、RedisSetupExtensions放到单独的类库中,然后打包发布成Nuget包,就可以给大家一起用啦,今天我这边就不发布Nuget包了,后面会有相关的计划,到时候再细聊。


:测试方法代码以及示例源码都已经上传至代码库,有兴趣的可以看看。
https://gitee.com/hugogoos/Planner

1. Performance API 的用处

Performance API
是浏览器中内置的一组工具,用于测量和记录页面加载和执行过程中的各类性能指标。它的主要用处包括:

  • 监控页面资源加载
    :跟踪页面中的资源(如 CSS、JavaScript、图片)的加载时间。
  • 分析页面加载时间
    :从导航到页面完全渲染的所有时间点。
  • 衡量用户交互性能
    :测量用户点击、输入等操作的响应时间。
  • 优化性能瓶颈
    :通过标记特定的代码片段和事件,精准定位性能瓶颈。

这些数据帮助开发者更好地理解页面表现,进而对性能进行优化和改进。

2. Performance API 常用的 API

在使用 Performance API 时,以下几个 API 是开发者最常用的工具:
getEntries()

mark()
、以及
PerformanceObserver
。这些 API 提供了从获取性能数据到观察性能事件的全面能力。

2.1 performance.getEntries()

performance.getEntries()
是 Performance API 提供的一个方法,它返回所有的性能条目(entries)。这些条目记录了从页面加载到当前时刻,各类资源的加载和交互的性能数据。性能条目包括页面加载资源(如 CSS、JS、图片等)以及自定义的事件标记。

//获取页面中所有资源的性能条目
const entries =performance.getEntries();
console.log(entries);

通过
getEntries()
,你可以获取资源加载时间、开始时间、结束时间等详细信息。这对于了解页面中每个资源的加载耗时十分有帮助。

2.2 entries 的类型

getEntries()
返回的每个性能条目对象都属于以下几种类型,开发者可以根据需要筛选和分析不同类型的数据:

  • navigation
    :与页面导航相关的条目,通常用于分析页面加载的时间点。
  • resource
    :所有通过网络请求加载的资源条目,包括 JS、CSS、图片等。
  • mark
    :开发者自定义的标记,用于记录特定事件的开始或结束。
  • measure
    :通过
    performance.measure()
    生成的条目,用于测量两个标记之间的时间间隔。

例如,使用
performance.getEntriesByType('resource')
可以只获取资源加载的性能数据:

//获取所有资源加载的性能条目
const resourceEntries = performance.getEntriesByType('resource');
console.log(resourceEntries);

通过这种方式,开发者可以轻松获取页面资源的加载时间及其详情。

2.3 performance.mark()

performance.mark()
是 Performance API 提供的一个方法,允许开发者在代码中手动创建标记。这些标记可以用于记录特定事件的发生时间,从而在分析性能时,更加精确地掌握代码中某个关键操作的时机。

//创建自定义标记
performance.mark('start-task');//执行某个任务
doSomething();//创建结束标记
performance.mark('end-task');//测量开始和结束之间的时间
performance.measure('Task Duration', 'start-task', 'end-task');

mark()
非常适合用于衡量应用程序中某段代码的执行时间,与
measure()
一起使用可以提供更加详细的性能分析。

2.4 PerformanceObserver

PerformanceObserver
是 Performance API 的一个高级特性,它可以监听性能事件的发生,并在事件触发时执行回调。这种观察模式可以帮助开发者实时监控页面中的资源加载、导航和其他性能相关的事件。

//创建 PerformanceObserver 实例,监听资源加载的事件
const observer = new PerformanceObserver((list) =>{const entries =list.getEntries();
entries.forEach(entry
=>{
console.log(`${entry.name}: ${entry.duration}ms`);
});
});
//监听资源类型的性能条目 observer.observe({ entryTypes: ['resource'] });

通过
PerformanceObserver
,你可以监听特定类型的性能条目,如
resource

mark
,并实时分析其数据。对于监控资源加载、关键操作或用户交互时的性能表现非常有用。

总结

Performance API 是前端开发者进行性能监控的强大工具,它提供了对页面加载、资源加载以及用户交互的详细分析能力。常用的 API,如
getEntries()

mark()
、以及
PerformanceObserver
,可以帮助开发者实时获取和分析性能数据。

通过合理地使用 Performance API,你可以更好地了解页面中各类操作的性能表现,从而有效地优化 Web 应用的加载速度和用户体验。