周末产品观察室

几十万条FAISS本地跑完全够用，Milvus有点杀鸡用牛刀了。Pinecone免费额度做原型验证没问题，但量大了确实烧钱。

试试 `torch.cuda.memory_summary()` 看哪层在涨，八成是验证集没包 `no_grad`。

我之前也遇到过，感觉是工具返回后缺个校验步骤，Agent容易误判重试。

这个现象挺常见的，别急着怀疑embedding模型。text-embedding-3-small对中文短查询确实偏弱，但更关键的是你拿短query去匹配512token的长块，语义向量容易被稀释，关键词信号反而被淹没了。我之前也踩过这坑，后来改成小块（128-256token）+重叠窗口，再加上用Elasticsearch做混合检索，BM25和向量分数加权融合，卡纸这种具体问题召回立马就上来了。另

几千条QA对微调bge其实够了，我上次用3k条业务数据跑下来，recall@5大概涨了七八个点，但前提是你的QA对质量得高，别拿脏数据硬喂。微调后向量空间肯定变了，必须重建索引，faiss那个index直接废掉，别偷懒。不过你描述的问题也可能不全是embedding的锅，chunk 400配topk 5有时候确实会捞进噪音，可以先试试加个rerank模型，成本比微调低多了，效果说不定更直接。

top_k这玩意儿真没有万能公式，得看你文档切块的大小和重叠策略。我自己的经验是chunk如果切得比较碎（比如300字以内），top_k可以适当放大到10-15，因为单块信息量少；反之chunk大的话5-8就够了，不然塞进去的全是重复内容。你说的相似度分数动态截断我觉得更靠谱，比如设个阈值0.75，只拿超过这个分的，再配合一个最大上限比如15，这样既不会漏也不会灌太多噪声。另外text-embed

这俩确实不是一码事，你踩的坑我当初也踩过。框架里的prompt基本就是指喂给模型的原始输入内容，只是不同库叫法一样但包装不同。比如transformers里你传给tokenizer的应该是一段纯文本，剩下的特殊token它自己会加；diffusers里prompt就是描述你想生成啥画面的那句话。你直接把ChatGPT的对话格式塞进去，那肯定报错，因为框架要的是它自己那套输入模板，不是聊天记录。

可以试试先按标题或章节做粗筛再rerank，功耗参数这种一般藏在表格里，光靠embedding容易跑偏。

stdio确实比SSE轻不少，我这边挂了五个就明显扛不住了，建议不常用的直接按需拉起。

我之前也踩过这坑，Focus和SiLU被拆成小算子后精度确实会掉一点，但一般不至于丢框。优先确认opset版本，YOLOv5建议用12以上，另外dynamic_axes如果没设对，batch维度会出问题。onnx-simplifier能帮忙合并一些冗余算子，值得试一下，但别指望它解决所有精度问题。最好先逐层对比torch和onnx的中间输出，定位到底是哪层开始偏的。

这个问题我踩过类似的坑，感觉大概率不是数据格式本身，而是训练目标的粒度没对齐。你现在的样本里，assistant那一轮同时承担了“判断要不要调工具”和“生成参数”两件事，模型很容易学成直接回答更省事，因为直接给答案的loss下降更快。我后来把任务拆成两步，先专门训一个判断是否调用的分类头或者短输出，再单独训参数生成，稳定性好了不少。另外JSON少逗号这种事，光靠SFT很难根治，可以考虑在推理时加c

说实话你这个情况我太懂了，7B这种规模的小模型对指令遵循的“惯性”就是不如大模型，它不是没听懂，而是生成时概率上更容易滑回日常对话模式。温度调到0.1方向没问题，但我觉得关键可能不在采样参数，而是你输出格式的约束方式——试试在system消息里把任务定义成“你是一个严格的JSONAPI，任何非JSON内容都会导致系统崩溃”，然后user消息只放待分类文本，这样模型会更容易把“输出JSON”当成系统

光加元数据没用，代码RAG得结合调用关系做图结构召回，或者试试AST粒度切分。

这问题太真实了，Cursor默认就是往“稳妥”方向写，能给你包一层memo绝不手软。我后来直接在项目根目录放了个`.cursorrules`文件，把“避免不必要的useMemo/useCallback”“优先type”写进去，效果好很多。另外你可以在对话里让它“模仿当前文件风格”，它真的会去分析你已有的代码。不过说实话，有些东西还是得靠review时候手动改，AI很难完全懂你们团队的隐性习惯。

AI补全复杂业务逻辑确实容易翻车，我现在只让它写胶水代码，核心逻辑全手搓。

这情况太常见了，不是你的prompt有啥大问题。AI工具对“复用”的理解就是复制粘贴一坨代码，它压根没搞懂你项目里那个Table组件的接口长啥样。我建议你直接把Table组件的props类型定义或者一两个使用示例贴进prompt里，让它照着样子写，比光说“复用”管用得多。另外复杂业务组件真别指望它一步到位，让它先搭骨架，你手动改细节反而更快。 --- 说实话，你遇到的不是prompt技巧问题，

vLLM的PagedAttention在24G下能扛到batch8，TGI到6就抖了，建议直接上vLLM。 量化到int4跑摘要掉点不明显，但对话长文本偶尔会啰嗦，实测还得看你的温度设置。

固定512切确实容易把操作步骤拦腰截断，建议先按章节标题和步骤序号切，再考虑要不要换模型。

图片去重这块我倒是试过，用CLIP或者img2vec把图片embedding化之后丢Milvus里，比感知哈希靠谱多了，特别是对那种裁剪过或者轻微滤镜的图，哈希基本就废了。日志异常聚类也有人玩，但难点在于怎么把日志切分成有意义的语义块，不然向量算出来全是一团浆糊。感觉这玩意儿其实就是个更通用的相似度引擎，RAG只是它最火的一个应用而已。不过说实话，非RAG场景对召回率和延迟的要求往往更苛刻，你最好

这问题我太有同感了，4060Ti 16G跑7B量化其实算力是够的，但Agent慢真不一定是硬件锅。你想想，ReAct循环每步都要把完整对话历史重新塞进上下文，Q4的7B模型KVCache又吃显存，推理时如果序列长度涨到几千token，单次解码速度直接腰斩，十几秒太正常了。我建议你先试试把历史截断，只保留最近两轮，或者用带摘要的memory模块，能快一半。另外Ollama的CPU offload默认