尧图网络 高端网站定制 · 原创设计
免费咨询热线
400-888-6620
免费获取方案
Spring AI集成Infinispan实现RAG向量检索实战
1. 为什么是Infinispan做向量检索之前的那些纠结1.1 项目背景与真实需求先说项目背景。我最近在做一个企业内部知识库的智能问答系统业务方要求把几百份产品文档、运维手册和排障记录全部“喂”给大模型让一线工程师可以直接用自然语言提问比如“Redis内存碎片率过高怎么办”系统能自动检索到相关段落并生成回答。技术栈定的是Java团队对Spring生态非常熟所以选型时几乎没犹豫就锁定了Spring AI。但真正开始做的时候发现麻烦不在大模型调用而在“知识怎么存、怎么查”。我需要一个向量数据库把文档切块后经过Embedding模型转成向量存进去用户提问时再把问题转成向量用相似度检索捞回最相关的文本片段最后拼进Prompt里交给大模型生成回答。这个“中间层”就是Vector Store说白了就是专门干相似度检索的数据库。市面上选择很多Milvus、Qdrant、Elasticsearch、Redis、Chroma、Pinecone随便挑但我们的场景有几个硬约束。第一不能上云数据要留在内网所以Pinecone这类托管服务直接排除。第二运维要省心团队没有专职DBA不想为了一个检索功能再维护一套独立数据库集群。第三最好能和现有基础设施打通我们内部本来就有Infinispan在承担分布式缓存和热数据存储如果能复用同一套集群运维成本几乎为零。1.2 选型时的横向对比与决策逻辑当时我把候选方案拉了个表格逐项对比方案部署复杂度运维成本与现有架构契合度向量检索能力备注Milvus高依赖etcd、MinIO、Pulsar等组件高低独立体系强支持多种索引功能强但太重Qdrant中单二进制可跑中低强Rust实现需要额外维护Elasticsearch中高需要调内存和分片中一般有但性能弱一些适合已有ES场景Redis低低一般需要额外模块精度一般简单但检索能力有限Infinispan低复用现有集群低高原生Spring生态14.0起内置向量索引和Spring AI深度集成最终选了Infinispan核心原因有三点。一是它能以嵌入式模式跑在应用进程内也能以远程模式独立部署我们直接把远程集群复用起来通过Hot Rod协议访问不需要额外部署任何东西。二是Infinispan的向量检索用Lucene引擎实现很多同学不知道Infinispan底层接了Lucene所以它的相似度检索能力和Elasticsearch是同源的精度和性能都有保障。三是Spring AI官方就提供了infinispan-spring-boot-starter集成路径成熟不需要自己造轮子。注意Infinispan从14.0版本开始才对向量搜索提供完整支持项目里如果用的是12.x或13.x老版本需要先升级。说到底选型就是权衡没有绝对的最好只有最合适。如果你的团队已经在用ES那直接用ES的向量检索也完全没问题但如果像我们这样已经有Infinispan集群而且业务链路里处处是Spring那复用Infinispan明显更聪明——少一套系统少一堆麻烦。2. 环境准备与依赖配置把地基打好2.1 Spring AI 2.0 与前代的核心差异在写代码之前必须先搞清楚Spring AI 2.0到底变了什么。很多同学还在用1.0的API习惯直接迁移到2.0会碰一鼻子灰因为2.0做了一次比较大的接口重新整理。2.0里最明显的变化是API命名规范化。以前让人困惑的EmbeddingClient、ChatClient、ImageClient现在统一改成了EmbeddingModel、ChatModel、ImageModel。名字变了职责更清晰了EmbeddingModel只负责“把文本变成向量”ChatModel只负责“对话生成”。如果你翻到其他Vector Store的Spring Boot Starter比如PGVector或Milvus的官方示例2.0版本里清一色都在用EmbeddingModel。第二个变化是VectorStore接口的返回类型从ListDocument加了个可选的元数据过滤search(SearchRequest request)方法更加规范支持返回相似度分数、支持可选的元数据过滤条件。2.0把原来分散在各个Store实现里的差异尽量收敛到了一套统一接口上业务代码切换存储后端时改动量小很多。第三个对Infinispan集成很关键的变化是Spring AI 2.0加强了对Document注解和映射的抽象允许更灵活地定义实体与向量字段的映射关系。Infinispan的Spring Boot Starter利用这一点把Infinispan的缓存条目和Spring AI的Document做了自动映射开发者甚至不需要写过多的转换代码。2.2 集成依赖与版本选择我建了一个Spring Boot 3.4.x的工程Java用的21Infinispan和Spring Boot对JDK版本有硬要求直接用21最省心。Maven的pom.xml里核心依赖如下dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-model-openai/artifactId version2.0.0/version /dependency dependency groupIdorg.springframework.ai/groupId artifactIdspring-ai-starter-vector-store-infinispan/artifactId version2.0.0/version /dependency dependency groupIdorg.infinispan/groupId artifactIdinfinispan-spring-boot-starter-remote/artifactId version15.1.1/version /dependency这里要特别提醒版本对应关系是最大的坑。Spring AI 2.0需要Spring Boot 3.4及以上而Infinispan的Spring Boot Starter版本必须和你的Infinispan服务端版本大致匹配。我一开始用的是Infinispan 15.0服务端是14.0.26跑起来之后发现部分配置项不识别后来把客户端升到15.0.3才消停。如果你不想用OpenAI的Embedding服务也可以用本地的Onnx模型Spring AI 2.0支持通过spring-ai-starter-model-onnx引入本地Embedding能力不依赖外部API适合内网环境。不过我们场景允许调用公司内部部署的OpenAI兼容网关所以直接用了OpenAI Starter。另外Spring AI的版本发布节奏是真快2.0.0出来之后没过多久就出了2.0.1和2.0.2如果遇到奇怪的编译错误可以先看一眼是不是有补丁版本修复了已知问题。Maven仓库里org.springframework.ai的group下面spring-ai-bom可以统一管理版本号建议用BOM方式引入避免各个模块版本不一致。2.3 Infinispan部署环境准备我们内网有个3节点的Infinispan远程集群跑的是14.0.26版本开启Hot Rod协议端口11222。如果你是从零搭建可以用Docker先在本地起个单机docker run -d --name infinispan \ -p 11222:11222 \ -e USERadmin \ -e PASSpassword \ infinispan/server:15.0本地验证一下打开管理控制台默认地址是http://localhost:11222/console用admin账号登录能看到集群信息和缓存管理界面。需要注意的是Infinispan的默认配置里metrics和health是开启的如果后续要接入Spring Boot的Actuator做监控这些端点可以直接利用。生产环境里Infinispan集群通常由一个配置文件控制最简单的方式是准备一个infinispan.xml里面可以定义分布式缓存、索引、序列化等参数。我用的配置精简版如下infinispan cache-container namedefault statisticstrue transport clusterknowledge-base/ distributed-cache namevector-cache modeSYNC encoding key media-typeapplication/x-protostream/ value media-typeapplication/x-protostream/ /encoding indexing indexed-entities indexed-entitycom.example.docstore.VectorEntity/indexed-entity /indexed-entities /indexing /distributed-cache /cache-container /infinispan这里的几个关键点我实际跑通了才体会到encoding必须用application/x-protostreamInfinispan的远程模式下默认用Protobuf序列化如果配成Java原生序列化远程Hot Rod客户端会连不上因为跨语言协议不支持Java原生的Serializable。indexing里的indexed-entities要列出你项目里参与索引的实体类全限定名漏列的话向量索引压根不会建立。3. 核心配置与集成实现写代码之前先想清楚这几件事3.1 Embedding模型与向量维度Infinispan的向量索引有个硬约束索引定义时必须声明向量字段的维度而这个维度取决于你用的Embedding模型。不同的Embedding模型输出向量的维度差异很大最常用的OpenAItext-embedding-3-small输出维度是1536text-embedding-3-large是3072而BGE或M3E这类开源中文模型通常是768或1024。维度选错会直接导致写入数据时报错或者索引根本没法建立。所以项目启动前第一件事是确定Embedding模型然后把维度写死在Infinispan的实体注解里。我的做法是在application.yml里配好模型相关参数spring: ai: openai: api-key: ${OPENAI_API_KEY} base-url: ${OPENAI_BASE_URL} embedding: options: model: text-embedding-3-small dimensions: 1536 vectorstore: infinispan: cache-name: vector-cache host: localhost port: 11222 username: admin password: password这里单独说一下base-url很多私有化部署的LLM网关都会提供一个兼容OpenAI格式的接口地址你有自己的网关就填网关地址没有就用OpenAI官方地址。Spring AI 2.0对base-url的支持比1.0更友好可以直接覆盖整个API基础路径。3.2 数据模型与缓存配置Infinispan没有把向量字段作为一等公民直接暴露给Hot Rod客户端而是通过Protobuf schema映射。在Spring AI的Infinispan Starter里底层已经帮我们用Message注解和Protostream的序列化器把Spring AI的Document映射成了缓存条目。但在自定义索引配置时如果你想要更细粒度的控制可以直接定义一个实体类package com.example.docstore; import org.infinispan.protostream.annotations.ProtoField; import org.springframework.ai.vectorstore.filter.Filter.Expression; public class VectorEntity { private String id; private float[] vector; private String text; private String metadata; ProtoField(number 1) public String getId() { return id; } public void setId(String id) { this.id id; } ProtoField(number 2) public float[] getVector() { return vector; } public void setVector(float[] vector) { this.vector vector; } ProtoField(number 3) public String getText() { return text; } public void setText(String text) { this.text text; } ProtoField(number 4) public String getMetadata() { return metadata; } public void setMetadata(String metadata) { this.metadata metadata; } }你可能会问为什么中间要套一层metadata字符串直接用Map不是更好这就是Infinispan远程模式的限制之一Protostream序列化对复杂泛型支持不如JSON友好String序列化最省心。后面检索时可以把这个String还原成JSON对象做过滤。不过这里我建议大多数场景直接用Spring AI Starter的默认映射就够了Starter已经把所有转换逻辑封装好了。你只需要像操作普通VectorStore一样调用add、delete、search方法。自定义实体的方式更适合需要深度定制索引结构的场景。3.3 向量索引类型与相似度算法选择Infinispan的向量索引基于Lucene索引类型上支持两种hnsw和flat。hnsw是近似最近邻算法检索速度快但需要调参召回率高但会有一定误差flat是暴力精确计算数据量小的时候精度最高数据量大了之后速度会明显下降。实际项目中我建议这样选数据量在几十万条以下直接用flat省心且精度高几十万条以上用hnsw配合合理的M每个节点的最大连接数和efConstruction构建时的动态列表长度参数。相似度算法上Infinispan支持三种COSINE、EUCLIDEAN、DOT_PRODUCT。绝大多数RAG场景用的是余弦相似度因为它对文本长度不敏感能更公平地比较语义接近程度。如果你用的Embedding模型本身已经做了归一化那么DOT_PRODUCT和COSINE在数学上是等价的但DOT_PRODUCT计算更快。在配置Infinispan索引时需要在实体的向量字段上加注解import org.infinispan.api.annotations.indexing.Indexed; import org.infinispan.api.annotations.indexing.VectorField; import org.infinispan.commons.api.query.EntityQuery; Indexed public class VectorEntity { VectorField(bean true, dimension 1536, similarity Similarity.COSINE) private float[] vector; // 其他字段省略 }这里bean true表示这个字段被识别为向量字段dimension 1536和Embedding模型的输出维度严格对齐similarity Similarity.COSINE指定余弦相似度。如果这个配置和缓存实际的索引配置不一致Infinispan启动时要么直接报错要么搜索时返回空结果非常难排查。4. 实操全过程从构建到检索的完整落地4.1 初始化Spring AI的VectorStore当Starter依赖到位、服务端集群可用之后Spring AI的自动配置会帮你创建好InfinispanVectorStore这个Bean。你如果不想用自动配置的默认值也可以手动创建一个VectorStore实例这样可以自定义缓存名称、索引设置等。初始化代码非常简洁import org.springframework.ai.vectorstore.VectorStore; import org.springframework.ai.embedding.EmbeddingModel; import org.springframework.ai.vectorstore.infinispan.InfinispanVectorStore; import org.springframework.ai.vectorstore.infinispan.InfinispanVectorStoreConfig; Configuration public class VectorStoreConfig { Bean public VectorStore vectorStore(EmbeddingModel embeddingModel) { InfinispanVectorStoreConfig config InfinispanVectorStoreConfig.builder() .cacheName(vector-cache) .build(); return new InfinispanVectorStore(embeddingModel, config); } }有几点要提醒。cacheName必须和Infinispan服务端已经存在的缓存名一致如果你连的是不存在的缓存Starter会自动创建但默认配置可能没有索引支持检索时会抛异常。我踩过一个坑自动创建的缓存名是vector-cache但我服务端手工创建的缓存也在这个名字下两边配置冲突导致启动时一直报 Cache already exists with a different configuration。4.2 文档写入与切块策略写好VectorStore之后写入流程相对简单但文档切块的策略直接决定了检索质量。这个环节不是Spring AI或Infinispan特有的却是RAG应用中影响最大的部分。我核心的经验是切块大小配合业务场景没有万能参数。对产品文档这类段落结构清晰的内容我用了TokenTextSplitterchunkSize设为800chunkOverlap设为150。800个Token大概对应500~600个汉字正好能覆盖一个完整的知识点段落。chunkOverlap的目的在于如果一句话被硬切在边界上下一块还能带着上文的语境一起向量化检索时不容易漏掉语义。如果文档是纯手工知识库卡片每条就是一个独立问题答案那就完全不要切直接整条入库检索精度反而更高。如果文档是长篇小说或连续技术手册建议chunkSize提高到1200让上下文更连贯。写入的核心逻辑import org.springframework.ai.document.Document; import org.springframework.ai.transformer.splitter.TokenTextSplitter; Service public class KnowledgeIngestService { private final VectorStore vectorStore; private final TokenTextSplitter splitter; public void ingest(ListString rawDocuments, String category) { splitter.apply(rawDocuments).forEach(doc - { doc.getMetadata().put(category, category); doc.getMetadata().put(timestamp, System.currentTimeMillis()); }); vectorStore.add(splitter.apply(rawDocuments)); } }Document的metadata在Infinispan向量检索里是用来做过滤的比如按文档分类过滤、按来源过滤、按时间范围过滤强烈建议把经常要筛的维度都放进metadata。Infinispan的向量检索本身不支持SQL级别的复杂过滤但Spring AI的Filter.Expression支持简单的表达式比如category 运维手册可以大大提升检索的精准度。4.3 相似度检索与结果后处理检索是VectorStore的当家本领。用Spring AI的SearchRequest发起语义检索import org.springframework.ai.vectorstore.SearchRequest; ListDocument results vectorStore.search( SearchRequest.builder() .query(Redis内存碎片率过高怎么处理) .topK(5) .similarityThreshold(0.5) .filterExpression(category 运维手册 timestamp 1700000000000) .build() );这段代码里三个参数要逐个解释。topK是返回的候选文档数我设置为5这个值不是越大越好topK太大容易把不相关的片段混进来污染Prompt太小又会漏掉关键信息。建议起步设5根据线上效果微调如果发现答案经常缺上下文提到8~10。similarityThreshold是相似度阈值低于这个分数的结果直接丢弃。0.5是经验值但不同Embedding模型产出的相似度分布不一样OpenAI的模型通常分数偏高0.6~0.7才有用有些开源模型分数普遍在0.3~0.5之间阈值0.5就会把大量有效结果过滤掉。最佳做法是先跑几个真实问题观察一下返回分数的分布区间再决定阈值。我最早用的0.5结果发现OpenAI模型下top5的分数都在0.55~0.62之间过滤基本无效后来调成0.45反而更合理——注意不同模型分布差异大按实测微调才是对的。filterExpression是元数据过滤表达式这里用了category和timestamp两个条件。Infinispan的过滤器能力在14.0之后提升了很多但还是要注意过滤字段如果是字符串表达式里用单引号包起来数字类型不需要引号。写错类型不会报错但会返回空结果很坑。检索结果拿到之后我一般会做一个简单后处理把返回的Document按相似度分数降序排列拼接成上下文字符串拼进Prompt。说得直白一点这一步就是把检索结果从“库里的原始文本”变成“给大模型的前置上下文”。4.4 性能调优与缓存策略Infinispan是分布式缓存性能调优绕不开内存索引和预加载策略。第一层优化是堆外内存。Infinispan 15.0支持把索引的一部分放到堆外内存减少GC压力。在infinispan.xml里配置memory heap size1000000 max-count1000000 when-fullEXCEPTION/ off-heap max-size1GB when-fullEXCEPTION/ /memory不过这里heap size和max-count的搭配要谨慎Infinispan官方文档说heap表示条目数而不是字节数单位是条目数这个语义很容易误解别像我一开始那样填了字节数导致OOM。实际上heap size1000000表示最多100万条条目max-count又限定了100万两者是同一个上限。第二层优化是索引预加载。第一次写入大量文档时Lucene索引会在后台构建Infinispan 14.0之后加了preload机制可以把索引数据在节点启动时提前加载到内存避免热启动时查询全部走磁盘。配置如下indexing indexed-entities indexed-entitycom.example.docstore.VectorEntity/indexed-entity /indexed-entities property namedefault.indexmanagerorg.infinispan.query.indexmanager.InfinispanIndexManager/property property namedefault.reader.asynctrue/property property namedefault.reader.strategyshared/property /indexingreader.strategy改成shared后集群内所有节点共享同一个索引reader减少内存占用。这个配置在生产集群里能明显提升检索稳定性尤其是数据量大、节点多的时候。第三层优化是批量写入。如果一次性灌入几十万条文档逐条vectorStore.add()会触发大量网络调用和索引重建性能惨不忍睹。SSD上批量写入能快上几倍到几十倍。正确的做法是把文档切块后分批提交每批100~200条ListListDocument batches partition(documents, 100); for (ListDocument batch : batches) { vectorStore.add(batch); }这里需要说明partition方法是我自己在工具类里封装的简单分页函数把一个大列表切成多个小批次。加批量是为了避免一次请求体过大导致Hot Rod协议传输超时。5. 常见问题与排查技巧实录5.1 找不到或无法创建缓存这个报错基本发生在第一次启动时典型的错误信息是 Cache vector-cache not found 或 ISPN000365: Cache vector-cache is missing。原因基本是缓存配置和Starter默认配置不一致。要么服务端没有手工创建缓存自动创建出来的缓存没有索引能力要么缓存存在但名字不对。解决办法是在服务端管理控制台或者用CLI手工创建带索引的缓存或者直接通过InfinispanVectorStoreConfig的cacheName指定已有的缓存。我调试时发现一个更隐蔽的情况如果工程里多个环境共用同一个Infinispan集群而缓存名都是vector-cache不同环境的索引维度不一致索引会重建失败。缓存名建议带上环境标识比如vector-cache-dev、vector-cache-prod。5.2 序列化相关异常错误信息通常长这样java.lang.IllegalArgumentException: Could not find a marshaller for class com.example.VectorEntity 或者 org.infinispan.commons.dataconversion.MarshallerNotFoundException。原因有两个。第一对象没有加Protostream注解或没被注册到序列化上下文。第二实体类没有ProtoField注解或者注解里的number重复。Infinispan远程模式下Hot Rod客户端传输的对象必须是Protobuf可序列化的。我用的自定义实体在启动时还需要注册序列化器Spring AI Starter一般自动完成但如果你过度自定义实体就得手动注册import org.infinispan.protostream.GeneratedSchema; import org.infinispan.query.remote.client.ProtobufMetadataManagerConstants; Configuration public class ProtoSchemaConfig { Bean public GeneratedSchema serializationContextInitializer() { return new GeneratedSchema() { // 这里需要声明 schema 文件路径 }; } }说实话这条整合路径的配置不是特别优雅我建议优先用Starter的默认Document映射别自己造实体出问题的概率小得多。5.3 向量检索返回空结果这个现象最让人头疼。数据写入成功了查询也不报错但返回结果是空列表。排查顺序我建议这样先看索引是否构建成功。Infinispan管理控制台里进入对应的缓存点击Indexing页面能查看到索引数据量。如果数据量为0说明写入的文档根本没进索引。再看维度是否匹配查询向量维度和索引定义的dimension不一致时检索会静默失败。最后看相似度阈值前面说过不同模型的相似度分数分布差异大阈值设高了全被过滤掉。还有一个容易忽略的地方向量字段必须用float[]如果你用double[]或者ListDoubleInfinispan的索引器不会把它识别成向量字段检索永远返回空。5.4 集群模式下索引不一致生产环境三节点集群跑起来之后我遇到过一个诡异的现象同一个查询在节点A返回结果在节点B返回空。原因是Infinispan的索引默认存储在本地节点上节点挂了或者数据分布不均某些分片没建立索引。解决方法是使用Infinispan的分布式索引配置default.directory_provider为filesystem或infinispan让索引跨节点共享。Infinispan官方推荐生产环境用infinispan目录提供者把索引数据也存进分布式缓存避免单节点索引缺失。配置property namedefault.directory_providerinfinispan/property property namedefault.indexed_entitycom.example.docstore.VectorEntity/property这个配置有个副作用索引一致性需要同步写入吞吐会下降一点但对检索一致性要求高的场景完全值得。5.5 排查速查表症状可能原因处理方式找不到缓存缓存名不匹配统一缓存名或手工创建序列化异常缺少Protostream注解使用Starter默认映射检索空结果维度不匹配、阈值太高校验维度实测分数分布索引不一致默认本地索引配置分布式目录写入慢逐条提交批量写入检索慢flat索引数据量大换HNSW索引5.6 两个不太被人注意的小细节最后分享两个我实际敲代码时踩到的细节问题。第一Infinispan Hot Rod连接的socketTimeout默认值比较保守批量向量写入时如果单批数据量过大可能触发读超时。建议在application.yml里主动加大infinispan: remote: socket-timeout: 30000这个配置项在Spring Boot Starter里通过spring.infinispan.remote.socket-timeout暴露不同版本位置略有差异建议查一下当前版本的配置元数据。第二Spring AI 2.0里VectorStore的delete方法也带过滤表达式平时用得少但在文档更新场景很管用。我重新灌某一类文档时先按category删掉旧数据再写新数据避免脏数据堆积vectorStore.delete(FilterExpressionBuilder.builder() .eq(category, 运维手册) .build());这个方法用的前提是metadata里确实有这个字段否则过滤条件匹配不到任何数据删除操作静默成功但什么都没删掉——这类“静默成功”问题在向量库里比普通数据库更隐蔽因为索引和原始数据可能有一层延迟同步。写在最后的实际体会项目上线一个月效果比预期稳定。Infinispan在集成过程中的角色很独特它不是一个纯粹的向量数据库而是带有向量检索能力的分布式数据网格。恰恰是这个定位让它在一个以Java和Spring为中心的技术团队里显得格外顺手没有引入新的运维组件向量管理、缓存、热数据存储都在同一套集群里完成。从Spring AI 1.0升级到2.0的过程中我最大的感受是这版API真的在向统一化和工程化收敛。EmbeddingModel、VectorStore、Document这些抽象比1.0清晰太多对接不同向量库时切换成本显著降低。如果你正在规划RAG应用又没有特别强的理由用独立向量数据库把Infinispan纳入考虑列表绝对值得。它的文档相比Milvus或Qdrant少一些但当你发现Lucene引擎带来的检索质量、Spring生态的原生集成、以及不用多维护一套系统的省心程度之后这点学习成本完全能接受。
RELATED

