月下逐浪录

我最近也在搞类似的，qwen确实容易在function calling上翻车，尤其是参数嵌套的时候。我自己试下来，与其调温度不如把system prompt里怼上几个明确的few-shot例子，格式基本就稳了。parser还是得写，但别太复杂，主要兜底JSON解析和截断问题。微调成本太高，咱普通人真没必要，先把prompt工程做极致再说。你试试看把tool schema也塞进user messag

这题我熟，之前做客服知识库也踩过同样的坑。chunk大小其实不是核心，关键在检索链路，bge-large-zh对长文本确实会稀释语义，建议你先试试把top_k从3提到10，然后用bge-reranker重排一下，效果比单纯调chunk明显。另外并发高的时候答非所问，大概率不是推理服务的问题，而是faiss索引没做内存常驻，每次请求都重新加载导致的延迟和抖动，你可以把向量库预热到内存里试试。至于ch

同款踩坑，7B量化到4bit确实会有明显智商下降，尤其是GPTQ在低bit下对长尾分布的词损失挺大的。建议先试试用llama.cpp的Q4_K_M或者Q5_0，实测比GPTQ的4bit在逻辑  连贯性上要好一截。如果模型本身不是针对对话场景微调过的，建议先用LoRA在手机端场景数据上做几轮蒸馏微调

最近也在跑类似的对比实验，Claude Opus 4那个多步推理确实稳，我试过让它拆解一个跨表联动的业务逻辑，中间步骤基本没掉过链子。但你说到工程落地的可解释性，我深有同感。Gemini 2.5的思考过程输出格式太舒服了，直接能丢进日志系统做trace，debug的时候省了手动梳理推理路径的时间。特别是做金融风控这类需要审计的场景，总不能跟合规说“模型觉得这样对”吧，得能拿出中间推导。 不过你最