代码偶尔抽风工程日常

vLLM和TGI我都用过，预算紧的话优先vLLM，PagedAttention对显存利用率确实友好不少。量化别一上来就上4bit，先试试GPTQ或AWQ的int8，客服场景一般掉点很有限。外部API那块建议套一层tenacity做重试加超时，再配个简单的熔断，不然线上抽风能把你拖死。另外监控一定要提前上，不然出了问题连日志都找不到。

别指望prompt能根治，我都是让它先把边界条件列出来再写代码，比事后打补丁靠谱多了。

Agent模式越到后面越飘，长会话里上下文一多它就爱自由发挥。我一般重构前先commit，让它只改指定文件，跑偏就直接reset。

这个超时问题我之前也踩过，大概率不是MCP的timeout参数本身要调，而是SSE连接在你等Ollama出结果的那段时间里被中间层掐掉了。你日志里能看到推理结果，说明请求已经打到Ollama并正常返回，问题出在Server往客户端回推这一步，链路后半段断了。Ollama默认是同步阻塞的，如果你在async函数里直接用requests或者没包到线程池里跑，事件循环会被卡住，SSE的keep-aliv

几百个PDF真不算多，我个人偏向LlamaIndex，索引抽象比LangChain清爽，改起来不用扒三层。不过上生产的话，LlamaIndex的坑主要在增量更新和版本迭代太快，接口说变就变。LangChain生态确实香，但你这种场景封装反而是负担，调个retriever都得绕半天。其实原生Python加LlamaCPP也不是不行，就是后面想加rerank、多路召回时得自己造轮子，看你能不能接受。

几千条业务QA对微调bge其实是够的，关键看你怎么构造训练数据。我当时用大概4千条，正样本是QA里的问题和对应文档片段，负样本用in-batch negatives加BM25挖出来的难负例，效果比不微调提升挺明显的，尤其是你提到的“不相关段落排名靠前”这个问题，微调后top5的准确率大概涨了十几个点。但要注意，微调完的向量空间肯定变了，哪怕你是在原模型基础上继续训练，向量分布也会漂移，所以原来建的

试试vLLM的PagedAttention加AWQ量化，7B在4090上能压到13G左右，效果比NF4稳不少。

500条测试集top-20召回68%，这个数字其实不算太离谱，关键得看你的chunk切法。我踩过类似的坑，之前把段落切得太碎，单个chunk语义不完整，embedding再强也白搭。bge-large-zh对长文本其实挺友好的，你可以试试把chunk调到300-500字，再带点重叠。另外Pinecone的metric选cosine还是dotproduct也影响不小，bge系列一般配cosine更稳

加个bge-reranker重排一下top20，基本能解决，比调阈值靠谱多了。

半年PyTorch转TF确实挺折磨的，我当初也是被Keras的fit和自定义train loop来回折腾。其实TF2的eager模式跟PyTorch动态图体验差不太多了，但PyTorch更Pythonic主要是因为它更像写原生Python，调试和看源码都顺。没必要非此即彼，看团队和部署需求选就行，转过去先把SavedModel和tf.function这两个坑摸熟会轻松很多。

调Prompt确实比写代码累，后来我干脆自己写，只让AI补全片段，省心多了。

这个评测挺有意思的，我们团队之前做商场导视识别时也踩过类似的坑。高跟鞋和烟斗这种符号对模型来说确实太抽象了，训练数据里估计就没多少这种非标准样本。推理模式反而扣分这点我深有体会，有时候让模型一步步想，它会把简单图案脑补出一堆无关语义，最后跑偏了。不过好奇你们项目里最后是怎么处理这类抽象符号的，是靠后处理规则兜底还是继续喂数据硬训？

你这个情况我碰到过，八成是MCP那边对query做了截断或者转义，把原始语义搞歪了。建议先把MCP server收到的query和直接调RAG的query打出来逐字对比，大概率能看出问题。tool description太长确实会干扰模型选参数，但一般不会导致召回飘，更像是编码或拼接出错。超时那个也真实存在，MCP默认超时短的话，RAG异步还没跑完就被掐了，返回的可能是空结果或者上一轮的缓存。

你这个问题挺典型的，本地小数据量检索看着准，一上全量就露馅。3000+文档其实不算多，但排序靠后说明embedding对长文本的语义压缩不够，法律文书里相似条款太多了。建议先别急着换模型，把召回top50都打出来人工看看，重点查rerank那一步是不是压根没生效或者被截断了。另外并发高了响应变慢，八成是向量库连接池或者索引没建好，可以看看是不是每次请求都在重连。

A100 80G两张跑7B还OOM，八成是KV cache吃太狠了，试试gpu_memory_utilization调低点，或者上AWQ量化，能省不少显存。

你这个情况我第一反应不是embedding的问题，bge-large-zh中文检索够用了。技术手册和会议纪要混在一起，语义空间差太远，向量检索容易被高频词带偏，报销流程里出现“服务器”这种词也可能被捞出来。建议先按文档类型分库或者加metadata过滤，再上BM25+向量的混合检索，RRF融合一下，召回质量会明显不一样。

推理OOM跟训练配置关系不大，加载就25G说明权重没量化到位，试试vLLM的gpu_memory_utilization调低点。

先查chat template是不是没套对，Qwen2格式错了很容易出乱码。学习率2e-4对LoRA也偏高了，试试1e-4或5e-5。

我之前也踩过这个坑，Cline读本地库这事儿确实不是简单加个路径就能搞定的。你现在的MCP文件系统服务器基本就是个浏览器角色，只能列目录读文件，指望它自动把整个项目当上下文喂给模型不太现实。关键得看你用的哪个MCP server，官方的filesystem server只提供read_file、list_directory这些原子操作，Cline得主动去调才行，它不会自己扫描你整个项目。想让Cli

我也有过这个阶段，Agent模式确实容易让人偷懒。但后来发现，让它生成完先别急着用，花五分钟让它解释一遍关键逻辑，再自己手敲一遍核心部分，比事后补课省事多了。能跑和能维护是两码事，真到交接那天讲不清楚，坑的其实是自己。