小唐_React手记

几万条向量Chroma完全够用，别过度设计，等真到百万级再迁Milvus也不迟。

这个坑我踩过，而且不止一次。Qwen2.5-7B在工具调用的指令遵循上确实有点“固执”，尤其是当它觉得当前信息还不够“完美”时，会倾向于重复调用同一个工具来确认。你日志里看到它拿到天气了还继续调，很可能是因为它在生成下一步推理时，把之前的工具结果当成了“上下文参考”而不是“已完成的动作”，模型没有真正把结果状态更新到决策链里。我后来在LangGraph里加了一个显式的状态标记，比如工具返回后强制写

chunk设512对中文来说有点大了，一个块里塞了好几个语义点，检索时向量被平均掉，问违约金召回违约责任条款太正常了。试试砍到256甚至128，配合overlap 20%，召回精度会好不少。bge-m3其实8G能跑，用fp16加batch调小点就行，它多语言和长文本确实比large-zh稳。query改写这块可以先加个简单的同义词扩展或者用qwen小模型做一下，成本不高但提升挺明显的。

我也这样，后来干脆让它先写简单版，我再按自己习惯改，慢慢就顺了。

指数退避确实比无脑重试3次靠谱多了，我一般用tenacity配个wait_exponential，再根据异常类型区分处理。像TimeoutError这种可以重试，但如果是工具返回的明确错误码就别浪费时间了。另外建议给每个工具单独设超时上限，别让一个慢查询拖死整个链路。MCP-Retry没听说过，感觉自己包一层也不难。

MCP本身不管上下文隔离，靠session_id在server侧做key隔离是常见做法，Redis或内存map都行。

我之前也纠结过这个，后来发现chunk大小真得看文档结构，像技术文档按段落切比固定字数效果好很多。可以试试用语义分割再限制max token，overlap我一般设10%-15%左右，能缓解边界丢信息的问题。你top-k=5可能偏小，配合rerank会稳一些。

我一般只让它补全重复代码，核心逻辑还是自己写，不然真会变懒。

工具描述里塞太多规则反而容易让模型晕，我一般只保留“什么时候用”和“必填参数”两块，其他细节靠工具名和参数名自己说话。让模型先确认意图这招我用过，在系统prompt里加一句“不确定就先问用户”，比让它自己闷头选稳多了。另外可以试试把相似工具合并成一个带action参数的工具，减少它纠结的空间。

lr=2e-4对LoRA来说其实不算离谱，但loss卡在1.8不动，感觉更像是数据格式或者label mask的问题。先确认下你的prompt template和tokenizer是不是对得上，尤其是中文法律数据里有没有混进太多无关符号或者截断得太狠。我拿llama3-8b微调中文任务时也遇到过类似情况，后来发现是padding侧和attention mask没处理好，loss直接躺平。另外bas

8G跑7B量化其实能跑，但你得看量化格式和推理框架搭配合不合适。我之前3070用exllama2跑4bit AWQ，速度能到20 tokens/s以上，比你这快不少，可能是你用了transformers默认加载，那玩意慢得很。质量下降是4bit的通病，可以试试Q5_K_M的GGUF格式，显存刚好够，逻辑会稳很多。

50万条128维才200QPS就90%CPU有点怪，先看下是不是没开多线程或者每次查询都重建连接了。

7B这个尺寸确实对prompt挺敏感的，我拿14B试过类似任务，结构化写法会稳不少。我的做法是把任务拆成几段：先给角色（你是Python工程师）、再列明确要求（必须包含import、异常处理、可直接运行），最后贴一个输入输出示例。另外“请给出完整代码”这种指令太笼统，不如直接说“输出完整脚本，不要省略任何部分，用```python包裹”。温度也调低一点，0.2左右，发散性小，代码完整性会好很多。

你描述的这个情况我去年做法律知识库的时候几乎一模一样，口语化query确实是向量检索的硬伤，bge对“违约金咋算”这种表达泛化能力有限，Top20里能命中2-3条已经不算最差了。我当时的排查思路是先别急着动模型，把badcase拉出来分类看，是检索没召回到还是召回了但排序靠后，这两个问题的解法完全不一样。重排权重调高导致幻觉变多，这个我觉得不是重排本身的锅，而是精排把语义相关但事实不同的段落推上来

这个问题我们也踩过不少坑，感觉核心还是不能让模型直接决定下一步调什么，中间得有一层自己写的调度逻辑兜着。你说的JSON多字段这种，其实用pydantic做严格schema校验就能挡掉大部分，多余字段直接忽略或者报错都行，别让脏数据往下流。重试这块光靠模型重新生成确实容易死循环，我一般会加个最大重试次数，超过就切到备用路径，比如返回兜底话术或者转人工。至于模型脑补参数，可以在工具定义里把必填项和枚举

我也在踩这坑，按话题分段加滑动窗口摘要，召回时再按时间加权，比单条存靠谱点。

你这个问题挺典型的，我踩过类似坑。每次拼接历史对话重新forward，kv cache没复用的话显存肯定线性涨，建议用past_key_values把历史cache传下去，别重复算。另外工具返回的结果别直接塞回完整上下文，可以只保留摘要或者关键字段，不然一轮搜索回来显存直接爆。清缓存那个del + empty_cache只在特定时候有用，别指望它兜底。

几千篇文档确实是个坎，我之前也踩过类似的坑。光调top-k没用，关键是召回阶段就混进了噪声，后面再怎么排也白搭。混合检索加rerank是真的有用，BM25兜底关键词，向量管语义，再用cross-encoder重排一遍，效果能提不少。另外可以试试给每个chunk加上来源标题或摘要一起embedding，让模型在上下文里更容易分辨该信谁。

loss降但输出乱码，八成不是学习率的事，更像是训练和推理的模板没对齐。Llama3有自己的chat template，你训练时如果手动拼的prompt跟推理时用的不一致，模型就等于在答另一道题。另外QLoRA合并权重那步也容易踩坑，adapter没正确merge或者推理时又套了一层lora，都会出这种重复加乱码。建议先把训练样本原样喂进去做一次推理，能复现就基本锁定是格式问题而不是超参。

这问题我也遇到过，Claude确实有这毛病，尤其写类型注解时特别爱自我发挥。我的经验是在.cursorrules里明确写一条：只import当前文件用到的模块，禁止预判性import。另外agent模式下它容易过度规划，改成cmd+k选中代码块局部生成会克制很多。还有个土办法就是写完让它自己跑一遍ruff或flake8，把unused import报出来再让它自己删。