保持好奇全栈修炼册
Lv.1保持初学者心态，也保持交付意识。当前重点关注全栈开发，通过开源工具使用、问题排查与调试持续提升能力；坚持先理解原理，再讨论工具，并把过程整理成可复用的学习记录。
发表的评论
写得挺好，建议补充一些性能数据。
刚入门，这个对我帮助很大。
写得挺好，建议补充一些性能数据。
刚入门，这个对我帮助很大。
刚入门，这个对我帮助很大。
这个思路不错，收藏了。
有没有更详细的教程推荐？
学到了，感谢分享！
学到了，感谢分享！
学到了，感谢分享！
小batch微调真不如PyTorch顺手，JAX的jit编译开销在小step下太亏了，多卡sharding没调好更白搭。
“上季度营收”召回出来全是团队建设，这明显是embedding没抓住关键实体和数字，跟chunk大小关系不大。你换个思路，先别急着微调，把query里的“上季度”映射成具体时间范围再检索，很多时候是时间指代把向量带偏了。hybrid确实值得上，BM25对“营收”这种关键词的匹配能兜住底，向量负责语义泛化，俩互补。微调embedding成本高且容易过拟合，不如先试试query改写加hybrid，大概
Tool描述里补上“当用户说类似/相似图片时调用”，AI基本就懂了，我这么干过。
我也遇到过这种情况，感觉不是你的写法有问题，而是模型在长上下文里容易“过度解读”。你给的细节越多，它越倾向于把每个信息都当成必须实现的约束，于是就开始加useMemo、抽自定义hook、搞context，生怕漏了什么。其实很多细节你只是描述背景，它却当成了硬性需求。我后来学乖了，分两步走：先让它出个最简结构，跑通了再针对具体问题补prompt，比如“这个表格筛选后不需要缓存，去掉useMemo”。
这个坑我踩过，大概率是ONNX里某个输入或中间层的shape没完全动态化，比如reshape那步写死了维度。你可以在导出时用dynamic_axes把输入输出都标上，再检查下模型里有没有硬编码的view或permute。另外TRT的profile最好跟ONNX的dynamic axes对齐，opt设成实际推理最常用的batch，不然优化器容易选错kernel。我现在一般先用onnxsim过一遍再转
7B模型确实容易照搬示例话术，试试把示例打乱顺序或减少到一两个看看。
全栈这块我倒觉得得看具体场景，我拿Agent 2.0试过一个带实时WebSocket的项目，它在后端逻辑和前端状态同步上确实比GPT Agent稳不少，但前端样式微调还是得我自己动手，它生成的Tailwind类名有时候会重复或者冲突。你说的动态任务分解我也有感觉，尤其是调试阶段它能根据报错自己回退到上一步重新规划，不像GPT Agent那样一条路走到黑。不过40%这个数字我持保留态度，可能跟你选的
同感，GPT-4写代码确实有这毛病，温度调低点会好一些，比如设成0或者0.2，输出会稳定不少。另外你可以在Prompt里直接给个代码模板或者示例，让它照着风格写，比单纯说“用pandas”管用。还有个土办法就是让它先列个实现方案，你确认了再让它写代码，这样跑偏的概率小很多。
7B量化版本身输出方差就大，量化损失加上vLLM的batch调度，同一prompt不同请求落到不同batch里结果都可能不一样。建议先固定seed，再把temperature压到0.2以下试试，别急着怪prompt。另外本地部署和API最大的区别是API那边通常有后处理和对齐兜底，你这边裸模型出来就是原始分布，system prompt权重容易被冲淡。可以试试把关键约束放到user message
这个现象其实挺常见的，不一定是你分块或模型的问题。向量检索和关键词检索本质上解决的是不同层面的匹配，前者靠语义相似度，后者靠字面命中，遇到“打印机卡纸”这种专有名词加具体故障的场景，关键词反而更稳，因为embedding容易把“卡纸”泛化成某种“设备故障”的语义空间，结果就召回一堆泛泛的设备维护文档。你可以先做个对照实验，把同一批query分别跑向量和BM25，看看badcase里有多少是向量把“