中文长文本理解模型对比：评测避坑、横向实测与落地选型指南

做模型对比这件事，我踩过的坑比想象中要多。最开始我以为把两个模型往同一份长文档上一放，看谁答得准就完事了，跑了几轮才发现事情远没有那么简单。基准选什么、长度怎么分档、位置偏差怎么控，这些看起来琐碎的细节，直接决定了最后那张对比表有没有参考价值。这一章我想把这些底层的评测基础摊开来聊聊，也给后面几章的横向对比打个底子。

1.1 关键词界定：长文本理解、长上下文与中文能力对比

我早期被"长文本"和"长上下文"这两个词绕晕过。跑过几轮评测之后才慢慢分清楚：长文本理解说的是模型能不能从一大堆中文材料里把关键信息捞出来、串起来、说清楚，重点在"理解"两个字；长上下文更像一个硬性指标，指的是模型一口气能吃下多少token，重点在"容量"。这两个东西经常被混着说，做评测的时候一定要拆开看，不然很容易拿窗口大小去冒充理解能力，结论就跑偏了。

中文能力对比有它单独的门道。英文里一个词往往对应一个明确概念，中文里同义词、歧义、隐含主语、省略太多了。我测过一个合同问答的case，模型把"甲方"和"乙方"搞反了，同样的题目换成英文版本它反而答对。中文长文本理解的难度，一部分就压在这种语言本身的黏连和省略上。评测设计里如果不多留几个这样的"中文钉子"，对比结果会显得过于乐观。

1.2 中文长文本理解模型评测基准梳理：通用基准与中文适配基准

通用基准这块，LongBench、L-Eval 这些我基本都跑过。它们提供中英混合的长文本任务，好处是社区认可度高，横向可比，拿来做过初筛挺合适，能看出一个模型大概处在什么档位。麻烦在于中文部分往往是翻译或者双语语料，中文语境的味道不浓，测出来的分数跟真实中文场景的感觉总会错位一点。

中文适配基准就不一样了。有些团队会自己构造中文长文档问答集，法律条文、政府报告、财报、会议记录都有。这类数据的长度分布和文档结构更贴近国内实际使用场景。我印象比较深的是一个中文财报摘要的测试集，里面塞了大量表格和脚注，模型光靠注意力机制根本不够，得懂点财务格式才行。这种数据通用基准里很难找到。

我自己的习惯是两套一起用。通用基准当体检报告，中文适配基准当专科门诊。只看前者容易漏掉中文特有的坑，只看后者又没法跟外面的模型对齐。混着看，心里才有底。

1.3 长上下文大模型中文能力对比的核心维度与指标设计

维度设计我会从四个角度切。信息召回，看长文档里该找到的点找没找到；长程一致性，看跨段落、跨章节的指代和逻辑有没有断；抗干扰，看文档里塞了不相关内容之后模型会不会跑偏；中文语义与文化，看成语、典故、行业黑话、隐含立场能不能读懂。这四个维度不是并列关系，更像是逐层加码，能把模型的能力梯度拉开。

指标上我很少只看准确率。位置敏感度是我必加的一项，把关键信息分别放在开头、中段、结尾各测一遍，某些模型在开头表现稳健，一放到中间就迷路，这种偏科只有分位置测才看得见。引用可追溯率也很管用，让它答完之后把原文出处标出来，人扫一眼就知道它是在答还是在编。这两个指标在小样本评测里特别能暴露问题，比一个孤零零的总分有信息量得多。

1.4 对比实验的可复现性：长度分档、位置偏差、干扰项与评分口径

长度分档这件事我吃过亏。早期测试只用一个超长文档，发现模型A赢了，换一个短一点的文档模型B又反超。后来我把长度固定分成4K、16K、64K、128K几档，每档至少准备两组数据，结果才算稳下来。不同模型在不同长度档的表现差异很大，混在一起测等于把信号搅成一锅粥。

位置偏差的控制得前置到数据构造阶段。我在文档的开头、中段、结尾分别埋关键信息，各测三次取平均，能比较清楚地看出模型是不是存在"中间迷失"。干扰项设计也有讲究，塞一堆同主题但无关的段落，比塞完全无关的噪声更能测出辨别力，因为前者更接近真实文档里的情形。评分口径要在实验开始前定死，是用严格字符串匹配，还是用LLM打分，打分模型是哪一个，温度设了多少，这些都要写进实验记录。换个人拿同样的数据重跑，得能出一样的数，这套评测才有可信度。

