一线知识管理手记
Lv.1主要整理知识管理相关的学习笔记与工程经验，内容覆盖架构设计、问题排查与调试。更关注能够真正落地的方法，希望把复杂问题讲清楚、把实践步骤写完整。
发表的评论
rank=16其实不算小，但LoRA掉通用能力这事挺常见的，问题往往不在rank本身，而是你只喂了领域数据，模型把原来那点分布给挤掉了。我之前也踩过这坑，后来把通用指令数据按1:3到1:5混进去一起训，GSM8K掉得就少很多了，基本能守住九成。两张3090跑全量8B不太现实，除非上FSDP+offload，折腾下来性价比很低，不如先把数据配比调好。另外你可以试试只对后面的层加LoRA，或者把alp
MemorySaver确实只适合本地调试，生产环境得换Redis或Postgres的checkpointer，不然状态全堆内存里不炸才怪。循环超过5轮内存暴涨，我怀疑是每轮的历史消息没做裁剪，state里messages越滚越大，加个trim或者只保留最近几轮试试。子图那块父图子图共享state是直接读写同一个key，Send API是并发分发用的，场景不一样，别混着用。死锁倒没遇到过，可以看看是
几十万文档加TopK 20，说实话FAISS撑住并发也没那么难，先别急着上分布式。Qdrant我踩过，单机Docker起一个就能扛中小流量，metadata过滤和payload索引都挺顺手，比Milvus那套etcd+MinIO的堆栈轻太多了。你们要是团队没人专门维护基础设施，Pinecone账单失控的风险其实比自部署更可控，加个用量告警就行。建议先拿Qdrant单机跑个压测，别在选型上耗太久，R
这个思路不错，收藏了。
有没有更详细的教程推荐？
写得挺好，建议补充一些性能数据。
写得挺好，建议补充一些性能数据。
我之前也遇到过类似问题，后来换了方案。
这个思路不错，收藏了。
这个思路不错，收藏了。
学到了，感谢分享！
我之前也遇到过类似问题，后来换了方案。
我之前也遇到过类似问题，后来换了方案。
写得挺好，建议补充一些性能数据。
这个思路不错，收藏了。
Prompt工程肯定有用，但没网上吹得那么神。我自己跑了几千张图下来，感觉核心就两点：模型选对、提示词结构清晰，剩下的画质词堆再多边际收益也很低。你说的分析工具可以试试prompthero或者sd-metadata这类，能反查图片的生成参数，比自己瞎试强不少。
pgvector的filter是后置的，先召回再过滤，过滤完可能就没几条了。试试先where再排序，或者用分区表。
单模型单工具确实没必要上，多模型多工具切换时省去重复适配才是真香。
这种场景我一般不会硬塞完整文档，而是让Agent先做一轮摘要再进主流程，虽然多一步但稳定很多。关键指令最好别依赖后面的内容，实在绕不开就拆成两个子任务串行跑。长上下文模型我也试过，贵不说，中间信息还是容易被稀释，不如分块加显式引用靠谱。
我最近也踩过类似的坑，后来发现关键不是把需求描述得多细，而是让模型先输出伪代码或逻辑分支树，确认无误再让它翻译成Python。另外动态SQL拼接这种场景，我会强制它先列出所有边缘case的断言，再生成带单元测试的代码，跑不通就让它根据报错自己修。单纯靠prompt优化确实有上限，配合测试驱动的方式会稳很多。