深夜前端笔记

换Qwen2.5的function calling版吧，我试过普通版确实容易乱调参数，专用版稳很多。

改写query这事我也踩过坑，直接让LLM自由发挥确实容易跑偏。后来我改成让它先抽取关键实体和时间范围，再拼成一句短查询，比如“去年 营收 公司名”，反而稳很多。另外别只依赖单次改写，可以多生成几个变体分别检索再合并结果，召回会明显好一些。你那个“去年”最好也转成具体年份，不然embedding对时间词其实挺不敏感的。

我一般按语义切，段落太大就拆成子块，再叠个reranker基本能压住跑偏。

单机跑1亿条768维，这量级已经摸到Milvus单节点的天花板了，数据增长又这么快，召回慢真不全是索引的锅。我之前在类似场景踩过坑，nlist和nprobe调参只对静态数据有效，你这每天涨几百万，索引重建频率跟不上，参数再优化也白搭。建议先确认下是不是segment文件太多导致查询时扫描了过多小文件，Milvus的compaction没跑及时的话，I/O会拖垮延迟。至于HNSW和IVF_FLAT，

这问题太真实了，我刚开始用Cursor的时候也被它这毛病烦得不行。后来发现它本质上是想“保险”，宁可多给也不漏，尤其Claude系模型特别喜欢把类型注解当标配。你试试在项目根目录放个.clinerules文件，直接写“禁止添加未使用的import，严格按现有代码风格”这类硬性规则，比在对话里反复强调管用得多。另外可以把agent模式从默认改成“专注编辑”或者每次让它改代码前先问一句“需要哪些依赖”

我跟你情况差不多，现在基本就是拿它当高级补全工具使，代码块超过十行就得自己过一遍。不过有个笨办法挺管用：让它先写单测，再补实现，这样边界情况能暴露得早一点。另外它给的Stream重构方案，我习惯手动换回传统for循环验证一遍事务逻辑，虽然丑但心里踏实。

这题我熟，之前用7B模型挂三个工具也是秒炸。你试试把max_seq_len调小点，或者干脆用vLLM跑，它对KV Cache的复用比transformers强很多，OOM概率能降一半。另外工具调用时系统提示词别塞太多，那玩意也吃显存，先把web搜索的并发砍到1看看。

说实话你这个现象我遇到过好多次，尤其是代码生成任务，few-shot的坑比想象中深。模型其实不是在看逻辑，它更像是在做模式匹配，你给的例子一旦稍微具体点，比如变量名、函数名有某种风格，它就会下意识模仿那种具体形态，反而把通用的抽象能力给压制了。我自己试下来，代码类任务里few-shot要么给特别抽象、几乎不涉及具体业务逻辑的伪代码，要么干脆给一个正例加一个反例，比如故意展示一个错误模式再给正确写法

碰到过类似的情况，bge-large在长文本上确实容易把主题词带偏。我觉得可以试试先做粗召回，再单独用cross-encoder对候选段落打个分，比MMR稳很多，就是费点算力。另外你那个512的chunk对部署流程这种步骤型内容可能太大了，试试按标题或章节边界切，别死磕固定字符数。

遇到过，faiss索引重建其实不是根因，重点看用户query的分布漂移。你每天全量重灌只是刷新了向量库，但embedding模型本身没变，如果用户问法越来越口语化或领域术语变多，相似度检索自然就偏了。 建议先抽一批最近的低质量query，跟历史测试集比对下embedding距离分布，如果明显拉远，就得考虑定期用新数据微调embedding模型，或者加一层query改写，把口语化表达映射到文档里的

子图隔离更省心，全局state的时序问题基本无解，你试试把检索结果快照塞进每个节点的私有字段里。

说实话我觉得你这个问题大概率不是embedding的锅，bge-m3对中文语义理解已经够用了，512字符切块确实偏大，尤其是企业文档里“报销流程”和“差旅标准”这种强相关但不同主题的内容，很容易被切进同一个块里。建议你先试试把chunk降到256甚至128，overlap提到128，先看召回有没有改善。另外你可以把召回来的片段直接打印出来看，是语义上压根不沾边，还是只是细节对不上，前者才需要换模型

我之前也遇到过这问题，你试试把ResNet50的BN层换成GroupNorm，或者冻结前几层只训后面，显存能降不少。另外检查下DataLoader的num_workers和pin_memory，有时候数据加载卡住也会导致显存虚高。用torch.cuda.memory_summary()能看到具体分配，但层级别定位可以开torch.profiler，能看到每个op的显存峰值。还有个小技巧，把输入尺寸

说实话我在生产环境折腾过类似的东西，最后是走了tailscale + Caddy反向代理这条路，比直接暴露HTTP省心太多。你提到的WebSocket其实官方协议层面是支持的，只是文档没细说，MCP的HTTP transport在升级握手后就是WebSocket，所以用ws://或者wss://完全没问题。我现在的方案是服务器上跑一个Caddy，自动配好HTTPS和Basic Auth，然后本地用

同款衣服不同角度召回率卡在60%，确实大概率不是Milvus的锅。ResNet50提特征对商品这种细粒度类别不够敏感，换个CLIP或者专门做reid的模型（比如PLIP）效果会明显不一样。另外你试过对图像做归一化或者数据增强吗？之前我处理相似度检索时发现，训练和推理时的预处理不一致特别影响结果。还有个小建议，L2距离对特征尺度太敏感，试试余弦相似度，有时候召回能涨好几个点。

这问题我太有同感了，cursor对版本的理解基本停留在训练数据里最热门的那个时代。我在项目里试过在pyproject.toml写死版本，也把fastapi的依赖注释写得很清楚，它照样给你生成pydantic v1的model_config写法，最后还得靠mypy和运行报错来兜底。个人感觉不如把关键依赖的版本和语法习惯直接写进rules文件，或者干脆让它生成代码后自己统一过一遍import和类型标注

生产环境最多挂3个，多了确实拖慢，工具冲突直接按业务域拆Agent，别全塞一个里。

大概率是K8s的service负载均衡或者keepalive配置问题，先抓包看看SYN丢在哪一跳。

这问题太典型了，GPT写代码本质是概率采样，温度参数不调低的话结构飘是必然的。你可以试试在prompt里明确要求“只用函数定义，禁止顶层执行代码”，或者干脆把输出格式定义成JSON再解析，比纯文本稳定得多。另外我自己的经验是，把任务拆成“先写骨架再补细节”两步，比让GPT一步到位靠谱。温度调到0.2以下，能明显减少随机性。

说实话你这个情况我太熟了，之前做合同类文档也栽过跟头。固定512字符切块对法律文本来说基本等于随缘切割，条款和定义经常被拦腰截断，建议先试试按段落或者句子边界做重叠切块，比如256字符带64重叠。embedding的话BGE中文场景其实还行，但合同这种专业术语密集的文本，通用模型确实容易抓瞎，有条件的话拿你们合同语料微调一下比换模型见效快。实体识别我觉得倒不是必须的，但你可以先跑一下看检索出来的片