相关推荐

GEO实战:五维测评法让门窗品牌被AI主动推荐

GEO实战:五维测评法让门窗品牌被AI主动推荐

最近有好几个做门窗品牌的朋友找我,问的都是同一件事:为什么客户进店之后,嘴里报出来的候选品牌名单里,多了几个他们从来没投过搜索引擎广告的名字?我说你先别急,回去拿手机随便找个AI问答工具问一句“断桥…

📅 2026/9/30 3:26:40
点云滤波全解析:直通、体素到统计滤波的PCL实操指南

点云滤波全解析:直通、体素到统计滤波的PCL实操指南

点云处理这个系列写到第二篇,终于轮到滤波了。很多刚接触点云的朋友一上来就急着做配准、分割、特征提取,结果折腾半天效果都很别扭,回头一看,问题大半出在滤波这步没做到位。点云滤波不是“有没有用”的问题,而是“怎…

📅 2026/9/30 3:26:40
不同阶段读什么?十本经典编程书籍推荐与阅读路线

不同阶段读什么?十本经典编程书籍推荐与阅读路线

如果有人问我"推荐十本编程书籍",我会先反问一句:你现在卡在哪一层?这个问题的答案,决定了同样一本经典,在你手里是安慰剂还是手术刀。我见过太多人抱着《算法导论》啃了三个月,最后连一道业务里…

