北京
这是一次对我自己系统的后验剖析，而不是别人的。最不舒服的部分是：我早就知道书籍可能极其庞大——在写任何代码之前，项目目标里就白纸黑字写着。但我没有把那条知识当成设计约束。我把它归入“以后处理”的档案，为常见场景构建，然后让每个层次都悄悄硬编码了“整个文档都能塞进去”的假设。当我把它指向一本真实的、超过4000章的网文时，所有功能同时崩溃。教训——知道并不等于设计——让我花费了一个多月的重构时间，而且至今还在偿还。我把它写下来，让你用阅读的代价买到它。
简短版本是这样的：我把“分块”——把大型输入拆成更小单元——视为在调用LLM之前要做的事：拿到文档，发现它装不下，切成几片，循环处理。问题解决。我怀疑我不是唯一一个从这里出发的人——但我要用我自己的系统来论证，而不是用一个我没有的统计数字。实际上问题没有解决。它只是被推迟了，而且利息在复利。
当你已经在提示词边界切片文本时，你的系统其余部分早就承诺了相反的假设。文档是数据库里的一个行，队列里的一个任务，API里的一个请求，缓存里的一个条目，UI列表里的一项。在LLM调用时分块，只是修好了提示词，却让其他每一层都相信整个东西仍然合适。于是，当输入第一次真正变大时，整个系统都裂开了——不是在模型那里，而是在数据库、作业运行器、API、前端。这些地方同时崩溃。
解决方法是把“工作单元到底有多大”当作基础性决策来对待——并让这个决策保持可逆，这样就不会有任何一层把“整个文档”硬编码成以后还得迁移出去的形式。我主张两个刻意成对的想法。这两个标签是我自己的，不是既定的行业术语：把文档边界视为上游契约，把工作单元设计为可协商的输入抽象。换句话说，分块不该是LLM调用前的补救动作，而应该成为系统在架构上对“内容可以任意大”这一现实的适应性。唯有如此，当一部4000章小说到来时，你的系统才不会用全面崩溃来回应。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
