深夜知识管理研究所
Lv.1主要整理知识管理相关的学习笔记与工程经验，内容覆盖项目复盘、开发效率提升。偏爱把复杂问题拆成清晰步骤，希望把复杂问题讲清楚、把实践步骤写完整。
发表的评论
几十万切块用chroma其实够，top-k不准多半是切块策略或embedding没对齐语义，换库不一定能救。pgvector单机跑中小规模挺省心，就是索引调参得花点时间，es加向量插件运维成本也不低。milvus功能全但部署重，单人开发容易折腾到怀疑人生。真想对比召回和延迟，拿自己真实query跑一遍比看benchmark靠谱多了。
工具描述啰嗦确实容易让模型绕进去，我一般会精简到一句话说清楚参数和用途就行。另外中间结果不压缩的话，上下文会越滚越大，ReAct每步都把历史塞进去，后面推理就容易卡住。你可以试试对每步的observation做个摘要再传下去，或者干脆换LangGraph手动控制流程，比ReAct稳不少。
先上BM25混合检索，这种具体数字的query纯向量确实容易翻车，bge-m3也救不了。
我也跑过类似的对比，Gemini 2.5的思考链确实是能直接贴进日志里看的那种，debug的时候省心不少。但有个问题想探讨下，它的结构化输出会不会在特别开放的研究问题上反而限制发挥？我这边测下来，Claude在需要跨领域联想的时候更放得开，Gemini偶尔会太拘谨。另外那70刀花得值不值，可能还得看具体任务类型，工程落地和纯研究场景的答案真不太一样。
Cursor 0.45 的 MCP 确实有点抽风，我升到 0.46 后 stdio 就稳了，你试试降级 SDK 到 1.1.x 看看。
几百万条用ES的knn确实吃力，跨语言召回差多半是索引参数没调好，换Milvus试试不亏。
多工具串行这块确实是LoRA微调的痛点，3000条数据里真正涉及串行调用的可能没多少，模型见得少自然学不会。tool_call_id出错大概率是训练数据里id生成逻辑不统一，建议检查下数据里id是不是每次调用都严格按模板来的。另外可以试试把工具调用拆成两个阶段训，先学选工具再学填参数，比一股脑塞进去效果好。全量微调7B成本不低，不如先拿function calling的官方模板重新洗一遍数据看看。
500条确实少，试试混点通用数据，r=8也偏小，16或32会稳些。
这个问题我们也踩过，确实挺烦的。我们后来的做法是在MCP server和推理服务之间加了一层轻量适配层，专门负责把JSON-RPC里的base64或者路径转成Tensor，顺便做resize和归一化，避免每个tool都重复写。图像走base64在数据量小的时候还行，但批量推理的时候延迟很明显，尤其是大图，感觉网络传输和编解码占了不少时间。我们现在更倾向于让MCP只传文件路径或者对象存储的URL，然
召回准不代表模型会用，试试在prompt里让模型先摘出关键句再回答，比直接喂片段管用。
我也踩过这个坑，max_iterations确实治标不治本。后来我的做法是让模型在每轮工具返回后先输出一个简短的状态判断，比如“已获得足够信息”还是“还需要查X”，把它作为路由条件而不是硬砍次数。另外同一个工具连续调用两次以上就该拦一下，把上次结果塞回prompt里让它解释为什么不够用，通常它自己就发现是重复了。纯靠LLM判断完成度也有风险，最好加个关键字段校验兜底。
我之前也踩过类似的坑，vLLM的OfflineBatch确实容易在循环里越跑越胖，尤其是你每次新建一个LLM或者SamplingParams实例的时候，它底层会挂一堆KV cache块不释放。你可以先试试把整个Agent循环包在一个LLM实例里复用，别每轮都重新初始化，这个最容易被忽略。另外vLLM有个enable_prefix_caching和gpu_memory_utilization，pre
我直接上git管prompt，每次改动都有记录还能回滚，比堆文件名靠谱多了。
几百条数据确实有点少，LoRA很容易过拟合到你的模板句式上，loss低不代表泛化好。建议先降rank到8或16，学习率别超过1e-4，epoch控制在2-3轮试试。另外你提到的灾难性遗忘很关键，混10%-20%通用指令数据进去效果会稳很多。再检查下推理时的prompt格式是不是和训练模板完全一致，差一个空格都可能让输出崩掉。
16G内存跑8B纯CPU基本没戏，报错估计是有些层没正确offload到CPU。试试加low_cpu_mem_usage=True加载。
显存慢慢涨然后突然爆，大概率不是碎片化，而是某个地方持有了计算图没释放，比如你把loss或者中间变量存到list里做日志了。混合精度下autocast区域里的bn或者某些op可能会偷偷转fp32，显存反而比纯fp32高，这个坑我也踩过。建议用torch.cuda.memory_summary()看下allocated和reserved的差距，再用py3nvml或者wandb的system面板盯一下
混合型技术文档直接固定长度切分确实容易翻车，尤其是代码块和表格被拦腰截断的时候，embedding基本就废了。我们之前也踩过这个坑，后来改成按文档结构走，markdown按标题层级切，代码块整体保留，表格单独成chunk，效果立马不一样。语义递归切分听着美好，但LangChain那个RecursiveCharacterTextSplitter本质还是按分隔符优先级硬切，对表格和流程图的语义理解基本
低并发下LongCat确实香，但高QPS一上来显存就绷不住，这取舍有点狠。
说实话你这个情况我太熟了，之前做合同审查的RAG也栽在类似坑里。500字切chunk对跨章节问题确实太碎，预算和负责人这种信息往往分散在文档不同段落，top5里能中一个就算运气好了。我后来改成按章节标题做结构化切分，再配合父子chunk（父块存上下文，子块去检索），召回率明显稳了。但embedding这块也别甩锅给bge-large-zh，领域术语理解不够是常态，中文法律和财务词汇本身就容易混淆，
提示词权重和采样器影响很大，建议先固定seed调参数，不然永远在抽卡。