持续研究设计方法手册

可能是梯度没关干净，建议检查一下推理脚本里有没有漏掉的requires_grad=True，或者某些层没被no_grad包住。也有可能是加载模型时没指定map_location，权重被复制到了多张卡或者CPU和GPU之间来回倒腾。另外BERT这种模型可以试试用torchscript或者onnx导出再推理，显存能降不少。我之前遇到过类似情况，最后发现是dataloader里pin_memory没关，

这问题多半不在embedding，混合检索加个rerank试试，关键词匹配对“第三版”这种词很关键。

内部技术手册术语多，通用embedding根本抓不住语义，换领域微调过的模型试试。

我一般按文档结构来切，不硬套固定字数。技术手册按章节切，新闻稿按段落切，效果比统一512稳不少。overlap留个10%到15%就够了，太大反而拖慢检索。动态切片可以看看LangChain的语义分割器，配合小模型判断边界，实测比递归字符切分准。

加个话题切换检测，检测到新意图就清掉工具调用历史，别让旧上下文拖后腿。

先确认下你对比的方式，onnxruntime跑的时候预处理是不是和原版完全一致？很多人栽在归一化或者letterbox的padding值上。Focus层转过去一般会被拆成slice+concat，这个通常没问题，但SiLU在某些老版本opset里确实可能被近似成sigmoid*x，建议把opset拉到13以上再试。排查的话可以逐层dump中间输出跟PyTorch对，看是从哪一层开始数值飘的。INT

我一般只让它补全和写小函数，大重构绝对不敢放手让它干。你这情况大概率是项目上下文超出它有效理解范围了，它就开始瞎猜着改。我自己的习惯是每个功能模块写完就commit一次，然后给关键文件顶部写几句注释说明职责，能少很多乱改。其实Copilot和Cursor不冲突，复杂逻辑手动写，重复代码交给它，别指望它懂你整个架构。

Rust这块确实难搞，我试过让Copilot写带生命周期的trait实现，它基本就是瞎猜，有时候连借用检查器的报错都改不对。后来我改成先自己把函数签名和结构体定义写好，只让它填函数体，命中率能高不少。不过遇到涉及多个引用和泛型约束的地方还是得自己来，感觉这玩意儿对Rust的借用规则理解就是浮于表面。

试试vLLM加AWQ量化，KV cache用FP8，24G跑7B基本够用，效果比GPTQ稳。

这个差距太正常了，ada-002在语义理解上确实比text2vec-base强不少，尤其是中文场景下后者经常抓不住 query 的真实意图。维度不同会有影响，但不是主因，768 维调好了照样能打，关键还是模型本身训练语料和任务匹配度。我之前也遇到过类似情况，换模型后召回质量提升很明显，但全量重 embedding 确实肉疼，可以先抽样对比几组 query 的召回效果再决定。另外你数据里技术文档和客

几万条笔记真没必要上Milvus，Chroma完全够用，我MCP接的就是它，docker一条命令起来，延迟基本感觉不到。那些说不适合生产的，大多是数据上百万或者要高并发才成立，个人知识库这量级纯属多虑。迁移也没啥成本，Chroma的Python SDK和MCP里用的是一套东西，切过去改改连接配置就行。真要说坑，就是持久化目录记得挂volume，不然重启数据没了。

先上reranker试试，长尾query光靠向量确实容易飘。HNSW参数影响的是速度不是精度，别折腾错了方向。

会议纪要这个场景其实挺难的，因为“决策”和“闲聊”的边界本来就模糊，模型很难自己判断。你试过把任务拆成两步吗？先让它逐条标注每句话的类型（决策/待办/闲聊/信息同步），再单独提取，这样比一步到位稳很多。另外时间节点漏掉，可能是prompt里没明确要求保留原文时间表达，加一句“涉及时间的原话必须原样保留”会好一些。

工具描述得单独走一路检索，别跟文档混在一起，不然模型分不清该查库还是该分析。

编码和多线程这种坑，AI确实容易翻车，因为训练数据里这类工程细节的正确答案本身就少，它更擅长写“看起来对”的代码。我一般会让它生成完再追问一句“这段代码在边界情况下会出什么问题”，逼它自己review一遍，能捞出不少隐藏bug。另外GBK这种建议直接让它用chardet或errors=‘replace’兜底，别指望它一次写对所有编码分支。多线程的话，还不如让它写多进程或者asyncio，坑少很多。

存纯用户问题更稳，完整Prompt里混了系统指令和用户ID，检索时噪音太大。

AgentExecutor默认不存工具结果到history，得手动把tool output拼进memory再传回去。

我也遇到过这问题，后来发现Cline默认只读当前打开的文件，根本不知道项目里已经有哪些工具函数。你可以在项目根目录建个.clinerules文件，把常用模块和函数名写进去当上下文，再配合自定义指令让它生成前先搜一下代码库。我现在每次开新任务都会先让它读一遍相关文件，明确说“复用xxx.py里的函数”，不然它就爱自己造轮子。挂MCP读全项目也行，但token烧得飞快，小项目用rules就够了。

这太正常了，向量检索本来就不擅长精确匹配，你问“某个参数在哪个文件配的”这种问题，embedding很容易把语义相近但实际不相关的片段排前面。bge-large-zh已经算不错了，但切512字符对定位具体参数来说太粗了，关键信息可能被稀释掉。建议试试混合检索，BM25召回加向量召回再做rerank，很多场景下比单纯向量强不少。

只存embedding省空间但检索容易飘，原文必须留，不然召回错内容你想调试都没法下手。 别整段历史全塞进去，按会话切片+时间衰减过滤，不然存越多噪点越多，白烧token。