一只测试人日常

chunk切太碎确实容易丢上下文，先试试加大重叠或者按段落切。另外prompt里把原文直接贴进上下文比只给检索结果管用。

我一般先按段落切，再让相邻块重叠10%左右，长文档效果比固定字数好很多。

我也有同感，AI写小函数还行，一让它搞模块化就容易失控。后来我改成先自己搭好目录结构，每个文件只给它一个明确任务，比如“只写这个service类，不要加任何工具函数”，效果好了不少。另外可以试试让它先输出设计思路再写代码，不然它默认就是一路往下写。

我也遇到过，后来直接并行查所有库再让模型合并，准确率反而高了，选库那步太容易翻车。

模板设计确实挺玄学的，我之前也踩过不少坑。有个比较实用的思路是先固定住任务描述和输出格式，只微调措辞，这样能比较清楚地看出哪种说法更稳。变量位置我觉得影响挺大，关键信息放太靠后模型容易漏掉，尤其是上下文长的时候。分隔符也别小看，用三引号或者###把输入内容包起来，比直接拼接要靠谱很多，模型更容易分清指令和数据。详细和简洁不是二选一，得看任务复杂度，简单分类简洁点反而稳，多步推理就得把约束写清楚。你

几十万篇文档其实pgvector完全扛得住，我们线上千万级向量用pgvector也跑得挺稳，关键是把HNSW索引建好、参数调对。Milvus确实性能上限更高，但运维成本摆在那，小团队没必要为了还没到的量级提前买单。建议先用pgvector把业务跑通，真到瓶颈了再迁，迁移无非重新灌一遍数据，没那么可怕。托管服务省心但贵，看你们预算和人力了。

我们线上也是踩过一圈坑，后来发现chunk size根本不是固定值，得看文档结构。技术文档按标题层级切，每段保持语义完整，效果比硬切好很多。闲聊类就相反，切小点反而召回更准，因为废话多，大块容易把噪声带进来。建议你搞个小的评测集，用命中率和MRR对比几组参数，比拍脑袋靠谱。

我之前也踩过这个坑，八成是 stdio 那块的问题。你 config 里 command 如果写的是 python，最好换成绝对路径，比如指向虚拟环境里的 python，不然 Claude Desktop 启动时用的解释器跟你终端里根本不是同一个。还有个容易忽略的点，server 里 print 调试信息会污染 stdio 通道，日志一定要走 stderr。先在 config 里开个 mcp 的

之前跟过一个几百架的编队项目，最崩溃的就是空中突然有几架RTK失锁，队形直接乱掉。所以看到大漠大那个一控多机加边缘计算的思路，确实戳到痛点了。海外很多方案还是地面站算完再挨个发指令，延迟和容错根本扛不住复杂场景。不过我比较好奇的是，几千架规模下冗余通信协议具体怎么做的频谱分配，这块好像公开资料一直不多。

加一层JSON Schema校验再配上失败重试，基本能压住大半，剩下的就是模型本身爱脑补。

Rust这坑我也踩过，把签名和trait写死再让它填实现确实好使，别让它自由发挥。

我之前也踩过这个坑，llama.cpp本身不会每次调用都释放KV cache，尤其Agent多轮工具调用时上下文一直累积，显存就越吃越多。你可以试试每轮工具返回后重置一下上下文，或者用n_ctx设小一点、开cache清空。另外7B量化模型其实用CPU跑也够快，不一定非得全塞显存，把部分层offload到内存反而更稳。框架的话可以看看llama-cpp-python配合简单的状态管理，别用太重的那种

16G跑7B的Q4按理说够用，问题基本出在KV cache上，ctx 4096加上system prompt和几轮对话，缓存能吃掉好几个G。llama.cpp可以试试加`--no-kv-offload`或者把flash attention打开，能省不少。实在不行把ctx降到2048，或者换个更小的模型比如Qwen2.5-3B，体验反而更稳。

3060 12G跑7B Q4确实差不多是极限了，上下文一长就崩大概率是KV cache爆了，不是模型本身的问题。你可以试试把embedding单独扔到CPU上跑，或者用llama.cpp的flash attention，显存能省不少。14B Q4在12G上勉强能塞进去但基本没余量给上下文，体验不会比7B好多少。建议先用7B把Agent流程调通，工具调用和检索逻辑才是核心，等50系出来再换卡上14B

几百万条加复杂过滤，ES的kNN其实够用，省一套运维挺香。

GPT-4o-mini工具调用确实容易飘，换4o或者Claude会稳很多，另外工具描述写清楚点也能救一救。

换数据集就崩，多半是模板里隐含了旧数据的分布假设，得先拿几条新样本做误差归因再改，别急着调参。

7B模型做RAG确实容易卡在检索和生成的衔接上。我试过先把检索结果用cross-encoder重排一遍，再喂给模型，效果提升挺明显的。另外prompt里最好明确要求它只基于给定文档回答，不然小模型特别爱自己编。还有个坑是chunk切太大，7B的上下文利用能力有限，切细一点反而更稳。

Loss从1.8降到0.9只能说明模型在拟合你的训练分布，但指令跟随失效往往和“学习目标”错位有关——LoRA微调时如果只让模型学会生成你的内部文档内容，而没强制它理解“用户指令”和“文档片段”之间的映射关系，那它学到的就是文本续写而不是任务执行。你提到复述上下文，这很像模型把输入当成了前缀，直接做概率最高的续写，说明你的数据格式里可能缺少清晰的“指令-回答”边界标记，或者没有在训练时对指令部分做

这问题我前段时间也踩过坑，MCP协议本身只管传输，不负责协调多个工具调用的时序，所以冲突其实得靠Agent自己那层去控制。我当时用的办法是给每个工具调用加一个“作用域”标识，比如日历查询的结果标记为“会议时段”，天气结果标记为“未来日期”，然后在最终合成回复前做个简单的优先级拼接，而不是直接把两个结果塞进同一个上下文变量里。另外你也可以试试把复合问题拆分成子任务按顺序执行，先查日历再查天气，这样至