慢热Go玩家手记
Lv.1一名专注于Go后端开发的服务端开发者。日常记录高并发与性能优化、项目落地经验和项目中的问题解决过程；更关注能够真正落地的方法，也会分享真实项目中的判断过程与改进记录。
发表的评论
动态shape对不上的问题我也踩过，大概率是某些插件或算子走了CPU回退，你可以开verbose日志看哪些层被切了。工业检测这种场景batch不固定，固定batch省事但灵活性差，建议先把onnx导出时shape设成dynamic axes，再用polygraphy跑一遍对比输出定位到具体层。trtexec那个报错是因为你用的explicit batch模式，必须配合profile的min/opt
这个场景我踩过坑，Redis存历史拼接prompt的做法轮次一多必然失控，token烧得心疼还容易串槽位。LangGraph的状态图看着吓人，但真用起来槽位隔离和条件跳转比手搓if-else清爽太多，尤其改需求时直接重置对应节点就行。带session_id的记忆API省事但黑盒，调试时你根本不知道它为什么记错，客服场景对可控性要求高的话不太敢用。建议花两天啃个最小demo，比继续在prompt里打
13B模型四卡每卡batch 2确实偏小，梯度累积8步虽然等效batch上去了，但DDP的梯度同步是每步都做的，累积期间各卡梯度噪声叠加，前期震荡很正常。可以先试试把梯度累积期间loss scale或者用bf16混合精度稳一下，V100不支持bf16的话fp16记得开dynamic loss scaling。另外torch.compile在DDP下有些版本确实会有梯度同步的坑，先关掉compile
7B模型做售后问答确实有点吃力，光靠prompt调来调去天花板就在那。我建议优先上RAG，把退换货政策、物流规则这些做成知识库检索，比塞system prompt靠谱多了。另外FAQ写进prompt容易让模型混淆边界，不如让检索结果来约束回答范围。如果预算允许，换个14B以上的模型效果会明显不一样。
时间加权确实有用，我一般还会在检索前先按session过滤一下，能挡掉不少跨话题的噪音。
多步任务断掉挺常见的，不一定是Prompt的问题。Agent在DataFrame那步卡住，多半是因为中间结果太大、上下文塞不下，前面的东西就被挤掉了。可以试试把每个步骤的中间结果落盘，比如存成parquet或csv，让Agent只传文件路径而不是数据本身。另外LangGraph比单纯用AgentExecutor稳一些，能显式管理状态和节点，断点续跑也好做。
维度不是越高越好，ada-002的1536维里其实有不少冗余，降维到512配合PCA或者直接用Matryoshka模型确实能提速，但召回变差说明信息损失了。384维的sentence-transformers跟1536维千万别混用，不同模型的向量空间根本不兼容，得统一用同一个模型重新索引。你那个准确率问题我怀疑不是维度的事，可能是chunk切分或者没加rerank，先试试在检索后接个cross-e
学到了，感谢分享！
这个思路不错，收藏了。
写得挺好，建议补充一些性能数据。
学到了，感谢分享！
刚入门，这个对我帮助很大。
有没有更详细的教程推荐？
这个思路不错，收藏了。
学到了，感谢分享！
有没有更详细的教程推荐？
这个思路不错，收藏了。
写得挺好，建议补充一些性能数据。
我也遇到过类似情况，Claude 3.7在前端确实有点过度设计倾向。后来我改了个prompt策略，明确告诉它只改指定部分、不许动其他代码，效果会好不少。另外可以试试让它先输出改动计划，你确认后再动手，虽然多一步但省得debug。不过说实话它重构的代码质量不差，就是老爱自作主张这点挺烦人。
几万条笔记Chroma完全够用，别被“生产环境”吓到，MCP场景延迟才是关键。