用LangChain搭的Agent总在简单任务上翻车，是框架问题还是我用法不对？

检索这块的问题大概率出在query改写上，建议先看看召回结果再赖框架。我试过直接调API自己写，反而更清楚卡在哪。

问题多半出在检索链路而非框架，试试把召回结果直接打印出来看看，比调参快多了。

这种问题我也踩过，大概率不是LangChain的锅，而是检索环节没调好。“报销流程”和“发票怎么贴”语义差挺远，光靠向量相似度确实容易漏。你可以试试加个查询改写或者混合检索（关键词+向量），召回率能提升不少。至于要不要换原生API，如果流程不复杂，自己写反而更透明，至少每一步你都能看到日志。

检索召回不行，先别怪框架，换个问法就挂多半是embedding没匹配上，建议先查召回结果再调别的。

换个问法就翻车，八成是检索召回的锅，跟LangChain关系不大，先看下embedding匹配得分吧。

这个问题我踩过类似的坑。检索不到大概率不是LangChain的锅，而是查询和文档的语义gap太大，建议先加一层query改写或者用multi-query retriever试试。LangChain确实抽象得让人抓狂，但它的retriever生态还是挺省事的，重写之前可以先手动跑一下检索那一步，看embedding到底返回了啥。定位清楚是检索挂了还是生成环节的问题，再决定要不要换原生API，不然重写了可能还是同样毛病。

检索召回不稳的话，先别急着换框架，把query改写和相似度阈值调一调可能就通了。

换问法就挂多半是检索召回的问题，跟LangChain关系不大，先查查embedding那步。

这个坑我踩过，问题大概率不在LangChain本身，而是检索那一步就没召回对的文档。你可以先把检索结果单独打出来看看，“发票怎么贴”这种口语化问法和文档里的书面表述embedding距离可能挺远，加个query改写或者用混合检索会好很多。LangChain抽象归抽象，但它把retriever和prompt解耦了，你完全可以把检索部分换成自己的逻辑，没必要整个推翻重写。先定位到底是召回问题还是生成问题，别急着换框架。

先别急着换框架，问题大概率出在检索这步，“发票怎么贴”和文档用词没对齐，加个查询改写试试。

我也踩过这坑，问题多半出在检索那步，换个问法embedding就匹配不上了。建议先拿原生API跑通检索再加框架。

这个问题的根源大概率不在LangChain本身，而是检索环节出了岔子。“报销流程是什么”和“发票怎么贴”语义差异其实挺大的，如果你的embedding模型对口语化表达不够敏感，召回结果可能完全不一样。我之前也踩过类似的坑，后来发现把检索和生成拆开单独调试特别有用——先看检索出来的top_k文档到底是不是相关的，如果这一步就不对，后面prompt怎么写都白搭。LangChain确实抽象层多，但它帮你省了很多胶水代码，问题是你得知道每一层在干什么。建议你先别急着换原生API重写，花半天时间把retriever单独拎出来跑几条query，看看召回率到底怎么样。如果确实是embedding的问题，换个多语言模型或者加个query改写步骤可能就解决了。重写当然更可控，但成本也不低，先定位清楚瓶颈再决定比较划算。