周末设计手记

我之前也踩过这个坑，检索排不准不一定是embedding的问题，可能是chunk切分或者rerank没做好，先别急着微调。如果领域术语确实偏门，只调embedding性价比最高，LLM那边靠few-shot和prompt基本能兜住。但你要是发现模型连指令都理解歪了，那再考虑上LoRA调LLM。训练数据不用跟检索文档结构一模一样，但query-doc的配对逻辑最好贴近真实检索场景，不然白调。

我一般把共享状态收拢成一个字典，节点只读写自己那部分，别让图结构跟着交互走。

2万条数据微调BERT其实够用了，先查查标注一致性吧，法律文书类别边界模糊很容易标错。

我目前是走SSH隧道+本地端口转发，MCP服务只监听127.0.0.1，IDE那边连localhost就行，token都省了，安全也稳。WebSocket这块你理解没错，官方transport主要就是stdio和HTTP/SSE，WS得自己包一层，不太划算。反向代理加HTTPS也行，但证书和鉴权配置起来比隧道麻烦不少。

两张3090跑7B还OOM，八成是没开gradient checkpointing，dataloader batch先降到1试试。

混合文档建议按标题层级切，表格和代码单独处理，overlap留10%到15%就够，再配合rerank效果会好很多。

我之前也遇到过类似情况，感觉提示词细化只是一方面，模型对长链的“注意力漂移”确实是个硬伤。你可以试试把中间步骤拆成独立的子问题，每一步只让它算一个值，算完再喂给下一步，别指望一次走完。另外加个“每步必须引用上一步的结果”这种约束，有时候能逼它别跳步。不过说实话，金融数值推理这种，完全靠CoT还是有点赌运气。

温度影响整体概率分布，top_p只截断尾部，俩一起调容易互相打架，建议先固定一个。JSON输出我一般温度0加top_p 1，但Qwen确实比Llama更吃top_p的变动。

3090上8B FP16确实吃紧，我实测vLLM的PagedAttention对KV cache碎片控制更好，同样batch size=2能跑但TGI偶尔会OOM，极限并发大概3-4左右。int4量化AWQ在摘要任务上质量掉得不多，对话稍微有点呆，长文本超过4k后偶有重复，建议GPTQ对比下。你API服务如果并发不高，vLLM配gpu-memory-utilization=0.9基本够用。

512字符一刀切对中文长文档挺伤的，语义容易被拦腰截断，bge对这种断头句的向量质量会掉得厉害。你可以先别急着换模型，拿几段没召回出来的原文直接算query相似度，看是分块问题还是embedding本身不行。企业文档里案例类内容建议按标题层级或问答对切，再给每块补一句上下文摘要塞进索引，比单纯调overlap管用。重排也值得加，bge-reranker对top20重排基本能把该中的捞回来。

我两边都用过，说实话转TF最坑的不是Eager，是Keras那套封装逻辑，你想灵活改点东西就得往下挖到tf.function和GradientTape，跟PyTorch的train loop思路确实差挺多。但工作里真没必要死磕一个，看团队和部署需求选就行，TF在serving和移动端还是稳的。至于Pythonic，主要是PyTorch调试直观，报错能定位到具体行，TF2虽然好多了但偶尔还是给你甩个

试试Outlines或LMQL，直接约束模型输出JSON格式，比手动解析稳多了。

跑测试只是底线，我一般会拿它生成的代码去搜一下，看是不是常见库的惯用法，没见过的写法先查清楚再合。静态分析工具像SonarQube或IDE自带检查能抓一部分问题，但团队规范还是得靠code review，我建议把Copilot的改动单独提个PR，让同事重点看逻辑。import乱这个，可以在设置里把optimize imports改成保存时自动整理，能省不少心。另外如果心里没底，就多写几个边界cas

摘要压缩历史是真管用，不过得按轮次分层存，别一股脑全压成一坨。 记忆子Agent我也试过，成本有点高，还是先试试混合策略吧。

说实话这个量级直接上FAISS完全没问题，bge-m3配个IVF索引几万条都是秒查。Chroma内存占用高是它内部实现的问题，我之前两万条文档也卡得不行，换FAISS后内存直接少了一半。 不过你要是嫌FAISS要自己写持久化逻辑，sqlite-vec确实是个折中方案，索引文件跟着库走，备份迁移都省心。个人项目别纠结扩展性，真到百万级数据你大概率会换pgvector或者es，现在怎么顺手怎么来。

说实话你这配置第一眼看上去没啥大问题，但2万条客服对话对7B来说已经不算少了，epoch3配合2e-4的学习率在LoRA里其实偏激进，尤其如果数据本身有重复套路，模型很容易被带偏。我之前调过类似的场景，rank8对客服这种任务可能不够，试着把rank提到16或者32，同时学习率降到1e-4以下，收敛会稳很多。关于重复和跑题，我怀疑是数据里高频模板句太多了，模型把“复制粘贴”当成了最优解，你可以试试

说实话我刚学爬虫时也卡这了，后来发现反爬的核心不是User-Agent，而是请求头里Accept-Language、Connection这些细节，以及cookie的完整性。你可以让AI生成selenium或playwright的代码，模拟真实浏览器加载，豆瓣对这种反而宽容些。代理池对新手确实复杂，先把session和headers伪装搞明白，再考虑上代理也不迟。另外建议爬慢点，别几秒内狂发请求，我

这感觉太真实了，我用了半年Copilot也有类似的体验。不过我觉得这不完全是坏事，更像是大脑把“写代码”的优先级让给了“读代码和调试”，毕竟AI补全再快，逻辑还是得自己把关。你说的排序算法被纠正成内置函数，我反而觉得是个提醒——我们容易把“手写能力”和“编程能力”划等号，但实际工作中，能判断该用哪个工具、能看懂AI为什么这么写，可能更关键。至于保持手感，我自己的办法是每周抽一小时去刷两道LeetC

我之前也踩过这个坑，7B模型LoRA微调后重复句子，大概率不是数据问题。你试试把学习率降到2e-5以下，epoch减到1-2个，LoRA的alpha调成rank的两倍（比如32），重复现象会明显缓解。 另外，可以检查一下推理时的repetition_penalty，设到1.2-1.3比降温度更直接有效。我之前用类似配置，改完这几个参数后重复基本消失，而且领域能力没掉多少。 如果还不行，看看是不

我们团队两个都深度用过，最后生产环境留了Qdrant。Milvus功能确实全，但坑大多藏在分布式部署里，etcd和pulsar那套链路一旦节点多了，问题排查起来真能让人头秃，而且内存索引对资源的要求比想象中高不少，小团队扛不住。Qdrant上手就顺滑很多，rust写的单机性能很能打，不过它的过滤条件写起来有点绕，特别是嵌套payload的查询，文档又少，遇到复杂场景只能靠猜。还有个细节，Milvu