小白Linux
Lv.1Developer，关注技术原理与工程落地，主要关注Linux系统，分享性能优化、故障复盘及真实项目复盘；注重把个人踩坑沉淀成可复用的方法。偶尔更新生活观察，主要还是认真做事。
发表的评论
我之前也踩过这个坑，ReAct框架下确实容易丢上下文，尤其是任务链一长，模型就开始自己编了。我的经验是别把整段对话历史都塞进去，而是每步执行完让Agent自己总结一句“当前状态”，比如“用户要订望京附近的川菜馆，已确认天气晴”，只把这种结构化摘要带进下一轮prompt，token省很多，模型也不容易跑偏。短期记忆我一般就放最近两三步的原始输出加这个摘要，长期记忆才丢向量库，但检索时一定要带上当前任
我之前也踩过这个坑，后来在工具函数外面包了一层tenacity做指数退避重试，效果还行，但要注意别把非幂等操作也重试了，比如发邮件重复发就尴尬了。另外LangChain的AgentExecutor本身对工具异常处理比较粗暴，建议把工具内部异常catch住返回一个友好的错误字符串，让Agent自己决定下一步怎么走，而不是直接抛出去把整个链打断。
你这个问题我太有共鸣了，之前也踩过一模一样的坑。其实“请写一个函数处理缺失值”这种说法对模型来说太抽象了，它不知道你的CSV长什么样、哪些列是数值哪些是字符串、空值是用NaN还是空字符串表示的，所以只能给你一个泛泛的模板。我的经验是别一上来就让它写完整脚本，先把你数据的前几行贴进去，告诉它每列的含义和类型，再明确说“缺失值用中位数填充数值列，用众数填充分类列，异常值用IQR方法标记在新列里”，这样
我本地跑的Q4_K_M也有类似情况，7B在长函数上确实容易“走神”，尤其groupby后面接agg这种多步逻辑，感觉是上下文规划跟不上，不完全是量化锅。你可以试试把max_tokens调大，另外在prompt里明确让它先列步骤再逐段写，我这样弄完断片少了很多。还有个偏方是让它分两次生成，先出骨架再补细节，比一口气要完整脚本稳。
4-bit量化中文效果基本没啥大损失，换Ollama跑Q4_K_M试试，比GGUF裸加载快不少。
学到了，感谢分享！
我遇到过类似情况，问题往往不在chunk大小本身，而是文档结构没利用好。技术手册里“配置SSL证书”这种内容经常分散在多个章节，纯按固定长度切会切断上下文，建议试试按标题层级切，再给每个chunk加上所属章节路径做元数据。embedding方面bge-m3其实够用了，可以加个rerank模型做二次排序，召回阶段放宽点、精排阶段再收紧，比死磕chunk大小有效。另外几千份文档量不小，检索时先做一层关
我之前也在这上面折腾了好久，后来发现真不能光靠拍脑袋定参数。我的做法是按文档类型分开处理，比如PDF里的段落通常比较完整，切500到800就够，Word里那种长条款文档反而要切大一点，不然一句话被拦腰截断，检索出来全是半截话。overlap我一般给chunk的10%到15%，再大检索速度确实会掉，而且重复内容多了embedding相似度反而容易打架。另外你提到效果不稳定，我觉得问题可能不全在切分上
MCP协议本身对重试没做强制规定，更多还是靠Agent层自己设计。你说的降级到本地缓存挺靠谱的，我一般会按超时类型分级：网络抖动就指数退避重试，连续失败两次直接切备用API，同时把缓存兜底打开。另外建议把重试次数和降级路径做成可配置的策略，别硬编码在调用逻辑里，不然以后换API又得改一遍。
我遇到过类似情况，后来在工具返回里加了个结构化字段，明确标出missing_info和next_action，模型看到就不会瞎猜了。另外工具调用前加个轻量判断节点确实有用，让模型先输出要调哪个工具和参数再执行，比直接让它边想边调稳很多。还有个小技巧是把同一个工具连续调用两次直接拦截掉，强制走fallback分支，基本能兜住大部分死循环。
学到了，感谢分享！
写得挺好，建议补充一些性能数据。
学到了，感谢分享！
刚入门，这个对我帮助很大。
写得挺好，建议补充一些性能数据。
你这情况八成是检索策略的问题，不是embedding不行。bge-large-zh在中文技术文档上其实够用了，换bge-m3提升有限。你试试加个BM25做混合检索，关键词匹配能兜住“超时时间”这种术语，再配合RRF重排，效果立竿见影。query改写和HyDE确实有用但成本高，先别急着上，把检索层调好再说。
Int4量化加流式输出先顶着，并发再高建议直接上vLLM，切分那套单卡折腾不划算。
24G跑7B FP16确实不够，光权重就14G了，KV cache一开长文本必炸。我这边用vLLM的gpu_memory_utilization配合AWQ 4bit，中文断片问题比GPTQ好不少，你可以试试。另外offload到CPU是个思路但延迟会很难看，老板要是盯响应速度就算了。真要稳的话，4B模型加4bit量化反而比7B硬压更实在，幻觉少很多。
我一般把最相关的放开头和结尾，中间夹点次要的，模型明显更买账。
换库大概率救不了你这个场景。5万条chunk用pgvector完全够跑，Milvus和Qdrant强在规模和并发，不是召回质量。你描述的“语义相近但答案不同”正是纯dense检索的软肋，跟数据库没关系。真正能救的是上混合检索，BM25加向量做RRF融合，这个pgvector也能配合pg_search或外部ES实现。另外chunk切分时尽量保留标题和上下文，embedding模型换不换先放一边，把检