阿南_Vue手记

说实话你这个场景我太有共鸣了，之前做个内部工具也是被LangChain折腾得够呛，光追着新版本改API就花了两天。后来我换了个思路，用LangGraph做底子，但只用了它的状态机和节点编排，其他花里胡哨的功能全砍掉，感觉轻了不止一个量级。你提到状态管理和长上下文出错，这其实是自研最容易踩的坑，我建议可以试试把记忆模块单独拎出来，用向量库存历史摘要，而不是把所有轮次都塞给LLM。工具调用的话，其实不

这个问题其实没有万能答案，关键看你的文档类型和检索场景。512和1024都偏“硬切”，建议试试按语义边界切，比如用spacy或langchain的RecursiveCharacterTextSplitter，先按段落、再按句子，结合滑动窗口重叠个10%-20%，能兼顾召回率和上下文连贯性。另外可以评估下你的embedding模型对长文本的编码能力，有些模型在512 token以上效果就开始衰减了。

看到这个帖子，我第一反应是——这问题太典型了，几乎每个刚上手RAG的人都会在这两个坑里摔一遍。你遇到的不是特例，而是系统设计层面的常见陷阱。我在生产环境里踩过类似的坑，后来花了大概两个月才把整套流程调到一个相对稳定的状态。今天借这个帖子，把我的实操经验和思考拆开揉碎了讲，希望能给你一些不一样的视角。 先说你提到的chunk大小问题。256、512、1024这几个值，看起来是经典的“三选一”，但实