终身学习写作成长记

几百万条单机pgvector就够跑，真要上K8s再换Milvus也不迟，Qdrant扩展性其实没你想的那么弱。

这个问题我踩过类似的坑，说下我的理解。LangChain里Agent的工具调用顺序其实很大程度上取决于LLM自己的推理能力，ReAct那一套本质上就是让模型在thought里自己规划步骤，但它并没有强约束机制保证一定按你想的顺序来。你调temperature基本没用，因为这不是随机性的问题，而是模型对任务分解的理解问题。我后来发现几个比较有效的做法：一是把工具描述写得更明确，特别是写明“这个工具必

我本地跑Qwen2.5-7B做结构化抽取时也遇到过类似情况，温度0.3左右配top_p 0.8会稳不少，repetition_penalty设1.05到1.1之间能压住重复句子。不过要硬保JSON字段完整，其实最好直接上约束解码，比如outlines或者llama.cpp的grammar，比调参数省心。你试过把生成格式写进system prompt再配合few-shot吗？有时候模型不是随机性太高

我之前也踩过这个坑，最后发现是autograd的图没断干净。你虽然关了梯度，但Agent里如果有些tensor参与了requires_grad=True的运算，哪怕只是记录，计算图也会一直挂着不放。建议在每个step结束时手动把中间变量detach一下，或者用with torch.no_grad()把整个推理包起来。另外检查下有没有全局list或者dict在偷偷存tensor引用，那种最容易被忽略

显存慢慢涨多半是碎片化，试试torch.cuda.memory_summary看下分配情况，另外amp有时反而会多占显存。

你append的是啥？如果是把每批的输出张量直接存列表里，那显存肯定一直涨啊，把结果转成cpu的numpy或者python标量再存。另外DataLoader的num_workers多的话，worker里也可能留着cuda上下文，试试设成0排查一下。监控的话可以看看torch.cuda.memory_summary()，或者用py3的gc加weakref自己查引用，比啥工具都直接。

这问题太真实了，我上个月也刚被吐槽过一轮。后来发现Cursor的代码风格其实跟你项目里已有的文件关系特别大，它会偷偷“学习”你最近打开过的那些组件写法。我现在的做法是每次开新组件前，先手动把同类组件的头部import、类型定义和几个典型函数写个骨架，再让它往里填逻辑，风格就稳很多。另外useMemo和useCallback这个事，你可以在项目根目录放一个.cursorrules文件，直接写清楚“不

几百条就开始退化，感觉问题可能不在检索本身，而是你每轮把top-5全塞进prompt，相似对话越积越多，模型反而被噪声带偏了。我后来加了时间衰减权重，再对高分片段做一次去重合并，效果明显好不少。另外你换过embedding模型但没提有没有做metadata过滤，按session或话题先粗筛再检索，往往比单纯调top-k更管用。

我也遇到过这个问题，尤其是多轮对话里代词一多，检索基本就飘了。后来我的做法是把历史压缩成一个“检索用的query”，只保留实体和约束条件，比如“报销流程”+“电子发票”，而不是把整段对话塞进去。这样检索目标会清楚很多，也不会把无关轮次带进来。另外我加了一层轻量rerank，先召回大一点，再用cross-encoder或者LLM打分筛掉跟当前约束不匹配的chunk。还有个挺关键的点是，检索结果里最好

说实话你这问题我太有共鸣了，之前做内部报表工具时也被SQL生成折磨得够呛。我的体感是Prompt工程在代码生成里不是没用，但它的天花板比想象中低，更像是个“保底手段”而不是“魔法开关”。你提到的schema塞上下文这事儿，我后来发现关键不在于塞多少，而在于怎么结构化——比如用CREATE TABLE语句的格式把字段类型、注释、外键关系写清楚，比用自然语言描述表结构要稳得多。至于语法错误和捏造列名，

说实话我觉得你这数据量其实挺尴尬的，chroma出问题大概率不是引擎本身，而是你检索链路里少了rerank这个环节。几十万条向量对任何数据库来说都不算大，但top-k语义漂移这事，换milvus也一样会发生，我建议你先用bge-reranker过一遍，可能比换库见效快。pgvector我也用过一阵，召回效果其实还行，就是索引构建和查询并发一上来容易让人着急，单人开发如果不想折腾运维，还真不如先拿e

阈值确实该跟着embedding模型走，OpenAI和bge的分布差太远，换模型就得重新标定，别指望一套参数通吃。

短期记忆做摘要滚动覆盖，长期记忆按任务存结构化槽位，别一股脑全塞prompt。

说实话你这个问题我也踩过很久，后来发现根子不在prompt措辞上，而是模型对“健壮”的理解跟咱们不一样。它默认你给的任务是“能跑通就行”，异常处理属于边缘场景，除非你明确把“可能出错的地方”列出来，否则它真就给你裸奔代码。我试过在prompt里加一句“所有IO操作必须try，所有网络请求必须设timeout，否则重新生成”，效果比长篇大论描述“要健壮”好得多，但任务一复杂它还是会漏。 few-s

我之前也栽在过这上面，bge-large-zh对长段落确实容易“分心”，500字带重叠可能把多个语义搅在一起。你可以先试试把chunk缩到200-300，或者按语义段落切，看召回有没有改善。如果还不行，再考虑换bge-m3或者干脆上混合检索，关键词+向量一起跑。至于rerank，别一开始就指望它，那是在召回结果本身不太差的情况下才见效的，不然纯属给垃圾排序。我自己的排查顺序是先调切分，再验embe

说实话几万条数据真不是Milvus和Chroma的差距能体现出来的，这规模换哪个库检索速度都够用。我觉得问题八成出在embedding模型和你的query表达上，比如问“治疗流程”和文档里写的“治疗步骤”可能语义空间就没对齐，换个领域微调过的模型试试。另外也可以看下Chroma默认用的距离算法，有时候换IP或者余弦相似度差别还挺明显的。我之前也遇到过类似情况，最后发现是切片时把表格拆散了，导致语义

我之前搞MCP的时候也卡在这过，后来发现是Cursor只认带name和version的初始化响应，你那个server.py里是不是没写`{"jsonrpc": "2.0", "result": {...}, "id": 1}`这种握手逻辑？建议先用`mcp-inspector`单独调试一下，看协议层返回的tools是不是空的，别直接在Cursor里试。另外确认下你用的Cursor版本，老版本对MC

这现象太典型了，LoRA把通用知识挤掉了，建议混合通用语料一起训，或者降低epoch到1试试。 我之前也这样，客服数据里插10%通用数据就稳住了，rank8其实够用。

这情况八成是数据格式问题，alpaca模板里prompt和response的分隔符没对齐，LoRA学串了。 建议先拿一条原始数据单独跑下生成，看看是不是模板拼接时把特殊token搞丢了。

top-k真不能拍脑袋定死，我这边是拿召回率结合人工评测去调的，比如抽几十条query看关键实体有没有进前十，比光看相似度分数靠谱。你这种情况k=8混入噪音，大概率是chunk切得太大或者embedding区分度不够，试试把检索结果按来源文档做一下多样性限制，别让同一个文档霸屏。另外重排序不是后话，哪怕用个轻量的bge-reranker也能把top20压到top5，检索质量直接上一个台阶，建议先跑