1.5 评测结果解读与常见偏差控制

拿到分数，我第一件事是看它有没有"背题"。有些公开基准在模型预训练阶段就见过，分数虚高，换个自建的小测试集分数可能掉一大截。我习惯留一个私有题集做交叉验证，题量不用大，但得有中文场景的颗粒感，这样才敢拿分数去下结论。

还有一种偏差叫提示词敏感性。同一个模型，提示词换个说法，分数能差十来个点，这个幅度可以掩盖模型之间真实的差距。报告里我会注明用的提示词版本，也会跑两套提示词求平均，让结果稳定一些。还有一点是人评和机评的差异，纯看分数会忽略回答的可读性和落地性，抽10%的样本人工过一遍，感受模型到底好不好用。数据指路，人做判断，这个顺序我认了很多年都没变过。

上一章把评测的地基铺好了，这一章我想聊聊真正的横向对比。说实话，把十几个模型往同一张表里放的时候，我心里是有点打鼓的——每个模型都有自己的脾气，有些在实验室里表现亮眼，换到实际中文文档上就露怯。这篇对比我会尽量把参评阵容、每个能力维度的实测表现和自己的观察揉在一起讲，数据是死的，手感是活的，两者得结合着看。

2.1 参评模型范围与分类：开源/闭源、通用/垂类、国内/海外

这次我拉进来的模型分了三组。闭源阵营有GPT-4o、Claude 3.5 Sonnet、Gemini 1.5 Pro，国内的有通义千问Qwen2.5、Kimi、GLM-4、文心一言，开源这边挑了Llama 3.1 70B、Qwen2.5-72B、DeepSeek-V2、Yi-34B。垂类模型我也放了两个，一个是做法律文档的，一个是做金融研报的，想看看垂直训练在长文本上到底有多少加成。

分组之后我发现一个现象：国内模型在中文长文档上的直觉往往更"接地气"，像合同里的甲乙方、报告里的"本季度同比"，这些表述海外模型也能处理，但偶尔会有那种微妙的理解偏差。Claude在结构化输出上特别稳，GPT-4o的摘要文风更自然，Kimi在超长文档的定位准确度上让我挺惊喜。开源模型这两年追得很快，Qwen2.5-72B在几个中文基准上已经能跟闭源中档模型掰手腕了。

垂类模型的定位我一开始期望很高，实测下来是各有千秋。法律模型对法条引用和条款结构确实更敏感，金融模型读财报表格的准确率也明显高于通用模型。它们的短板在于跨领域泛化，给法律模型塞一份技术白皮书，表现会往下掉一大截。用垂类模型就得接受"专精"这两个字背后的代价。

2.2 长文档问答与信息抽取能力对比

长文档问答我设计了三档长度：8K、32K、128K，每档五组中文材料，涵盖政府公告、招股书、学术论文、技术手册和会议 transcript。信息抽取的题目分两类，一类是显式信息定位，比如"第几条第几款写了什么"；一类是隐式信息整合，比如"这份材料的核心诉求是什么"。

显式定位这块，闭源模型整体领先，GPT-4o和Claude在8K和32K档的准确率都能摸到90%上下，128K档掉到80%出头。Kimi在128K档的表现很稳，我甚至怀疑它对超长中文文档做过专门优化。开源模型里Qwen2.5-72B在32K以内接近闭源水平，过64K之后衰减就明显了。有意思的是，128K档的失分大多集中在文档中段，跟上一章说过的"中间迷失"完全对得上。

隐式信息整合的难度不在找，在串。我出了一道题，让模型从一份三万字的企业战略文档里提炼出未来三年的业务重心，材料里相关信息散落在七个不同章节，还夹着一堆务虚的表述。这种题闭源模型明显更会"抓重点"，生成出来的答案能看出层次。开源模型倾向于把所有相关句子罗列一遍，缺少归纳。垂类模型在金融类材料上表现突出，但换成政府公告反而还比不上通用模型，专精的双刃剑又出现了。

信息抽取还有个小细节我想提一下。中文文档里经常有"以上""以下""前述"这类指代，测试里我特意埋了不少，让模型判断这些词具体指代哪一段。GPT-4o和Claude在这一项上准确率最高，国内模型中Kimi和GLM-4紧随其后。开源模型偶尔会把"以上"错误地关联到距离更远的内容，长文档里的指代追踪确实是个硬骨头。

