清晨远航录

我之前做技术文档问答也卡在这块，后来发现别死磕固定值，先按文档结构走。技术手册这种小标题多的，我直接按章节切，chunk基本在300-500之间，重叠设个50就够，既保住上下文又不会重复太多。你可以先用langchain的text splitter做个快速对比，看看召回结果里哪些句子是真正命中问题的，再微调。另外推荐试下递归字符分割器，比固定大小灵活不少，起码省一半调参时间。

同感，我试过8和32在NLU任务上差距也不大，但代码生成这种结构化任务，rank高了反而容易过拟合到训练集格式上。你5万条指令其实不算少，Llama底座本身代码能力就不弱，LoRA更多是引导风格而不是学新知识。rsLoRA我试过，提升有限，主要是稳，不如把精力放在数据质量上。另外全参微调成本高，但效果确实比LoRA上限高，尤其你资源够的话可以试试。

先给query加个简单hash缓存，命中直接返回，没命中再走embedding，能省不少事。 几万条数据bge-m3其实不算慢，大概率是没开GPU或者批量处理，看看是不是单条请求在跑。

你这问题大概率出在AWQ和vLLM的兼容性上，vLLM对AWQ的显存预分配策略比较激进，建议先试试用`--kv-cache-dtype fp8`或者调低`--gpu-memory-utilization`到0.85看看。另外LoRA微调后的权重和量化校准数据可能不匹配，导致推理时某些层回退到fp16，可以检查下模型加载日志里有没有“unsupported layer”的警告。我之前跑类似场景是直接

试试用倒数层特征或者换个模型吧，ResNet50的512维全局特征对细粒度区分太弱了。

别死磕固定值，按内容段落边界切，重叠设10%-15%比固定chunk靠谱得多。

我之前也踩过这个坑，Top-K真不是个固定值。你这情况我猜是chunk粒度跟K没匹配上，512切法对bge来说偏大，试试切成256或者用滑动窗口重叠一点，召回质量会稳很多。 另外别只看Top-K，Milvus里可以调下M参数和nprobe，有时候召回乱序不是K的锅，是索引精度不够。我们项目最后是把K设在10-15之间，然后加了个rerank层，效果比单调K靠谱多了。

这坑我太熟了，当初搭多步推理的时候差点被工具调用整到怀疑人生。你日志里那个“输出搜索原文”的情况，大概率是ReAct模板里thought和action的格式没对齐，模型以为搜索完直接把结果当答案就行，压根没触发下一轮action。我试过把工具描述改成“必须终止于final answer”这种强硬措辞，稍微好点，但治标不治本。死循环那个更头疼，后来我是给循环加了最大步数限制，再在prompt里强调“

先确认下MCP的endpoint是不是填了模型服务的实际地址，我之前就是默认写成了localhost结果容器里访问不到。

我之前微调别的模型也遇到过类似只输出固定类别的问题，后来发现是数据里“其他”类的样本虽然数量够，但文本特征太杂，模型反而学不到统一模式。你试试把“其他”类单独做下聚类或者筛选一些代表样本，别一股脑全塞进去。全参数微调那个疯狂输出换行符的情况，大概率是学习率太高了，降到1e-5以下再看看，另外检查下数据格式里有没有空的system字段，我之前就是这坑。

切分512带128重叠对报销这种强语义段落其实偏大了，PDF里条款经常一段讲完一个事，建议试试按标题和章节结构切，或者干脆用200-300的chunk再加50重叠，配合bm25和向量检索混个分，能过滤掉不少无关片段。reranker确实值得加，bge-reranker-base跑起来不算重，但对这种语义区分度低的问题帮助挺大。另外你top_k调高了反而容易把噪声带进来，不如降到3-5然后看下召回质

别说512和1024了，我试过从128到2048，最后发现这事儿真不是单看chunk大小，得跟你文档的语义粒度匹配。你如果切太碎，检索时上下文信息不够，相关段落容易被埋没；切太大呢，向量平均化又把关键细节稀释了。我现在的土办法是先用一个简单的规则，比如按章节或段落标题预切分，再对超长段落做二次切分，最后用重叠窗口（比如128字符重叠）把边界内容保住，效果比死板固定大小稳得多。 embedding

2卡负载均衡比4卡张量并行稳，TTFT能压住，AWQ 4bit跑知识库够用。

我们团队之前也是纠结这个，最后选了LangChain但只用了它的核心链和工具调用，Memory和Agent那套全自己写。说实话应付飞书Jira这种场景够用了，报错至少能看懂。长期记忆直接塞向量库，Redis只放短期会话，别想太复杂，三个人的话稳定比花活重要。

试试把上一轮的回答摘要也塞进query里，比纯历史对话干净多了，过滤掉噪声效果还行。 历史对话压缩成关键词再拼进去，别全量塞，我这么改完跑偏少了不少。

我们团队之前也踩过这个坑，后来直接粗暴地按相似度阈值截断，再配合一个“信息密度”排序，就是把那些重复度高的段落先过滤掉。实测下来，召回量降到3-4个，效果比硬塞5个以上还好。另外，摘要压缩其实可以用两阶段，先粗筛再对高分段做摘要，细节丢失能接受，毕竟上下文才是硬约束。

别急着换架构，你这大概率是vllm的显存预分配和MCP的请求长度没对齐。`max_model_len`设太高，vllm会直接按这个值预分配KV cache，显存当然炸；设太低又触发截断报错。我建议先查下MCP侧有没有单独的`max_tokens`参数，有时候是它把生成长度算进了总上下文里，导致实际输入超限。 再说rope_scaling，这玩意儿调起来很玄学，特别是动态NTK在不同版本vllm里

试试在prompt里加一句“只能使用引号内的原文作答”，然后把检索片段按段落用引号包起来，效果会稳很多。

老实说，你这情况太典型了，Agent写CRUD确实跟喝水一样顺，但一上状态机这种带时序的东西就原形毕露。我后来试了个土办法，就是别让它一口气写完整个逻辑，改成让它先输出伪代码或者步骤列表，你确认完了再让它填实现，相当于给它装了个“先想后做”的开关，效果立竿见影。 另外我觉得你拆小函数的方向没错，但拆的时候得把“边界条件”也拆进去，比如直接跟它说“每个if都要写else”，或者“所有数组访问前必须

试试在系统提示里加一句“只导入实际用到的模块”，或者把agent模式切到normal，效果立竿见影。