企业官网建设流程全解析

重庆石桥铺网站建设公司,win2003怎么做网站,网站没服务器行吗,南平建设网站文#xff1a;张晨RAG与agent用到深水区#xff0c;一定会遇到这个问题#xff1a;明明架构很完美#xff0c;私有数据也做了接入#xff0c;但项目上线三天#xff0c;不但token账单爆了#xff0c;模型输出结果也似乎总差点意思。原因在于#xff0c;针对大模型的RAG…文张晨RAG与agent用到深水区一定会遇到这个问题明明架构很完美私有数据也做了接入但项目上线三天不但token账单爆了模型输出结果也似乎总差点意思。原因在于针对大模型的RAG、agent架构其检索模块本质上可视为传统搜索做的衍生变体。这就导致了一个问题传统搜索系统比如搜索引擎、推荐系统等需要饱和式输出保证用户能够收到关于检索结果所有召回信息然后人类会自动在其中选择适合的信息消化吸收。但这一思路迁移到RAG上一次query就能召回10段文档给LLM然后每篇文档几千字这就导致一个query就要消耗几万个token。但问题是这10篇文档里真正有用的句子可能只有几十句而剩下的全是噪音。大量的噪音灌入不仅浪费token也分散了LLM注意力。那么怎么解决RAG召回上下文太长的问题不妨借鉴传统搜索中的重点内容Highlight高亮能力来为大模型做精准的上下文剪枝。欢迎体验我们最新开源的中英文双语语义高亮模型Semantic HighlightHuggingFace链接zilliz/semantic-highlight-bilingual-v101官宣我们开源了Semantic Highlight的SOTA模型要解决RAG召回上下文太长的问题一个最简单的办法就是把召回文档里真正与query语义相关的句子高亮出来只把高亮的句子发给LLM。这样不仅token数量能直接减少70-80%LLM不再被噪音干扰我们也能直观看到这个文档的重点并且在RAG状态不理想时我们也能直接复盘是检索策略的问题还是chunking策略的问题。目前市面上也已经出现了一些能够初步解决这些问题的模型但它们要么只支持英文要么上下文窗口太小512 token要么协议不友好不允许商业使用。没有一个能同时满足中英文都强、窗口够大、泛化能力好、协议友好。所以我们开源了内部最新的Semantic Highlight语义高亮模型。作为一款支持中英文双语处理的轻量级模型它不仅能快速在生产环境完成部署帮助用户更好的理解高亮核心内容裁掉无关上下文大幅降低RAG成本。与此同时由于Semantic Highlight 和 Context Pruning 上下文剪枝本质是同一技术的一体两面。因此这款模型也能用于 Context Pruning 场景在 Agent 应用中对上下文做精准裁剪降低大模型的 token 成本。目前模型权重已经开源MIT协议可以放心食用HuggingFace链接zilliz/semantic-highlight-bilingual-v1具体效果如何我们直接上数据。在中英文数据集上的评测我们的模型都达到了SOTA水平。这是out-of-domain测试。也就是说测试数据和训练数据的分布完全不同。模型在所有四个数据集上都是第一。同时这是唯一一个在中英文数据集上都表现优秀的模型。其他模型要么只支持英文要么在中文上明显下降。比如XProvence系列在中文wikitext2上只有0.45-0.47我们是0.60。02Semantic Highlight工作原理Semantic Highlight的推理过程其实很简单。将输入拼接为 [BOS] Query Context对上下文中的每个 token 打分0 到 1 之间将每个句子内的 token 分数平均得到句子分数高亮高分句子移除低分句子这套思路借鉴了来自Provence的轻量Encoder-Only模型思路把修剪上下文当成一个给每个token打分的任务来做。Provence是一个专门做Context Pruning的模型由Naver在ICLR 2025发表。Encoder-Only虽然是上古时代的架构但它用0.6B上下的参数就能完成token打分任务其速度和效率比现在的LLM快得多。现在主流的大模型Decoder-Only架构通常是一个一个token地吐词缓慢输出。而Encoder-Only是并行处理一次性给所有位置打分。而基于Encoder-Only的打分结果我们再将每个句子的token得分聚合成句子得分就可以得到每个句子的相关性分数高于阈值的句子即为highlight句子。具体的模型选择上我们选择了BGE-M3 Reranker v2作为基础模型。因为它是Encoder架构更适配token/句子打分多语言方面中英文都是重点优化语言。并且其上下文窗口能做到8192 tokens适合RAG里更长的文档。0.6B的参数量在保证效率的同时也确保基础模型本身有足够好的世界知识。而且BGE-M3 Reranker v2本身就是针对Reranking需求训练出来的用于做token打分这种相似性任务时迁移学习更省力。03训练数据准备模型架构选好之后我们需要思考的下一步是训练数据从哪里来我们参考了Open Provence里的数据构造和组织形式并对其进行改进优化Open Provence是Provence的开源复现项目。Open Provence好的一点是它的数据来自公开的问答数据集然后使用了一个小的LLM对句子相关度进行标注并生成 silver label银标签。但其不足在于直接让LLM直接生成标注结果输出结果会变得不稳定且难以后期优化但传统人工标注又会成本、时间双双失控。因此我们让LLM在输出标签的时候把推理过程也写出来。也就是说每条训练样本除了Query、Context、Sentence Spans等字段还有一个很重要的字段Think process思考过程从而让标注更准确因为写推理过程相当于自检一遍可以保证更低的错误率。具体来说让模型带上思考过程会带来了三个更多的优势可观测模型为什么选这句的原因、可调试我们能快速知道标错的内容是prompt问题还是知识问题、可复用后续即使换模型重标注也有现成参考答案。标注流程如下这里用于标注数据的模型我们用的是本地部署的Qwen3 8B。它有天然的思考模式可以用输出推理过程成本也相对可控。最终我们构造了500万双语训练样本中英文各一半。英文数据来自MS MARCO、Natural Questions、GooAQ中文数据来自DuReader、Wikipedia中文、mmarco_chinese。 其中一部分数据是来自 Open Provence 等模型训练数据的重新标注另一部分使用原始语料生成query和context再进行标注。全部标注好的训练数据也开源在HuggingFace上了方便大家二次开发或参考训练。https://huggingface.co/zilliz/datasets准备好了模型架构和数据集接下来我们在8张A100上训练了3个epoch约9小时Semantic Highlight终于成功出炉。目前Semantic Highlight模型已经开源MIT协议可以放心用在商业项目中也欢迎大家基于这个模型的二次开发和改进让开源的力量薪火相传。另外我们在Zilliz Cloud云服务上也即将上线Semantic Highlight的在线推理服务主打开箱即用。04致谢Semantic Highlight模型的训练离不开前人的工作。我们参考了Provence的理论基础。它提出了用轻量级Encoder模型做上下文修剪的思路这个思路非常优雅。也使用了Open Provence的代码框架开源协议它把训练流程、数据管道、模型都实现好了我们不用重复造轮子只需要做少量的调整。在这些基础上我们加入了自己的创新用带思考过程的LLM标注提升数据质量创建了500万双语训练样本覆盖中英文场景更符合实际业务需求选择了更适合RAG场景的基础模型BGE-M3 Reranker v2。只训练Pruning Head专注在Semantic Highlight任务上没有训练Rerank Head。在此向Provence团队和Open Provence项目的贡献者们致以诚挚的感谢。05相关链接模型下载zilliz/semantic-highlight-bilingual-v1Open Provence 项目hotchpotch/open_provenceProvence 论文arXiv:2501.16214Provence 官方介绍文章Provence: efficient and robust context pruning for retrieval-augmented generationMilvusmilvus.ioZilliz Cloudzilliz.com作者介绍张晨Zilliz Algorithm Engineer阅读推荐 不会做RAG、agent的本地数据管理都来学Claude Code附深度拆解 索引选不对成本贵十倍ScaNN就是电商推荐的最优解 都有混合检索与智能路由了谁还在给RAG赛博哭坟 prompt比拖拉拽更适合新手做复杂agentLangSmithMilvus教程 多agent系统实战之Agno与LangGraph谁更适合快速落地生产