小顾Product

试试AWQ量化，比GPTQ对代码任务友好些，另外vLLM延迟高可能是没开prefix caching。

先换embedding模型试试，跨章节召回差多半是切分和模型的问题，换库治标不治本。

我之前也踩过这个坑，512切块太机械了，句子被拦腰截断，检索出来当然缺胳膊少腿。后来换成按语义或者按段落切，再给每个chunk加上父文档的标题和前后文摘要，效果好了不少。另外top_k=5其实可以配合rerank用，先多召回再精排，比单纯调chunk size管用。你们有没有试过在prompt里明确要求模型只基于检索内容回答、不确定就说不知道？

刚入门，这个对我帮助很大。

有没有更详细的教程推荐？

这个思路不错，收藏了。

有没有更详细的教程推荐？

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

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

有没有更详细的教程推荐？

学到了，感谢分享！

学到了，感谢分享！

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

我也遇到过类似的情况，text-embedding-3-small做中文技术文档其实还行，但确实有几个坑容易踩。你描述的现象里，CPU部署混进GPU配置，我觉得大概率不是embedding模型本身的问题，而是chunk切得太碎了，200-300字对技术文档来说很可能把一个完整概念拆散了，检索时上下文就不够用。另外你提到重叠50字，这个比例其实偏低，可以试试重叠拉到80-100字，宁愿冗余也别丢信息

T4 16G这个配置其实挺尴尬的，bge-large-zh跑起来确实吃力，尤其你知识库文档一多，批量推理的时候显存和延迟都容易顶到天花板。我之前也用过text2vec-base-chinese，短文本还行，但PDF切出来的块经常五六百token，它那个max length撑不住，后面召回确实会掉。后来换成bge-small-zh-v1.5试了试，速度比large快不少，效果在中文场景下也没差太多，

我之前也折腾过一阵子，后来发现一个比较实在的切入点：把每次生成的输出当成测试用例来跑，而不是靠感觉判断“对不对”。比如生成正则就立刻拿预设的正负样本去匹配，SQL就直接在测试库上explain或者执行，能跑通就是硬道理，跑不通就回看是哪类错误。这个反馈一旦量化，你就能区分是模型能力边界还是指令歧义了。我自己统计过一轮，发现大部分翻车都出在“隐含约束”没说出来，比如正则的贪婪模式、SQL的方言差异，

试试把stage降到2，7B微调ZeRO-2加offload基本够用，3的开销确实大。

我之前也踩过这个坑，后来发现光靠system prompt强调“记住历史”基本没用，模型该忘还是忘。我的做法是把每一步的工具调用结果显式塞回下一轮的prompt里，比如查完订单直接把状态字符串拼进上下文，而不是指望它自己记。另外退款这种敏感操作最好加个校验节点，让它先输出“准备调用退款接口，参数是xxx”，确认参数完整再真正执行，能挡掉不少跳步和胡言乱语。

我倒是觉得MCP跑短任务还行，超过几分钟的微调确实容易踩坑，官方文档里其实也暗示过tool call更适合快速返回的场景。训练数据太大走参数传递不现实，不如让server自己读文件路径或者从对象存储拉。客户端断开后任务大概率跟着挂，除非你的server自己做了异步队列和状态持久化。真要搞长训练，建议把MCP当触发入口，实际训练丢给后端job系统，用轮询或回调拿状态。

这个OOM基本是KV cache被并发打满导致的，跟你显存分配姿势关系不大。8192的上下文乘20并发，光KV cache就要吃掉十几G，加上模型权重和激活，24G根本扛不住。建议把max-model-len降到4096试试，或者开enable-prefix-caching、调小max-num-seqs限制并发数。实在要跑高并发，上双卡张量并行或者换量化版本更靠谱。