📅 2026/9/30 3:26:40
MORE NEWS

更多资讯

📰

YOLOv13改进策略【卷积层篇】| CVPR2024 UniRepLKNet Block,大核感受野的可重参数化卷积

本文基于 YOLOv13 官方仓库(iMoonLab/yolov13,ultralytics 8.3.63 fork) 实测整理,Windows/CPU 全程可跑。UniRepLKNet(Ding et al., CVPR 2024《UniRepLKNet: A Universal Perception Large-Kernel ConvNet》,官方源码 github.com/AILab-CVC/UniRepLKNet)给"大核卷…

📰

YOLOv13改进策略【卷积层篇】| CVPR2023 DCNv3 可变形卷积,采样点第三次进化

本文基于 YOLOv13 官方仓库(iMoonLab/yolov13,ultralytics 8.3.63 fork) 实测整理,Windows/CPU 全程可跑。DCNv3(Wang et al., CVPR 2023《InternImage: Exploring Large-Scale Vision Foundation Models with Deformable Convolutions》,官方源码 github.com/OpenGVLab/…

📰

YOLOv13改进策略【卷积层篇】| 2024 MobileNetV4 UIB 万能倒残差,一块卷积通吃轻量微结构

本文基于 YOLOv13 官方仓库(iMoonLab/yolov13,ultralytics 8.3.63 fork) 实测整理,Windows/CPU 全程可跑。MobileNetV4(Qin et al., CVPR 2024 Workshop,《MobileNetV4: Universal Models for the Mobile Ecosystem》,arXiv 2404.10518;官方实现为 TensorFlow,无官方 …

📰

使用 Rube MCP 自动化 Aero Workflow:awesome-claude-skills 中 aero-workflow-automation Skill 实战指南

AI 技能AI 插件人工智能工作流自动化 【免费下载链接】awesome-claude-skills A curated list of awesome Claude Skills, resources, and tools for customizing Claude AI workflows 项目地址: https://gitcode.com/GitHub_Trending/aw/awesome-claude-skills 点击…

📰

DGCharts(Charts 5.x)iOS/tvOS/macOS 图表库完全指南:从安装集成到八大图表实战

数据可视化图表库移动开发 【免费下载链接】Charts Beautiful charts for iOS/tvOS/OSX! The Apple side of the crossplatform MPAndroidChart. 项目地址: https://gitcode.com/gh_mirrors/cha/Charts 点击查看 免费下载 DGCharts 是著名 Android 图表库 MPAndroi…

📰

security-audit-skill HTTP 协议与身份认证安全审计指南:从请求分帧到 mTLS 的系统化狩猎方法

AI 技能应用安全 【免费下载链接】security-audit-skill A coding-agent skill for multi-phase security audits with independently verified, machine-readable findings 项目地址: https://gitcode.com/GitHub_Trending/se/security-audit-skill 点击查看 免费下…

TODAY

今日更新

THIS WEEK

本周精选

THIS MONTH

本月热门

读完文章,想聊聊您的网站?

告诉我们您的行业与需求,资深顾问一对一梳理方案与报价,全程免费。

📞 💬