长期关注体验实践笔记

几百条数据训3个epoch，loss正常降但输出没变化，很可能压根没学到东西。先别急着调alpha和rank，建议你拿几条训练集里的原句去测，看模型能不能复现，如果连训练集都拟合不上，那大概率是数据格式或者label mask有问题，比如prompt部分没被mask掉。另外5e-4对LoRA来说确实偏高了，7B模型一般1e-4到2e-4比较稳，可以先降到1e-4再跑一遍试试。

我之前也遇到过类似问题，后来换了方案。

状态别塞全局dict，用Redis按session存，MCP的Resource正好能当状态句柄用。

我之前也踩过一模一样的坑，few-shot给多了模型反而会去“背”示例的格式和变量名。后来我基本只在输出格式有严格要求时才加例子，逻辑类的任务干脆零样本，或者最多给一个。角色设定也是同理，说“资深工程师”它就容易炫技，不如直接说“写简洁、能跑的代码，别加多余抽象”。

8并发就OOM确实有点离谱，我这边A100 80G跑Qwen2.5-7B用vLLM默认配置大概能撑到20+并发才吃紧。你先确认下是不是KV cache没限制住，--gpu-memory-utilization默认0.9，再叠加4K+的序列，KV cache膨胀得很快。量化的话AWQ或GPTQ版本对7B效果还行，显存能压到一半左右，但vLLM对量化模型的支持得看版本，老版本遇到过吞吐掉得厉害的情况。

试试把few-shot示例里直接塞一段“坏输出”当反面教材，模型看到对比会老实很多。

说实话你这问题我太熟了，之前做合同审查也栽在这上面。混合文档里表格和长段落混着，光调chunk_size真没啥用，建议先按文档结构拆，比如用版面分析或者标题层级切，表格单独处理。rerank我这边实测提升挺明显的，尤其召回top20再精排到5，比单纯换embedding模型管用。你可以先试试把检索结果拉多些，让rerank去挑，直接砍到3-5个，效果会稳不少。

我之前也踩过这个坑，后来发现固定token切真的很坑，尤其技术文档里步骤和代码块经常被拦腰截断。我现在是先用markdown或标题结构做粗切，再把超长段落按语义边界二次分割，比如遇到“步骤一”这种关键词就强制断开。另外你试试把召回后加一个rerank环节，用bge-reranker重排一下，比单纯调切片见效快。至于评估，可以拿一批真实问答对去算召回内容的答案覆盖率，比盯着embedding相似度靠

这问题我太有同感了，之前调RAG也卡在这儿好久。top_k=10确实容易让模型“贪多嚼不烂”，但降到3又跟抽奖似的，漏了关键信息直接答非所问。我后来发现根子不全在top_k，而是chunk切得太死，512的长度对很多长段落其实会截断语义，导致检索回来一堆半截话，模型自然分不清主次。你提到的rerank我倒觉得是个方向，但不一定非得上一套重模型，先试试在检索后加个基于关键词或向量相似度的二次过滤，把

千万级数据量如果单机部署，Qdrant的Rust性能优势挺明显的，内存控制也比Milvus好很多，我们之前试过8C16G跑500万向量没压力。Milvus的过滤查询确实强，但你要做好它吃资源的思想准备，尤其是索引构建那会儿CPU直接拉满。混合检索这块俩都能做，但Qdrant的BM25是内置的，Milvus得自己搭ES或者用它的混合搜索API，改造上我觉得Qdrant更顺滑些。如果你的过滤条件特别复

说实话你碰到的问题不是prompt技巧不够，是任务本身对稳定性要求太高了，文本分类这种活儿用few-shot加输出格式约束能解决一部分，但标点符号影响结果说明模型对输入扰动太敏感。我建议你把分类标准从“投诉/咨询”这种主观标签改成“是否包含退款/骂人等关键词”的可操作规则，同时用温度调到0跑批量测试，把每类的误判case攒下来反推是边界模糊还是prompt描述有歧义。真要省心，这种业务场景直接用t

我最近也在纠结这个，感觉你那个“去年Q3”的例子特别典型，Agent强行介入反而增加了不必要的工具调用开销。我自己试下来觉得Agent更适合处理那种需要多步推理或者信息不全的复杂问题，像简单的单跳问答直接向量检索加rerank完全够用。另外你说重写query能力有限这点太真实了，现在很多模型在这个任务上其实不如直接换个更好的embedding模型来得实在。

说实话我之前也纠结过这个问题，后来发现MCP更像是个“插线板”，把工具调用、权限、上下文传递都统一成一套协议，省得每个Agent自己造轮子。但如果你只是本地文档检索，确实没必要硬上MCP，直接embedding+向量库就够，ReAct反而更轻快。我自己的经验是，MCP的价值在混合场景，比如要动态接十几个外部服务，或者工具需要热插拔时，它优势才明显。不过有个疑问，你实际跑起来有没有觉得MCP的调试比

我一般先把历史对话丢给LLM提炼成当前问题的背景，再拿这个精简版去检索，效果稳很多。

我们之前试过按session存摘要，发现用户跨天聊同一件事的时候，摘要根本拼不出完整上下文，后来改成事件+实体双轨，事件存动态变化，实体存静态属性，效果好很多。清理策略的话，给每个向量加个last_access时间戳，定期把超过N天没被命中的直接删掉，再配合一个摘要压缩任务把旧对话滚成一条总记忆。不过你这场景要是偏闲聊，可能得考虑情感倾向的衰减权重，不然用户随口一句“今天好烦”能影响后面三天的推荐

说实话我之前也踩过类似的坑，7B模型在双卡上如果单卡显存够放，DDP的通信开销很容易吃掉并行收益，尤其是batch size小的时候。你可以先试试把batch size翻倍或者用gradient accumulation，让每张卡的计算量更大，再看看是不是梯度同步的耗时占比太高了。另外检查一下是不是没设`torch.cuda.set_device`，或者数据加载成了瓶颈，有时候nvlink没接对也

说实话Agent这块瓶颈根本不在框架，LLM推理和工具调用链路才是大头，PyTorch完全够用。

这问题我太有同感了，光堆描述和例子确实容易翻车。你试试把每个工具的参数schema改成严格枚举或者用正则表达式约束，让模型没得选。另外那个“不确认就不要调用”的句子放在system里容易被忽略，不如直接写进工具描述末尾，效果会稳一些。 还有个思路是把决策拆成两步，先让模型只选工具不填参，再单独让它根据选中工具的描述生成参数，这样能少很多混乱。不过多跑几次结果不一样这点，可能跟temperatur

说实话我之前也纠结过这个问题，后来踩了不少坑才摸清楚。MCP server里塞system prompt不是完全不行，但有个很现实的问题：Claude那边对工具返回的content字段会有自己的解析逻辑，你塞进去的指令它不一定当“系统级”约束来对待，有时候会被当成普通文本或工具结果的一部分，稳定性很迷。我试过把规则写在response的structuredContent里，效果比直接拼字符串强点，

这真不是玄学，本质就是各家模型的训练数据分布和指令微调策略差异太大。你那个角色扮演的写法，Claude可能对身份认同类指令更敏感，GPT-4则更容易被few-shot里的具体格式带跑偏。我最近也是发现，与其找通用方法论，不如把prompt当成一个可配置的接口，针对不同模型先跑几个小实验，把角色、指令、示例拆开单独测，哪个组合稳定就用哪个，省得来回折腾。