先把结论摆这儿一段几万字的文本喂进模型炸了上下文窗口正确做法不是「砍尾巴」而是先切块、再按和当前问题的相关度打分排序留高分块、丢低分块,中间用一句话占位说明删了啥。硬截会出事的根因在下面三段我自己踩过坑慢慢说。事情起因是上个月。有同事把一份 PDF 合同正文整段复制贴进对话框目测三万多字我那边接口直接报 context length exceeded。当时第一反应特别朴素——截呗留前面一截不就行了。结果翻车翻得挺彻底。一、为什么「留前面、砍后面」会丢掉真正要紧的东西模型读你的输入靠的是一段连续的 token 序列。你以为「前面是重点、后面是废话」那是人读文章的习惯不是文本本身的结构。合同这种东西关键条款经常压在最后——违约责任、争议管辖、生效条件全在尾部。我那一刀切下去把「乙方逾期付款按日万分之五」这条给削没了模型回答得头头是道就是把最贵的那条漏了。说实话我当时有点冒冷汗这要是真发出去就是事故。后面砍不行那砍中间总行吧也不行。文本是有指代链的。前面说「该公司」后面才出现「指甲方北京某某科技」你把中间一段挖掉指代关系就断了模型读到「该公司」一脸懵开始瞎猜幻觉就是这么来的。截断破坏的不是字数是上下文的连贯性。二、为什么 token 不是字符按字数截更容易踩雷很多人写截断逻辑习惯text[:5000]这么来一刀。这里有个隐藏的坑模型数的是 token不是字符。中文一个字大概占 1 到 2 个 token英文一个词可能是一个 token也可能被拆成好几个 subword。你按字符数算「安全」实际 token 数可能超了反过来按字符砍狠了又白白浪费窗口。更糟的是 BPE 分词会把一个完整的词从中间劈开截断点正好落在词中间模型读到半个乱码 token输出直接抽风。截法看着像实际问题按字符硬截简单token 数对不上分词被劈开只留开头保住「重点」尾部关键信息全丢中间挖空省 token指代链断裂幻觉切块按相关度筛麻烦但不丢重点正确姿势是先用 tokenizer 真实数 token按语义边界段落、句号切块每块带点重叠避免割裂然后才是关键一步——和「当前这个问题」算相关度留相关的丢无关的。问合同金额就把谈金额的块留下问管辖法院就留争议那段。这套流程业界叫 RAG检索增强生成。三、为什么这事最好别自己从零搓道理我都懂了真要自己写一套切块策略、向量化、相似度检索、重排序、还得维护一个向量库调起来没几天下不来。学习曲线说陡不陡但够你喝一壶。我后来偷懒搬到了一个零代码就能搭智能体的平台上——拖一拖配一配不写代码把那份合同丢进它的私有知识库切块和检索它在后台自己干了。我搭了个「合同问答小助手」对它说「逾期付款怎么罚」那玩意儿真就只把违约条款那几段捞出来喂给模型回答精准窗口也没爆。说实话第一次成的时候我愣了下这要搁以前得我手写半天检索逻辑。当然也不是没毛病。那个小助手只干「找对片段」这种杂活复杂的多轮推理还得靠后面接的大模型扛知识库第一次建好检索召回有点偏我手动调了两轮分块粒度才顺。但比起自己从零搓一套省下的时间够我多睡两觉了。说到底长文本爆窗口不是让你练刀工的是逼你想清楚「当前这个问题到底要哪几句」。想明白了截断就不再是丢信息是抓重点。你们平时处理超长输入是硬截还是上 RAG分块粒度一般设多大评论区聊聊我那两轮全靠瞎试调出来的。模型和检索那套我直接走的讯飞星辰 MaaS现成 API 调没自己部署算力
 是有代价的)
