算法随想
Lv.1主要整理算法与工程实现相关的学习笔记与工程经验，内容覆盖项目复盘、代码可维护性。相信长期积累胜过短期追热点，希望把复杂问题讲清楚、把实践步骤写完整。
发表的评论
说实话我也遇到过类似的情况，尤其是inplace这个参数，我试过好几次它默认False导致原df没变，后来干脆每次都显式写清楚。不过我觉得这跟prompt关系不太大，可能模型对这类细节的上下文记忆还是不够稳，你试试把需求拆得更细一点，比如直接告诉它“不要用inplace，重新赋值给新变量”可能好很多。 另外异常处理这块，我习惯在prompt里加一句“所有网络请求必须带try-except并重试两
LangGraph确实能解决这问题，状态机管理并发比全局变量稳多了，token存session里就行。 你这场景直接上LangGraph呗，节点化设计天然支持复用，并发冲突也能避开。
few-shot在RAG里确实容易带偏模型，示例和检索内容冲突时它就放飞自我了，不如只靠system prompt约束。
我觉得你这问题大概率不是rerank的锅，bge-m3的向量召回本身够用了，真正的坑在“检索片段冗余”。top5里每段都512字，里面可能只有一两句是真正相关的，模型很容易被那些细节带偏。你可以试试在生成前做一步“关键句压缩”，比如用LLM把每个chunk提炼成摘要再拼进上下文，或者干脆用text-ranker之类的模型先对句子级别打分，只保留最高分的几句。另外qwen2.5-7b对长上下文的理解
1亿条768维这个量级，单机SSD跑实时召回确实有点勉强。建议先确认下是不是内存根本没装下索引，Milvus的mmap模式有时会退化成磁盘扫描。另外IVF_FLAT在数据量大了以后召回率会掉得厉害，HNSW对内存要求高但速度快很多，可以试试把索引换成HNSW，M和efConstruction调大点，nprobe改成efSearch试试。 2. 你这情况大概率是索引构建和查询参数没匹配上，1亿条数
max_length砍到1024试试，bf16下7B光激活值就吃紧，LoRA也没省多少。
说实话这问题我纠结过挺久，最后留在了PyTorch。JAX那套函数式写法在MCP里确实省心，但调试成本太高了，服务端一上线哪有功夫跟编译错误死磕。你的场景要是偏部署，不如先用PyTorch把推理链路跑通，上下文传递其实靠MCP的协议层就能规范，不一定非要动框架。真要优化的话可以看看torch.compile，能蹭到不少JAX那种静态图的好处。 PyTorch生态里能直接抄的现成方案多，MCP这头
这个坑我踩过，微调确实容易让模型「记住」训练数据里的知识，反而忽略检索来的上下文。建议试试LoRA之类的高效微调方法，冻结大部分参数只改少量适配器，同时在训练数据里故意混入一些检索结果和模型记忆冲突的样本，让模型学会优先采纳检索内容。另外可以试试在指令里明确强调「请严格依据以下文档回答」，微调时把这句话也加到模板里强化一下。