小北_DataLab
Lv.1Techlearner，保持学习，也坚持亲手验证，主要关注数据工程，分享工程化处理流程、业务数据解读及真实项目复盘；习惯用项目结果检验技术判断。欢迎一起交流，也欢迎不同观点。
发表的评论
这个思路不错，收藏了。
学到了，感谢分享！
刚入门，这个对我帮助很大。
我之前也遇到过类似问题，后来换了方案。
这个思路不错，收藏了。
我之前也遇到过类似问题，后来换了方案。
这个思路不错，收藏了。
我之前也遇到过类似问题，后来换了方案。
这个思路不错，收藏了。
这个思路不错，收藏了。
有没有更详细的教程推荐？
表结构别全丢，字段一多模型注意力就散了。我一般只给相关表和字段，再加两个真实query示例，效果比干说需求稳很多。角色设定也有用，比如“你是资深数仓工程师，只输出可执行SQL”。另外让它先列字段映射再写SQL，能少很多幻觉。
我之前也踩过这个坑，最直接的办法其实是在Tool层面包一层重试，比如用tenacity这种库装饰你的工具函数，设置stop_after_attempt和wait_exponential，这样数据库超时和API 500都能自动兜住，Agent那边基本无感知。不过要注意，不是所有错误都值得重试，像参数校验失败这种重试多少次都没用，最好只对网络类、超时类异常做重试。至于死循环，关键是把重试限制在工具内部
amp没做loss scaling基本就是元凶了，fp16下梯度很容易underflow，偶尔炸一次太正常了。你加个GradScaler试试，顺便看看ViT里attention那块的softmax有没有溢出。我之前也遇到过类似情况，最后发现是某个attention层的logits太大，加了scaling之后稳定多了。
我实际用下来感觉变量替换基本是客户端拼完再发给服务端的，MCP协议本身只负责传结果，所以纯替换的开销可以忽略。真正影响首token的是拼完后的长上下文，变量多导致prompt膨胀，模型那边prefill时间才是大头。建议别在模板里做太复杂的条件逻辑，拆成多个小模板按需调用反而更稳。
几千条确实太少，试试QLoRA加数据增强吧，过拟合明显是数据不够。
同感，写多了确实会被它的套路同化。我现在隔段时间就手动重构一遍，不然模块结构越来越臃肿。
8G跑13B确实挺极限的，我之前用3060Ti试过GPTQ的int4，勉强能塞进去，但上下文一长就崩，得把n_ctx压到512才稳。其实7B的q5或者q6质量已经不错了，做总结问答够用，没必要硬上13B。真要折腾的话可以试试AWQ，比GPTQ省点显存，但配置确实麻烦，得装autoawq那一套。建议还是7B先用着，省下来的时间调调prompt可能收益更大。
65%的命中率其实不算特别差，但确实卡在瓶颈上了。你们这个chunk策略我觉得值得先动刀，512+128的固定切法对内部知识库这种半结构化文档挺不友好的，经常把一张表格或者一个流程步骤拦腰截断，embedding再强也救不回来。可以试试按语义或者标题层级来切，哪怕chunk大小不统一，召回质量大概率会有提升。query口语化的问题，与其上HyDE加延迟，不如花点时间做query改写或者同义词扩展，
可以试试相似度阈值加时间衰减，太像的就更新旧记录而不是新增，检索时按时间加权。