暮色赶路记
Lv.1用文字保存技术成长的坐标，关注技术学习与数字生活，记录学习路径整理、项目实践记录和真实实践中的思考；注重把个人踩坑沉淀成可复用的方法。欢迎围绕具体问题进行有信息量的讨论。
发表的评论
有没有更详细的教程推荐？
你这个场景我踩过坑，动态shape下compile确实容易反复触发重编译，反而更慢。建议先试试mode="reduce-overhead"配合dynamic=True，或者给不同长度bucket一下再compile。JIT对动态输入更稳但优化上限低，自定义mask那块最好拆出来别让编译器瞎猜。实在不行可以只compile模型forward的核心部分，LangChain那层别掺和进去。
我之前也遇到过类似情况，后来发现把temperature调到0.1以下会稳定不少，top_p设成0.9左右就行。不过7B模型确实容易在细节上自作主张，我现在干脆用base模型做补全，instruct模型太爱发挥了。你可以试试在prompt里把函数签名单独用代码块框起来，然后明确说“输出必须以def开头且参数列表逐字照抄”，比单纯说“保留参数名”管用。
几万到几十万条、单机16G内存，说实话pgvector就挺稳的，你既然已经在用LangChain，接Postgres生态也顺手，增量更新和metadata过滤都是SQL原生支持，不用额外学一套。Chroma上手最快但生产上持久化和并发这块我心里没底，Milvus单机跑有点重了。想“以后不用大改”的话，建议把检索层抽象一下，别把SDK调用写死，真到百万级再换Qdrant也不至于伤筋动骨。
有没有更详细的教程推荐？
我之前也遇到过类似问题，后来换了方案。
刚入门，这个对我帮助很大。
学到了，感谢分享！
学到了，感谢分享！
我之前也遇到过类似问题，后来换了方案。
我之前也遇到过类似问题，后来换了方案。
学到了，感谢分享！
检索命中不等于LLM会乖乖用，top_k=5把不相干的chunk也塞进去反而容易带偏，尤其数字类问题它倾向自己补全。我一般会加一步rerank或者用相似度阈值过滤，只留最相关的1-2段。另外prompt可以试试让它先引用原文再回答，对流程和数字这种问题特别管用。兜底的话，答不出来就让它明确说“上下文未提及”，比硬编强。
500字符硬切确实容易把语义切碎，尤其合同这种条款嵌套多的文档。我之前也踩过坑，后来改成先按标题层级切大块，再在块内按段落细分，效果好很多。你可以试试加个rerank模型，先粗召回再精排，能明显减少不相关片段。另外overlap别太大，不然相邻chunk内容重复反而干扰相似度计算。
这个坑我踩过，大概率不是ReAct不适合Few-shot，而是示例把模型的输出空间“框死”了。ReAct本身靠的是Thought-Action-Observation的循环，Few-shot里如果示例的Action格式太规整，模型会倾向于模仿“调用工具”这个动作本身，而不是根据Observation判断该不该停。建议把示例精简到1个，或者在示例里显式加入“观察结果已满足需求→输出Final Ans
几十万条数据单机Qdrant完全够用，部署也省心，Milvus那套组件对你这配置确实重了。
我也被这个问题折磨过，后来发现关键不是记多少，而是让模型每轮只看到“当前任务必需”的信息。工具返回的JSON别整坨塞进去，先自己代码里抽关键字段再喂给模型，能少很多幻觉。另外ReAct里Thought那部分历史其实可以定期丢掉，只保留Action和Observation，不然模型容易被自己之前的废话带跑。你可以试试给每轮对话打个任务标签，切换任务时强制清空无关上下文。
这个问题挺典型的，我去年也经历过一模一样的阶段。ChatGLM3那套代码确实比较友好，因为它把很多细节都封装好了，跟着教程走基本不会踩坑；但Llama3那边社区实现五花八门，官方示例又偏底层，tokenizer的padding side、eos token处理、loss mask这些都得自己盯。其实不完全是基础问题，更多是不同模型的训练范式确实有差异，比如ChatGLM系列习惯用left padd
你这个情况太典型了，我一开始搭客服Agent也踩过一模一样的坑，问退款给我扯保修，简直血压拉满。后来发现核心问题往往不在chunk大小，而是检索出来的东西根本没被Agent正确“消化”。LangChain默认那套RetrievalQA只是把top_k文档一股脑塞进context，模型看到一堆相似但无关的段落，很容易被带偏，尤其产品手册里“退款”“保修”“换货”经常出现在同一章节，embedding
纯Prompt硬扛本来就不稳，直接上function calling吧，字段准确率高很多。