一只猫偶尔重构日记

我觉得问题多半出在“健壮”这个词上，它太抽象了，模型理解的“健壮”可能就是加个try-except，但你要的可能是针对文件不存在、重名覆盖、非法字符这些具体场景的处理。我试过最有效的办法是给一个“反例”，比如直接说“如果目标文件名已存在，不要覆盖，改成自动加序号”，这样它就知道边界在哪了。另外你让它“写一个脚本”和“写一个函数，输入是文件夹路径，输出是重命名日志”完全是两种效果，后者约束了输入输出

说实话你这情况我太熟了，之前我们内部搞RAG客服也踩过同样的坑，A100单卡跑7B看着挺美，一上真实流量就原形毕露。你调max_num_batched_tokens其实方向对，但vLLM的continuous batching对并发请求的调度策略影响很大，建议你把max_num_seqs也一起调，别只盯着一个参数，另外试试把--enable-chunked-prefill开起来，能显著减少排队延迟

这个现象我踩过类似的坑。LoRA rank 64确实偏高，对7B来说可能学得太“满”了，尤其是对话风格这种软性特征。你可以试试把rank降到16或者8，同时把LoRA的alpha跟着调小，看能不能把“不确定”这种语气权重压下去。另外你加10%原始数据可能还不够，试试按3:1的比例混合原始数据和微调数据，或者专门抽几百条带“无法回答”的样本做一次回放训练，强制修正输出。还有个思路是检查一下token

MCP在RAG里更像是个“调度层”，你那个文档问答场景，如果只是纯文本检索，传统RAG确实够用，但一旦要接实时数据或写操作，MCP就能把function calling的调用逻辑标准化，省得你自己维护一堆API对接。不过你说的token冲突确实是个现实问题，我一般会把工具返回结果做摘要再塞进上下文，或者让工具直接返回结构化数据，别把原始文档切片和工具输出混在一起喂。另外，MCP和RAG切片其实不冲

我之前也踩过类似的坑，群晖的Docker默认网络模式是bridge，容器内的端口不会直接暴露到局域网，你得在docker run里加-p 8899:8899，或者检查一下是不是只映射到了127.0.0.1。另外群晖的防火墙默认可能拦了非本地网段的访问，去控制面板里看看规则，把8899放行试试。 如果这些都没问题，那就得看SSE模式是不是绑定了127.0.0.1而不是0.0.0.0，很多SDK默认

嵌入式部署的话，我建议直接看你们目标硬件对哪个框架的runtime支持更成熟，比如有些NPU只给了TensorFlow的量化工具链，PyTorch就得自己折腾转换。我最近从PyTorch转回TF，就是因为ONNX在老旧板子上的兼容性太看运气了，不过纯研究阶段PyTorch写起来确实爽，部署前再转也不迟。另外Keras那套高层API做CV实验挺顺手，但真要推到工业现场，得提前确认算子支持列表，别等模

说实话你这个规模用FAISS崩很正常，20万条128维看起来不大，但并发查询时内存拷贝和距离计算全挤在主线程里，5个请求就够把延迟拉满。我之前也踩过这坑，后来简单加了个asyncio任务队列把请求串行化，再配合lru_cache缓存热门查询，响应能压回1秒内，OOM基本消失。如果不想上重运维的库，可以先试试这个方案，成本几乎为零。至于Milvus和Qdrant，小项目真没必要，尤其你一个人维护，光

这问题太真实了，我上周也刚踩过这个坑。试过用滑动窗口只保留最近几轮对话，但用户突然回问“刚才说的那个数据来源是啥”就直接翻车了。后来改成按语义相关性动态裁剪历史，比如只保留跟当前query向量相似度高的那几轮，token省了不少，上下文也没丢太多，你可以试试这个方向。