2.3 长文本摘要、多文档聚合与结构化生成对比

摘要任务我分单文档摘要和多文档聚合两种。单文档摘要相对简单，大部分模型都能给出通顺的结果，差异主要在"抓没抓到点上"。我给每份文档人工标注了三个核心要点，看模型摘要覆盖了几个。GPT-4o和Claude的要点覆盖率最高，能达到2.7/3左右，通义千问和Kimi在2.5上下，开源模型大致在2.2到2.4之间浮动。差距不算悬殊，但考虑到摘要任务的实际使用场景，这零点几的差距往往就是"能用"和"还需要人改"的分水岭。

多文档聚合就难多了。我拿了五份同一行业不同公司的财报，让模型横向对比营收结构。这一步不光要读懂每份文档，还得跨文档对齐概念、识别口径差异。测试下来闭源模型优势明显，Claude给出的聚合摘要结构清晰，还能自动提示"各公司统计口径不一致"这种隐含风险。国内模型里通义千问表现最好，Kimi次之。开源模型在这项上集体吃力，输出经常变成五份摘要的简单拼接，缺少真正的聚合。

结构化生成是我很看重的一项，让模型把长文档内容整理成表格或JSON。这个能力在实际业务里需求很大，知识库入库、合同要素提取都得靠它。GPT-4o和Claude的JSON输出几乎不用二次修正，字段完整、格式规范。国内模型里GLM-4和Qwen2.5做得不错，偶尔会有字段名不一致的小毛病。开源模型生成JSON时格式错误率明显偏高，尤其是长文档场景下，越到后面越容易"忘记"要求的结构。这一点在工程落地时很致命，格式不对整个下游管道都得停。

2.4 多跳推理、长程一致性与抗干扰能力对比

多跳推理是我最喜欢也最头疼的测试项。我构造了一道题，要求模型从一份产品手册里找配置参数，再从一份测试报告里找对应的实验条件，最后判断参数是否达标。这种题需要模型在多个文档片段之间建立逻辑链，单点召回能力强没用，得能把线索串起来。闭源模型里Claude在这项上表现最稳，GPT-4o次之，Gemini偶尔会在中间步骤跳步。国内模型Kimi和通义千问表现接近，能完成两跳推理，三跳以上就开始出错。开源模型在两跳以上的准确率下降很快，有些甚至直接把两个片段的内容并列输出，没有做推理连接。

长程一致性我测的是跨章节的人物关系、时间线和立场一致性。拿一份五万字的小说节选和一份会议纪要各测一遍，看模型在回答不同位置的问题时会不会自相矛盾。这个测试暴露了不少问题。有些模型在回答前半部分问题时说"张三是项目负责人"，翻到后半部分再问就变成了"李四负责"。GPT-4o和Claude的一致性最好，通义千问和Kimi也基本能保持稳定。开源模型在128K档的一致性衰减比较明显，尤其是文档结构复杂的时候。

抗干扰能力测试我塞了两类干扰：一类是同主题无关段落，比如在一份新能源汽车研报里插入大段传统燃油车的内容；一类是矛盾信息，同一份文档里前后表述不一致，看模型会不会被带偏。结果挺有参考价值。闭源模型面对同主题干扰时基本能保持判断，遇到矛盾信息会主动指出"文档中存在不一致表述"。国内模型在干扰项上的表现参差，Kimi和GLM-4对矛盾信息的识别率较高，有些模型则会被后出现的错误信息带跑。开源模型的抗干扰普遍偏弱，干扰段落一多，回答质量下降得很明显。

2.5 中文语义、文化知识与专业领域适配对比

中文语义这块我准备了一批"中文钉子"题。成语典故、歇后语、隐含立场、方言表达、网络流行语都放进去了，还有几道题专门测古文和白话混排的文档理解。海外模型在这类题上偶尔会闹笑话，比如把"差强人意"理解成"不满意"，把"不刊之论"当成"不能刊登的言论"。GPT-4o和Claude在常见成语上基本没问题，遇到生僻典故和当代网络语境就开始不稳。国内模型在这方面有天然优势，通义千问、Kimi、GLM-4对中文语感的把握明显更细腻。

