深度学习落地指南

表格图片切碎了确实要命，先上reranker试试，不行再改切分。

7B量化的模型确实在指令遵循上会打折扣，尤其4-bit之后有些细节容易丢。我试过Qwen2.5-7B和14B，感觉14B的指令跟随明显稳很多，7B得把提示词写得更死，比如明确说“只输出三点，每点不超过20字”。另外它的系统提示词权重好像比GPT低，你可以试试把要求直接塞进用户消息里而不是system里，效果会好一些。

工具返回前先做一轮重排和去重，别让模型自己硬拼。

我们组去年也踩过这个坑，说说实际感受。torch.compile在固定shape的CV模型上确实香，但LLM推理这边动态batch基本是常态，每次shape一变就触发recompile，那个编译开销在生产环境里根本扛不住。你提到的和vLLM冲突我也有耳闻，主要是vLLM自己已经用CUDA graph做了capture，compile再插一脚去改计算图，两边打架很容易出显存碎片。我们最后的做法是推理

数据太脏了吧，判决书里一堆没用的话，先做清洗和截断再调参试试。

我一般按语义切，512到800字符加10%重叠，技术文档再小点更准。

几十万条Chroma扛并发确实吃力，早点上Milvus省心，索引选HNSW别用IVF。

微调bge得配对比学习样本，纯文档喂效果一般。混合检索能救一部分，但长文语义匹配还是闭源稳。

top5都漏信息，是不是chunk切得太碎了？我后来改成按语义切加小重叠，效果好不少。

几百字一坨的切法对API文档真的不友好，一个方法签名和它的参数说明很容易被切散，检索出来全是半截内容。可以试试按类或按方法粒度切，把签名、参数、返回值、示例绑在一起，再给每块加上类名和方法名的路径前缀，这样embedding能抓到的语义信号强很多。另外几千个类几万条方法，光靠纯向量检索容易召回到“长得像但用错场景”的接口，混合BM25做关键词过滤会稳不少。

几百条之后才开始崩，这个时间点挺典型的，基本就是记忆库从“信息不足”变成“信息过载”了。你换embedding模型没大用其实不奇怪，因为问题多半不在编码质量，而在检索目标本身变模糊了——同一个用户说过太多语义相近的话，top-k=5很容易被同一类内容反复占满。我之前也踩过这个坑，后来发现光靠时间衰减只能缓解，真正有用的是给记忆分层，比如把原始对话、阶段性摘要、用户画像拆成不同namespace或不

先让LLM把指代补全成独立query再检索，历史只用来改写别直接塞。

我们线上也踩过这个坑，torch.compile在训练侧收益挺明显，推理这边确实不太敢上。T4上动态batch加上vLLM的paged attention，compile基本等于给CUDA graph添乱，显存碎片报错不是偶然。后来我们推理直接走TensorRT-LLM或者ONNX Runtime，warmup可控，延迟也稳。compile目前更适合固定shape、自己手写serving的场景，跟

我现在的做法是分两步，先让模型只看检索片段做抽取式回答，再让它润色成完整句子，这样准确率高不少。你那个“不知道”指令太硬了，可以改成“优先用资料回答，资料不够时再补充你自己的知识”，模型就不会那么怂。还有一个坑是检索回来的片段顺序，把最相关的放最前面效果会好一点，别按文档原始顺序拼。

我试过类似的场景，问题多半出在“逐行分析”这个指令上，它会让模型陷入细节反而忽略全局。你可以拆成两轮，第一轮只让它找明显错误和坏味道，第二轮再针对可疑片段深挖，比一次性给压力稳定得多。另外给一两个正反例确实有用，但别太多，不然它会过度模仿你的例子格式而不是真正思考。你现在的模板能发出来看看吗？想对比下约束的粒度。 我最近也卡在这块，感觉“扮演资深开发者”这种话术对GPT-4来说太虚了，它反而会往

同款问题，五千条LoRA数据绝对够用，但八成是你构造的样本里“长文档+精确答案”的映射太理想化了。真实检索出来的片段往往带噪音，模型练的时候只见过干净上下文，上线碰到信息密度低的段落自然就抓瞎。建议试试把负样本和无关段落混进训练集，强制它学会挑重点，而不是无脑复述。另外也可以先别动生成模型，单纯调RAG的检索重排，有时候问题出在拿回来的段落压根不对。

结构化输出建议上JSON mode或函数调用，分类摘要拆成两级任务，能稳不少。评估工具可以试试promptfoo，批量跑用例看差异。 --- 试试把few-shot换成带标注的异常样本，再配合输出校验重试机制，比纯调prompt靠谱。版本对比我用的promptlayer，能看token消耗和成功率。

这个我踩过坑，MCP挂多了确实会有握手开销，但更大的问题在于你把所有工具的schema全塞进了上下文里，每轮请求token都在悄悄膨胀，响应慢往往是因为这个而不是网络握手。我生产环境现在固定只挂两三个核心服务，文件、数据库这种高频操作走本地封装，GitHub这种低频才走MCP，基本能做到按需初始化连接，但说实话不同客户端的懒加载机制差别很大，有的还是启动时全量拉取。至于权限隔离，我个人觉得比负载均

few-shot确实管用，把真实SQL样例喂进去它就不敢乱编了。另外别用小模型，复杂逻辑更容易幻觉。 few-shot是靠谱的，顺便把JOIN类型和字段名写成强约束模板，直接让它填空就行。

你怀疑切块策略是很有道理的，固定512字符确实容易把语义切断，我之前碰到过类似情况，改成按段落或语义边界切块后召回提升挺明显。另外可以看看query和文档是不是用了同样的embedding模型，有时候查询端处理方式不同会影响分布。还有个小方向，检索完可以试试用交叉编码器重排一下top50，能救回不少漏掉的。你测试集是人工标注的还是自动构建的？如果是自动的，说不定标签本身有噪音。