周末开源手记

resource这招我也试过，效果确实看场景。感觉Claude对resource的主动读取优先级没那么高，除非你把它和工具调用绑在一起，强制它先读再写。另外prompt模板塞太多反而容易稀释重点，不如把最关键的几条规范直接写进system prompt里，剩下的细节再走resource。

说实话这是个特别典型的坑，我之前也踩过。你现在的做法其实没错，但漏了多模态这一层，纯文本向量根本覆盖不了图表信息。图片得单独过一遍视觉模型（比如CLIP或者那种能出图向量的模型），把生成的向量也存进Milvus，同时把图表里的关键数字、标题、结论用文本描述出来一起存，这样检索的时候才能双路召回。另外建议你建个映射关系，文字块和图片向量要能关联到同一个文档ID，不然就算召回了图片，系统也不知道该回哪

跟你情况差不多，bge-small确实有点弱，尤其法律条款这种专业场景，换个bge-m3或干脆用text-embedding-3-large试试，召回准头能提升不少。rerank别犹豫，直接上，特别是top3混入无关内容时，cross-encoder一过滤效果立竿见影，延迟多几十毫秒但值。至于向量库对比纯塞prompt，数据量大了以后准确率其实没差太多，但延迟和成本优势明显，主要坑在chunk切分

试试把top_k调小点，再给召回加上关键词过滤，这类技术文档术语匹配还挺管用的。

6G显存跑7B确实挺极限的，我之前用2080（8G）试过Qwen-7B，FP16勉强塞进去但生成时显存直接爆掉，后来换4-bit才稳定。你提到bitsandbytes慢，大概率是因为加载时没开`bnb_4bit_compute_dtype=torch.float16`，这个选项能明显提速，否则默认fp32计算会拖死你。另外torch.compile对量化模型收益不大，反而可能因为动态图编译报错，建

说实话中兴这次确实让我有点改观，OEX超节点强调的“极致协同”比单纯堆参数实在多了，毕竟大规模训练最怕通信瓶颈。不过全栈这东西，链路越长越容易掉链子，我比较好奇OEX跟AIOS的适配是深度定制还是拿现成框架套壳，这直接决定实际落地效率。要是真能打通底层调度，那端侧AI的体验质变就有戏了。

说实话你这问题我太有同感了，之前用RAG做记忆模块也踩过类似的坑，后来发现光调chunk size和top_k根本治标不治本。我的经验是，记忆这种场景得先区分“事实查询”和“语义召回”，你问“上次讨论的API设计修改”本质上是时间线+主题的混合检索，纯向量相似度很难捕捉到这种上下文关系。建议你可以试试在分块时保留一些元数据，比如文档标题、章节层级、更新时间，然后检索时先用关键词过滤一次范围，再做向