文化知识维度我测了传统节日、地域习俗、政策语境这些内容。举个具体例子，让模型判断一份政府工作报告里某句话的施政优先级，这个判断需要理解中国政策文本的行文习惯。国内模型在这类任务上的准确率普遍高出海外模型十到十五个百分点，不是模型能力问题，是训练语料里这类文本的密度不一样。海外模型也能答，但经常抓不住"语气词"背后的轻重缓急。

专业领域适配我覆盖了法律、金融、医疗、信息技术四个方向。垂类模型在法律和金融上优势明显，条款引用和财务指标提取的准确率比通用模型高出不少。通用模型里GPT-4o和Claude在医疗和IT领域表现更好，专业术语理解到位。国内模型在金融和政务领域表现亮眼，通义千问的财报分析能力让我印象深刻。医疗领域整体是弱项，所有模型在涉及临床指南和药物相互作用的测试题上准确率都不算高，这块可能得有专门的医疗语料来做增强。

2.6 上下文窗口、推理成本、吞吐与部署约束对比

上下文窗口的数字这两年涨得很快，128K已经不算稀罕，Gemini 1.5 Pro喊出了1M到2M，Kimi也支持200K。数字好看是一回事，真正能把窗口用满又是另一回事。我测下来，大部分模型在窗口前半段的表现都还算稳定，超过窗口70%之后信息召回率和一致性都会往下走。窗口大小和有效窗口是两码事，选型的时候得看有效窗口，别被标称数字晃了眼。

推理成本这块差异很大。闭源模型按token计费，处理一份十万字的中文文档，单次问答成本从几毛到几块不等，具体取决于模型档位和输入输出比例。开源模型前期投入在硬件上，长期跑量的话单次成本能压得很低。我粗略算过一笔账，日均处理一千份长文档的场景下，用开源模型自建推理服务的成本能比调用闭源API低一个数量级，前提是团队有运维能力。

吞吐和部署约束容易被忽略。闭源API的吞吐上限取决于配额，高频场景下需要提前申请。开源模型部署对显存要求高，128K上下文基本要80G显存起步，Qwen2.5-72B这种体量的模型在长上下文场景下单卡跑不动，得多卡并行。国内模型在国产硬件适配上有优势，昇腾、寒武纪这些平台的支持度比海外开源模型好不少。实际落地时还得考虑合规和数据出境问题，金融、政务类场景基本只能用国内模型或者私有化部署的开源模型，这一条往往比性能对比更有决定性。

选型这件事没有全能冠军。闭源模型综合能力强、省心，成本高、数据出境有顾虑；开源模型可控、便宜，需要技术投入；垂类模型专精，泛化弱。我自己的经验是先拿场景卡死合规和成本红线，再在剩下的候选里比能力，这样选出来的模型才真能落地。

前两章聊了评测基准和横向对比，这一章我想把视角拉回到真实业务里。模型跑分再漂亮，拿不到具体场景里就是屠龙术。我在过去一年里帮几个团队做过长文本方案的选型和落地，踩过的坑比测验分数更有参考价值。这章不讲理论，讲怎么把模型塞进业务流程里还能让它稳定干活。

3.1 场景化选型矩阵：知识库问答、合同/报告分析、会议纪要、舆情长文等

知识库问答这个场景我经手最多。它的特点是问题短、文档长、对准确率要求高，回答错了比不回答还糟糕。这种场景我一般优先看模型的定位精度和引用溯源能力。上一章测过Kimi在超长文档里的定位表现很稳，Qwen2.5在32K以内性价比突出，如果知识库文档普遍在五万字以下，这两个都够用。文档更长的话，我会倾向把RAG和长上下文结合起来，而不是硬让模型吃满窗口。

合同和报告分析是另一套逻辑。合同类文档结构规整，条款之间有严格的逻辑关联，模型需要理解"甲方"和"乙方"在整个文档里的一致性。这里垂类法律模型确实有优势，条款引用准确率能比通用模型高出一截。报告分析稍微复杂一些，尤其是财报或者研报，里面夹着大量表格和跨章节的数据引用。我试过用通用模型直接读财报，表格里的数字经常被读串行，后来改成先用解析工具把表格抽出来再喂给模型，准确率提升很明显。

会议纪要和舆情长文是两类容易被低估的场景。会议纪要的特点是口语化严重、信息密度低、关键信息散落，模型需要从一堆"那个""然后"里捞出真正的决策项。舆情长文则要求模型能处理情感倾向和立场判断，这跟纯信息抽取完全是两种能力。舆情场景里我用下来通义千问和GLM-4对中文语境的立场判断更细腻，海外模型经常会把反讽当成正面表述。

