周末机器学习方法论

几十万条faiss其实够用，慢可能是没建IVF索引。Milvus个人项目真没必要，Qdrant单机版轻多了可以试试。

OTA分层管理确实是关键，不然海外用户收到货连不上WiFi就尴尬了。

几万chunk真没必要上Milvus，那套etcd加minio的部署对个人项目纯属折腾。我自己的知识库十几万向量用Chroma跑着，召回延迟完全能接受，瓶颈往往在embedding和rerank那一步。等真到了百万级或者要多租户并发再考虑换，Chroma的接口设计迁移到Qdrant也不难。先跑通业务逻辑比纠结选型重要多了。

我也遇到过，后来把指令放最前面、上下文用分隔符隔开，再明确说“没找到就说不知道”，稳了不少。

这个我踩过类似的坑，YOLOv5转ONNX其实最容易出问题的是后处理那块，尤其是anchor解码和NMS，有时候不是模型本身数值差，而是导出时把decode逻辑也带进去了导致对不齐。你可以先只导出backbone+head，把后处理放到外面用numpy或onnxruntime自己写，看看置信度还差多少。另外opset 12对slice和focus的支持确实有点坑，试试换成opset 11或者13对

这个情况挺典型的，LoRA微调翻车大概率不是rank的问题，16对8B模型来说不算小。我第一反应是学习率2e-4偏高了，LoRA通常1e-4到2e-4是给大点的数据集或者全参数量级用的，你这2万条跑3个epoch，模型很容易过拟合到你的数据分布上，把基座的中文通用能力给冲掉了。蹦英文这个现象我遇到过，一般是训练数据里混了英文回复或者system prompt里有英文，模型在生成时被带偏了。另外你提

我遇到过类似情况，后来发现关键在检索前。单纯调chunk size确实两头堵，不如按文档结构切，比如按标题层级拆，保留父子关系，召回时把父块也带上。另外rerank阶段可以加个连贯性打分，看相邻片段有没有语义重叠或指代关系。你试过用句子窗口检索吗？就是命中句子后往回扩几段，比单纯重叠窗口自然多了。

温度设0不代表不跑偏，采样策略和上下文长度也得调，光靠Prompt稳不住。

这个坑我踩过，确实挺隐蔽的。你本地的pipeline里大概率是硬编码了top_k和阈值，模型直接按固定参数走，但换成MCP tool调用之后，这些参数变成了模型自己填，它经常拍脑袋给个top_k=5或者干脆不传，检索面一下就窄了。而且MCP的tool schema如果描述得含糊，模型很容易把query改写成它以为的样子，跟你原始问题偏离挺多，召回的自然就不对味。建议先把tool的input sch

6G显存跑7B int4确实有点勉强，显卡层数给到20左右就差不多到顶了，剩下的全压内存里速度肯定崩。你试试把上下文长度砍到2048，线程数设成物理核数别开超线程，能快个两三成。但说实话代码补全这活儿7B本身就一般，换成Qwen2.5-Coder-3B或者4B反而更跟手，体感差距没你想的那么大。

4090跑7B QLoRA其实挺极限的，24G显存开gradient checkpointing是必须的，不然光激活值就能吃掉好几个G。你试试把`gradient_checkpointing=True`加上，再把`per_device_train_batch_size`保持1，应该能缓解不少。另外5000条QA对不算少，如果序列长度超过1024，建议把`max_seq_length`砍到768或5

先粗分类再各自建索引确实有用，另外可以试试用重排序模型把召回的topN再精排一遍。 试试用摘要做第一轮粗筛，再用向量检索只搜候选子集，能减少合同串场的情况。

ChromaDB这个坑我也踩过，数据量上来后load确实是个大问题。你可以试试把向量库换成Qdrant，它有持久化存储，重启不用重新加载，查询速度也稳很多。另外如果只是给Claude加记忆，其实用sqlite-vec这种轻量方案可能更省心，不用单独跑服务。不过得看你的文档量级，几千条以内我觉得本地文件型够用了。你目前大概存了多少条记忆？

我之前也踩过这个坑，LangChain的AgentExecutor在工具间传递上下文确实有点“健忘”，本质是它默认只保留当前step的observation，之前的中间结果被覆盖了。你可以试试把工具返回的结果显式塞进prompt模板里，或者改用一个自定义的memory对象，把每一步的关键输出都存下来再拼接。另外，你那个“销售额”和“客户”其实是两个独立查询，不如先合并成一个工具，或者用Conver

我之前也踩过这个坑，后来干脆把流式输出和回调全收拢到一个事件队列里，前端只消费队列里的消息类型，token和工具调用都带个标记，这样UI刷新和拼接就同步了。另外Agent内部工具调用时流式中断，其实可以手动在工具回调里发一个特殊事件，让前端显示个“正在调用工具”的占位，别硬等流式。感觉核心思路就是别让回调直接改UI，统一走消息总线会清爽很多。

这问题我踩过，别急着换embedding，先试试rerank，小模型就够用，提升比调chunk明显。

试试把state schema里所有字段都设成Optional并给默认值，之前我也被这个坑过。对话历史建议放Redis，全塞state里迟早爆掉。

这问题太典型了，我当初也踩过这坑。topk拉高之后噪音确实多，可以试试先按相似度分数做个硬截断，比如只留top3，再配合一个rerank模型把最相关的挤到前面，效果立竿见影。另外，你那个年假的例子，本质是chunk粒度太粗或者索引字段混了，不如在入库时给每个chunk打上部门或文档类型的标签，检索后按标签做个简单过滤，LLM就不会被带偏了。

合同提取这种任务建议直接上ShareGPT，多轮上下文对复杂规则理解帮助很大。混着训练容易跑偏，最好按场景拆开训。

这问题我也踩过坑，COT适合拆解逻辑，但别指望它自动选最优算法，直接限定伪代码和复杂度要求更靠谱。 思维链确实容易让模型钻牛角尖，你该告诉它“用快排思路”，再给个具体分治步骤，比让它自由发挥强多了。