持续研究产品研究簿

学到了，感谢分享！

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

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

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

几千份文档光靠向量检索确实容易翻车，ada-002对这种专业术语的语义区分本身就一般。你切分的时候可以试试按标题层级来，别硬切固定长度，不然一个chunk里混了好几个主题，召回肯定乱。加reranker是最直接的解法，bge-reranker或者cohere的都行，先粗召回top50再精排，效果提升很明显。另外查询端也可以做点文章，把“数据库连接超时怎么排查”改写成几个子查询分别检索再合并，比单条

这块确实头疼，我现在的做法是把每个工具调用都包一层重试加超时，参数校验也提前做掉，不然模型经常传个格式不对的东西过来直接炸。另外工具描述写得越清楚越好，尤其是参数类型和边界条件，能省掉不少幻觉调用。你们有没有试过让模型在调用前先输出一遍参数确认？我感觉这个对稳定性帮助挺大的。

我也踩过这坑，后来加了中间结果校验提示词，让它每步先输出数字再往下算，稳了不少。

FP16掉点太正常了，尤其暗部和小目标，数值范围一小就容易溢出或者被量化吃掉细节。建议先别急着上FP16，用FP32跑一遍验证集，确认是转换本身的问题还是精度压缩的锅。如果FP32没问题，可以试试混合精度，对敏感层保留FP32，或者用trtexec的--best参数让它自己选kernel。另外ONNX导出时opset版本和动态轴设置也检查下，有时候是图优化阶段就出偏差了。

这情况太典型了，我去年也踩过一模一样的坑。你用的alpaca格式微调，本质上是在教模型“看到这种指令就按这个套路答”，但你的prompt模板里塞了角色设定、步骤拆分、few-shot，这些结构在微调数据里大概率没出现过，模型一微调就把原来的指令跟随能力给带偏了。学习率2e-4对LoRA来说有点猛，一个epoch虽然不多，但7B模型很容易过拟合到微调数据的表面格式上，把之前RLHF学到的“仔细看指令

我之前也踩过这坑，后来发现大概率不是框架的锅，而是工具调用那块容易死循环。gpt-3.5-turbo对function calling的支持其实有点飘，尤其工具返回格式稍微不对，它就会反复重试同一个动作。建议先开verbose看下日志，确认到底是卡在网络请求还是卡在Agent的循环里。另外本地循环试试把max_iterations调小点，别让它无限转下去。

你是不是没用agent的return_intermediate_steps？工具输出默认不会自动进对话历史，得手动把它拼回prompt里。我一般是在callback里把ToolMessage抓出来，塞进memory的chat_history再走下一轮。另外AgentExecutor本身确实不帮你保留工具结果，这块得自己接。

bge-large换bge-small或m3e-base确实能快不少，精度掉得没那么夸张，可以先试试。几秒的延迟多半不是模型本身，而是每次都在重新加载索引或者embedding没做缓存，FAISS索引启动时load一次常驻内存就行。另外检索和生成完全可以异步串起来，用户问题一到就并行跑embedding和query改写，别等检索完再启动模型。如果知识库不大，也可以考虑把top-k调小配合重排序，比

做应用开发的话真没必要死磕torch.compile，我去年也折腾过一阵，编译慢不说，动态shape一多就各种回退，最后发现还不如直接上vLLM来得省心。它那个CUDA graph和paged attention对显存的优化是实打实的，你调LLM推理的话优先考虑这套。torch.compile更适合你自己写模型想榨性能的场景，或者等它生态再成熟点。现在这阶段把它当个锦上添花的工具就行，不用有学习焦

我之前也踩过这个坑，后来试了Qwen2.5-14B-Instruct，感觉是个不错的折中。速度比72B快不少，工具调用的准确率又比7B稳太多，基本能满足Agent多步推理的需求。如果显存够的话建议直接上14B，不够就量化到4bit跑，损失也不算大。另外LangGraph那边可以把一些简单意图路由拆给7B做，复杂决策再交给大模型，混着用效果挺好。

维度不是越高越好，关键看模型和场景，混用不同维度得各自建索引再融合，别硬拼。

微调能治标但数据得下功夫，工具定义混着正反例一起喂，不然换个问法照样翻车。

我一般会在项目根目录放一个.cursorrules文件，把关键依赖的版本和用法示例写进去，比在prompt里临时说管用多了。Pydantic v2和v1的差异确实坑，我直接贴一段v2的model_config示例给它看，后面基本就不乱写了。不过说实话，依赖这块我还是会自己过一遍，AI当草稿用就行，别全信。

编号和分隔符真的有用，我习惯给每个chunk标上[1][2]，然后要求模型引用时带上角标，缝合情况少了很多。另外“原文没有就直说不知道”这句最好写成硬性规则放开头，别放在末尾，模型对前置指令更敏感。开源模型确实得更直白，像Qwen得反复强调“只能依据上文”，GPT-4相对省心但也别指望它百分百老实。

我之前也踩过这个坑，7B量化在CPU上跑并发基本没救，延迟比云端还离谱。后来换成vLLM加GPU，单路快很多，但MCP场景请求零散，资源利用率又上不去。传输这块HTTP轮询确实拖后腿，可以看看MCP的SSE或者streamable HTTP，首token能快不少。云端API胜在省心，就是波动真看运气，敏感场景建议做超时和降级兜底。

这个坑我踩过，而且踩得挺深。你遇到的问题其实挺典型的，CoT对任务类型很挑，不是万能药。像客服问答这种场景，很多问题本来就是查表或者匹配意图就能搞定的，你让它一步步推理，等于逼着模型去“编”一个不存在的思考链条，反而把简单问题复杂化了。我之前也试过在系统提示里加类似的话，结果模型连“今天天气怎么样”都要给我分析三步骤，纯粹是浪费token。后来我的做法是分场景处理，简单意图识别类的请求干脆不加任何