我把这几个场景的核心诉求和推荐策略整理成了一张矩阵表，选型时先对号入座再细化比较，能省不少试错时间：

这张表不是铁律，实际选型还得看团队手里的技术储备和预算。有自建能力的团队在知识库场景用开源模型加RAG，成本能压得很低。没有运维班子的团队直接调闭源API更省心，多花的钱买的是确定性。

3.2 技术路线对比：直接长上下文、分块检索RAG、层次摘要与混合架构

直接长上下文是最省事的路线，文档整篇塞进去，模型自己找答案。这条路线的优点是信息不丢失，跨章节的隐式关联能保留下来，像合同里的交叉引用、报告里的前后呼应，模型都能直接看到。缺点也很明显，成本和延迟随文档长度线性增长，128K上下文跑一次推理的费用是8K的十几倍，而且上一章测过，窗口用到七成以后召回率会往下掉。文档长度稳定在五万字以内、对延迟不敏感的场景，这条路最省心。

分块检索RAG是另一个极端。把长文档切成小块建索引，提问时召回相关片段再喂给模型。成本低、延迟短、可扩展性好，知识库几十万份文档也能扛住。问题是切块本身就是信息损耗，块与块之间的逻辑关系容易断。我做过一个测试，一份三十页的技术方案里，某个关键参数的定义在第三页，具体数值在第二十八页，RAG召回的时候只捞到了第二十八页，模型给出的答案就缺了前提条件。这种跨块推理的短板在复杂文档上特别致命。

层次摘要适合超长文档的粗粒度理解场景，比如让模型先读完一百页报告给出整体判断。做法是先分段摘要再逐层聚合，优点是能处理远超窗口长度的材料，缺点是细节丢失严重，聚合过程中容易把关键数字或者限定条件磨掉。我用这套方案做过一份招股书的整体风险分析，框架性结论没问题，但具体到某一项财务指标的异常波动，模型就说不出所以然了。

混合架构是我目前最推荐的路线，也是实际落地里效果最稳的。核心思路是让RAG负责定位、长上下文负责理解。具体做法是先通过检索把相关段落圈出来，再把召回片段加上它们的上下文一起塞进长窗口，让模型在相对完整的语境里做推理。这样既控制了输入长度，又保留了跨段落的逻辑链。我帮一个法务团队搭过合同审查流程，用的就是这套混合方案，条款召回准确率和条款间冲突识别率都比纯RAG或者纯长上下文高出不少。

混合架构的工程复杂度也最高，检索质量、上下文拼装策略、窗口预算分配都得调。我的经验是检索召回率不到85%的时候别急着上长上下文，先把检索这层做扎实，不然模型拿到的是残缺信息，再强的理解能力也救不回来。另外拼装策略上我倾向"召回片段加前后各一段"的方式，比只给召回片段本身的效果好很多，模型能自己判断片段在原文里的位置和上下文关系。

3.3 提示工程与评测闭环：引用溯源、结构化输出、位置敏感与人工评估

引用溯源在长文本场景里不是加分项，是必选项。知识库问答和合同审查这类场景，用户看到答案的第一反应是"你从哪看出来的"，没有引用支撑的回答基本没法用。我在提示词里会明确要求模型输出答案时附带原文片段和位置信息，格式上固定成"结论+依据+出处"的结构。实测下来Claude和GPT-4o对这类指令的遵循度最高，国内模型里Kimi和GLM-4也不错。开源模型经常会把引用位置标错，尤其是长文档后半段的内容，引用到前半段去的情况时有发生，这块得靠后处理校验来兜底。

结构化输出是另一个必须提前设计好的环节。长文本处理的输出往往要进下游系统，JSON格式错了整个管道就断了。我的做法是在提示词里给出完整的字段定义和示例，并且要求模型在输出前做一次自检。更稳妥的方式是用模型厂商提供的结构化输出接口，比如JSON mode或者function calling，格式约束比纯靠提示词硬得多。即便如此，长文档场景下还是建议加一层格式校验，我遇到过模型在文档末尾输出截断的情况，JSON没闭合，下游解析直接报错。

