周末写作备忘录

我也踩过这个坑，State塞大字典后期真的没法维护。后来我是按业务域拆成几个子State，每个节点只声明自己读写的字段，LangGraph的TypedDict其实能约束住。并行和循环那块的判断确实容易散，我的做法是把条件函数单独抽成纯函数加日志，图定义里只留引用，调试时能直接单测。外部存储我建议一开始就上，checkpoint用起来，不然回边跑几次状态就乱了。

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

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

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

学到了，感谢分享！

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

这个思路不错，收藏了。

学到了，感谢分享！

这个思路不错，收藏了。

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

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

几十万条1536维的向量，说实话pgvector完全能扛住，我之前有个类似规模的项目用的就是pgvector，配上HNSW索引延迟挺稳的，而且metadata过滤直接走SQL，省得你再维护一套过滤逻辑。但如果你后面向量量级要往百万甚至千万走，那还是趁早换专业的向量库，迁移成本后面会更高。Milvus单机部署确实偏重，etcd、minio一堆依赖，运维心智负担不小，不过它的索引类型和调优空间更大，延

loss降不代表模型学到了有用东西，5000条数据跑3个epoch，2e-4学习率对LoRA来说偏高了，很容易过拟合到那些套话模板上。建议先降到1e-4甚至5e-5试试，epoch也减到1-2，然后重点检查下你的数据格式，instruct模型微调时prompt模板和special token有没有对齐。还有个可能是你数据里本身就有一堆“好的我理解”这种客服客套话，模型只是学会了复读高频模式，得把这

你有没有把检索结果拼进训练样本里？不然模型肯定学成背答案了，生成时根本不看检索。

loss在0.9卡住挺常见的，先查查数据里是不是混了太多重复片段或注释噪声。

你这个“相关但不精准”的描述挺典型的，我之前做PDF手册问答也踩过类似的坑。固定500字切分对技术手册其实不太友好，尤其是配置类内容，步骤和上下文经常被拦腰截断，检索时很容易把“安装CUDA”和“配置GPU环境”混在一起，因为它们语义上本来就挨着。bge-large-zh本身不差，但它对chunk的语义完整性很敏感，碎片太多时再强的模型也拉不回来。你可以先别急着换embedding，试试按标题或段

我后来是让模型输出固定格式的JSON，里面带一个"answerable"字段，检索到的内容撑不起来就标false，比纯靠prompt让它自觉靠谱多了。另外你可以试试把问题先做一次query改写，拆成子问题逐个去检索，缺哪块它反而更容易暴露出来。阈值调高召回掉得厉害这个坑我也踩过，感觉单纯调阈值不如在rerank那层加个打分过滤。

我踩过一模一样的坑，4个工具串起来就开始鬼打墙。后来发现关键不是temperature，而是ReAct的prompt里工具描述太模糊，模型分不清“查数据库”和“计算”的边界。我改成每个工具加几个few-shot示例，明确什么时候该调用谁，稳了不少。多步任务确实别硬靠Agent自己规划，可以试试拆成固定workflow，或者上LangGraph把流程节点画出来，比纯ReAct靠谱。

固定500切块对技术手册确实容易切碎，配置步骤经常跨段被拆开，top_k调再大也救不回来。我之前也踩过这坑，换成按标题层级递归切块后召回明显好转，你可以先试试MarkdownHeaderTextSplitter那套思路。至于评估，别光靠肉眼，搞个几十条问题加标准答案的小测试集，算一下命中率就够了。embedding倒不一定背锅，bge-large在中文技术语料上一般够用，先动切块性价比更高。

7B模型在单卡上跑torch.compile确实挺容易踩坑的，graph break多半是HuggingFace模型里那些动态控制流搞的，编译不出来反而白折腾。我之前也试过，后来把mode设成"default"配合dynamic=False才稍微好点，但显存涨是必然的，它要缓存编译图和中间结果。建议先跑个profile看看瓶颈到底在不在kernel launch上，如果本来就是compute-bo