刺猬爱写代码日记

把关键约束放开头和结尾各说一遍，中间塞例子就行，亲测比加粗管用。

这俩其实互相成就，检索不准提示词再牛也白搭，但提示词对了能把烂牌打好。

我最近也在跟这套Agent较劲，感觉问题不在于提示词写得好不好，而是它压根没有“停下来想”的机制。你让它写订单状态机，它其实是在按概率补全代码，而不是真的在脑子里跑一遍状态转移图，所以漏掉某个分支太正常了。我的做法是逼它先输出逻辑再输出代码，比如让它用自然语言把状态流转和异常路径列出来，确认没问题了再让它写实现。还有个笨办法但挺管用，就是让它自己写单元测试，尤其是边界条件的测试，写完跑一遍，很多时

500字符切块对API文档来说可能太碎了，接口的参数说明和返回值经常被切断，检索出来的片段丢上下文，模型自然给不对。我一般会按标题层级或者函数签名来切，尽量保证一个接口的完整描述在一块里。另外bge-large-zh可以试试加个query指令前缀，检索和入库的文本处理方式最好对齐，不然相似度算出来会偏。还有个容易忽略的点是Chroma默认的余弦距离和归一化处理，确认下embedding有没有做no

我遇到过几乎一样的情况，后来发现根因不在库也不在模型，而是chunk切分把“退款到账时间”那段和“积分规则”切到了相邻上下文里，导致embedding混入了噪声。你可以先试试用bge的rerank模型（比如bge-reranker-base）对前20条做精排，通常能直接把那条无关的挤出去。chroma的HNSW参数影响没你想的那么大，调embedding或换库之前，建议先检查下召回文档的原始文本是

试试按标题层级切分再合并，技术手册这种结构比纯字数靠谱多了。

说真的，MCP这块本身还是个挺新的东西，框架选择其实没有标准答案，更多看你团队和部署环境。JAX在MCP示例里多，主要是Google那边推得猛，函数式那套确实跟上下文切换、vmap这类操作天然契合，但调试成本高是真的，jit编译报错经常让人抓瞎。PyTorch这边动态图调试友好，生态成熟，服务端部署有TorchServe、TensorRT这些现成路子，踩坑少很多。我自己的做法是训练和实验阶段用Py

几十个PDF还带扫描件，检索对不上太正常了，扫描件没OCR的话embedding根本抓不到有效语义，表格里的内容切碎了也容易串味。你光调chunk_size和换模型其实是在下游折腾，上游文档质量不解决，换啥embedding都白搭。建议先把扫描件过一遍OCR、表格单独抽出来结构化处理，再考虑召回这块。reranker确实能救一部分，但它只能在你召回的候选里挑，前面捞回来的全是报销和差旅混在一起的，

几千篇文档直接查就行，聚类反而容易丢召回，得不偿失。

我之前也踩过这坑，后来发现光调chunk size不够，得配合结构感知切分。比如按标题层级或者段落边界切，再给每个chunk加上它所属的章节路径，这样检索时能带上父级上下文。现在用的方案是子块检索、父块返回，效果比单纯调大小稳不少。你可以试试llama_index的sentence window或者hierarchical node parser，比自己手撸省事。

你这个情况我之前也踩过，说实话bge-small-zh在中文短query上确实有点拉，尤其你们内部文档要是有很多业务黑话或者缩写，它很容易把“报销”和“出差”这种语义相近但场景不同的东西混在一起。我建议你先别急着换embedding，可以先拿几个bad case手动看看top10的chunk到底是啥，有时候问题不在模型，而是你的文档切分把“报销流程”这个标题和下面的正文切散了，检索时只匹配到零碎词

我们之前也踩过这个坑，Faiss本身确实不太适合做这种动态更新场景，它就是个静态索引库，你硬要搞增量就得自己维护一套id映射和删除标记，时间长了坑特别多。后来我们干脆换成了Milvus，它支持按主键upsert和delete，文档版本更新的时候直接根据doc_id覆盖就行，省心不少。不过要注意切分策略得跟着调整，我们是用parent-child的方式，子块存向量，父块存原文，删的时候按parent

50万条分块说实话不算大，但你描述的全量重跑索引这个痛点确实是faiss的硬伤，它就是个库不是服务，没有增量写入和实时更新的能力。ES的kNN底层走的是Lucene的HNSW，性能其实不差，但它的强项在于filter和BM25能跟向量打分做原生融合，你要做中文检索的话ik分词加BM25这条路很成熟，纯向量库反而还得自己另搭一套全文检索再手动做RRF。频繁更新这个需求我建议优先看pgvector或者

问题不在RAG，是生成层没做意图判断，天气这种得走工具调用再润色，别让模型纯念检索结果。 试试把chunk切小点，再加个“基于检索内容自由发挥”的重写prompt，语气能活不少。

短期记忆用滑动窗口加关键信息抽取，长期就存向量库按任务触发召回，别啥都往里塞。

这题我熟，简历问答这种垂直场景，固定256切分确实容易把一段技能描述或者项目经历拦腰截断，语义就不完整了。建议先试试按markdown标题或者自然段落边界切，简历结构其实挺规整的，这个改动往往比换embedding更直接。 另外你提到混合检索只涨3个点，我怀疑是BM25和向量结果融合权重没调好，或者topK取太少，rerank对这类长文档干扰项多的场景效果其实挺明显的，尤其用bge-rera

试试用循环加注册表替代if-else，把工具调用当成可组合的任务队列，状态用上下文对象串起来就行。 工具本身没必要硬套nn.Module，不如把调度逻辑单独抽出来，用asyncio的队列或者事件驱动管状态，能清爽不少。

试试把工具选择拆成两步，先让模型只选工具再单独填参，我这么改后乱选少了很多。

说实话我觉得你列的几个原因全都踩中了，但最核心的可能是分词器匹配不上LoRA微调的上限。原版LLaMA的tokenizer对中文基本就是按字节拆，你1万条对话里那些固定话术被拆得七零八落，模型很难学到真正的中文语义关联，loss降了只能说明它在机械记忆模板，一旦遇到没见过的句式就崩。 学习率5e-4对LoRA来说确实偏高，尤其你数据量才1万，很容易把预训练权重冲得太狠，导致灾难性遗忘，表现出来就

我之前也踩过类似的坑，后来发现核心问题往往是工具描述写得太模糊，模型根本分不清参数边界。你可以试试在tool的description里把每个字段的格式、示例甚至“千万别填错”这种话都写进去，比调temperature管用多了。另外如果连续调用会崩，大概率是中间某次返回的格式不合法，建议在工具函数里加个try-catch兜底，把异常转成模型能理解的文本再传回去。至于框架，我后来换了LangGraph