实战派LLM应用札记

BM25能命中而向量召回不行，问题大概率出在embedding对操作步骤里的具体术语不敏感，固定512字符切分也容易把步骤拦腰截断。建议先别急着换模型，拿几篇badcase看看chunk边界是不是正好切在步骤中间，改成按标题或段落切、chunk调小到256左右试试。另外可以搞个hybrid检索，BM25和向量分数融合，操作类query往往关键词匹配更靠谱。bge-large-zh提升不明显说明瓶颈

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

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

这个思路不错，收藏了。

写得挺好，建议补充一些性能数据。

写得挺好，建议补充一些性能数据。

这个思路不错，收藏了。

我们后来加了一层参数schema校验，不合法就直接打回让模型重生成，最多重试两次，基本能压住大部分乱编字段的情况。不过prompt里最好把每个字段的类型和枚举值写死，别指望模型自己理解。还有个坑是模型偶尔会把嵌套结构拍平，这种校验层也得能兜住。

SSE的keep-alive没配的话，中间层很容易60秒断连，先查这个。

我现在是短期和长期分两个collection，短期那个只留最近N轮，超了就摘要成一条塞进长期，这样检索干扰小很多。时间戳加session_id做filter我也试过，问题是embedding本身不区分时效，filter再准也救不了召回质量。短期过期我一般不是直接删，而是压缩成摘要归档，省得以后想追溯对话线索时啥都没有。你们那边如果用Pinecone，其实可以试试namespace按session隔

官方胜在可控，社区胜在好用，我一般敏感目录只给官方，社区的先看源码再跑。

这个问题我也踩过坑，说点实际感受。把对话历史直接拼进query再检索，基本等于往索引里灌噪声，尤其是历史里出现过相似词但不同意图的时候，召回结果会跑偏得很离谱。我现在更倾向于先做一轮轻量的query改写，但不是让LLM自由发挥，而是限定它只做指代消解和省略补全，比如“那第二个方案呢”改成“XX产品的第二个方案是什么”，这样检索目标明确很多。历史embedding我是不建议跟知识库混在一个索引里的，

我习惯把每步结果单独存state里，别全塞prompt，不然确实容易串。

2000条数据做客服问答确实偏少，loss卡在2.3多半是数据质量和多样性不够，模型没东西可学只能摆烂。你验证集输出重复提问内容，很可能是训练样本里本身就有一堆类似模板，建议先清洗下数据，把重复和低质对话去掉。LoRA rank=8对客服场景可能偏小，可以试试调到16或32，学习率2e-4也有点高，降到1e-4左右更稳。24G跑全量肯定不现实，别折腾了，先把数据和rank调一调看看效果。

vLLM的显存占用确实不能只看模型权重本身。你算的5-6G只是权重部分，但实际跑起来KV cache才是大头，尤其你开了continuous batching之后，vLLM会预分配一大块显存给KV cache池，默认gpu_memory_utilization是0.9，也就是它会尽量把A10的24G吃到九成左右，14G其实还算克制了。想确认的话可以看启动日志里那行"GPU blocks"和"KV

batch size降到1还OOM确实有点离谱，A100 40G跑7B微调按理说没那么夸张。你forward中间层爆显存，大概率是激活值没清干净，可以试试torch.cuda.empty_cache()配合手动del中间变量，或者直接上FSDP把参数和梯度都分片。fp16 loss震荡的话换bf16试试，A100原生支持bf16稳定性好很多，基本不用调loss scale。另外dataloader

我理解的 MCP 更像是给模型和工具之间定的一套标准接口，不是 gRPC 那种纯通信层，重点在工具的发现和调用规范上。你现在 vLLM 加 FastAPI 的架构，MCP Server 单独起进程比较省事，训练脚本里直接嵌会跟推理服务耦合太紧。跟 LangChain 的 Tool 抽象比，MCP 更像跨应用复用的协议层，LangChain 那套还是绑在它自己生态里。建议先把工具注册抽出来独立跑，模

Milvus集群部署挺折腾的，小团队直接上Qdrant省心不少，但数据量大了再迁移也头疼。

int4本来就慢，换vLLM或TensorRT-LLM提速明显，flash attention也值得开。

PDF技术手册有个坑是表格和图文混排，ada-002对这类结构基本没辙，切出来全是碎句子。建议先别急着换模型，拿二三十个badcase手动看看切出来的chunk到底长啥样，大概率能发现问题。bge-large-zh中文确实强不少，但你这场景可能混合检索加rerank比单换embedding收益更大。