位置敏感这个问题值得单独说。上一章测过"中间迷失"，实际业务里的表现更隐蔽。用户问的问题如果答案在文档开头或者结尾，模型答得又快又准；答案在文档中段，模型经常答得含糊或者干脆说"文档中未提及"。我的应对方式是在提示词里明确提示"答案可能位于文档任何位置，请仔细检索全文"，同时在RAG召回阶段适当提高中段片段的权重。这个小技巧在知识库场景里把中段问题的准确率拉上去了十来个点。

人工评估这块我想多说两句。自动指标能告诉你模型答得对不对，但答得好不好、能不能直接用，还得人来看。我一般会抽10%的样本做人工评估，重点看三个维度：引用是否准确、结论是否有依据、表达是否符合业务习惯。评估结果会反馈到提示词迭代里，形成一个闭环。这个闭环跑上两三轮，模型在具体场景里的可用性会有明显提升，比单纯换模型见效快。

3.4 成本、延迟、稳定性与合规风险的综合权衡

成本这件事得算总账，不能只看单次调用价格。闭源API按token计费，长文档场景下输入token是大头，一份十万字的文档单次问答成本从几毛到几块不等。开源模型自建推理前期硬件投入大，但跑量之后单次成本能压到闭源的十分之一甚至更低。我算过一笔账，日均处理量在一千份文档以上的团队，自建推理半年左右能回本。日均几十份的小团队就别折腾了，直接调API更划算，运维成本比省下来的钱多。

延迟是另一个容易被低估的指标。长上下文模型的首次token延迟本来就高，128K窗口下等个十几秒是常态。知识库问答这种交互场景用户等不了太久，我会把窗口控制在32K以内，配合RAG把输入长度压下来。合同审查、报告分析这类异步任务对延迟不敏感，可以用大窗口换准确率。流式输出也能缓解等待焦虑，用户看到字一个个蹦出来，感知延迟会低不少，这个体验细节在落地时挺重要。

稳定性在长文本场景里是个大坑。闭源API有配额限制，高峰期偶尔会限流，关键业务得做多模型备份。开源模型自建服务的稳定性取决于运维水平，显存溢出、推理超时这些故障我都遇到过。我的建议是核心业务至少准备两条技术路线，一条主用一条备用，主路线出问题能快速切换。另外长文档处理本身耗时长，任务队列和超时重试机制得提前设计好，别等线上出事了再补。

合规风险在中文长文本场景里往往是决定性因素。金融、政务、医疗这些行业的数据基本不允许出境，海外模型直接出局。国内模型里也得看清楚数据使用条款，有些API会拿用户数据做训练，敏感业务得选明确承诺不留存数据的服务商。私有化部署的开源模型在合规上最稳妥，代价是硬件投入和运维人力。我见过不少团队性能对比做了一堆，最后卡在合规审查上推倒重来，选型时把合规红线放在第一位能省很多返工。

3.5 趋势展望：中文长文本评测标准化与长上下文模型演进

中文长文本评测的标准化这两年进展不算快。英文社区有LongBench、RULER这些公认基准，中文这边各家用的测试集五花八门，横向对比的可信度打折扣。我期待看到更多针对中文语言特点设计的基准，比如古文和白话混排、政策文本的语义层次、中文特有的指代和省略现象。现在有些团队在推动中文长文本评测联盟，方向是对的，标准统一了选型才有依据。

长上下文模型的演进方向我看两个点。一个是有效窗口的提升，现在标称128K的模型实际能稳定用的也就七八十K，把有效窗口做扎实比继续堆数字更有价值。另一个是长文本推理效率的优化，稀疏注意力、KV cache压缩这些技术在快速迭代，同等硬件下能处理的上下文长度还会往上走。开源模型在这块的追赶速度很快，Qwen和DeepSeek的长上下文版本能力已经不输海外中档闭源模型。

混合架构会成为长文本落地的主流形态。纯长上下文成本太高，纯RAG信息损耗太大，两者的结合点会越来越成熟。我观察到一些团队开始在检索层做语义分块、在模型层做位置感知的注意力增强，这些工程优化积累下来，长文本方案的整体可用性会有质的提升。选型这件事也会从"选哪个模型"变成"怎么组合模型和检索策略"，视角变了，答案就不一样了。

最后说一句我自己的判断。中文长文本理解这个赛道，模型能力的差距在缩小，工程落地能力的差距在拉大。同样的模型，有人搭出来的系统准确率九成，有人搭出来六成不到，差别在检索质量、提示设计、评估闭环这些脏活累活上。选型是起点不是终点，把优化实践做扎实，中等模型也能跑出好效果。