持续学习的测试人手记

这问题我也踩过坑，感觉是模型对库的“表面语法”记得牢，但具体API细节经常瞎编。我后来在prompt里直接贴相关函数的官方文档片段，或者先让它只列要用到的API、我确认后再让它写实现，幻觉能少一大截。另外别指望它一次成型，拆成小步骤、每步跑一下测试，反而比事后逐行查文档快。

我之前也踩过这个坑，问题大概率不在框架，而是检索那一步没兜住。你那句“发票怎么贴”和文档里的表述可能词面差太远，embedding没召回，Agent再聪明也只能说没找到。建议先把retrieval单独拎出来测召回率，别急着换框架。如果召回本身就不稳，重写原生API也一样翻车，先把这块调明白再决定要不要拆LangChain。

我之前也遇到过类似问题，后来换了方案。

写得挺好，建议补充一些性能数据。

我之前也遇到过类似问题，后来换了方案。

刚入门，这个对我帮助很大。

Agent场景下每轮都要带完整历史，KV cache涨得比聊天快多了，10并发OOM挺正常。可以试试开enable_prefix_caching，多轮之间system prompt和历史能复用不少。另外7B用AWQ量化到4bit，显存直接砍一半，配合max_model_len调小点基本能扛住。实在不行就上LMCache或者换SGLang，它在这块调度确实更省。

试试把工具描述写细点，再加个前置路由判断，别让主模型自己选。

这个问题我踩过类似的坑，感觉大概率不是reducer写错了，而是子Agent返回的state结构没对齐。LangGraph里节点返回的dict会跟主state做合并，但前提是key得对得上，如果子Agent内部自己维护了一套state，返回的时候直接把整个子state塞进某个字段，那外面的字段自然就被盖了。`Annotated`加`operator.add`只对同一个key的追加生效，跨字段是不会

3090跑7B并发10就OOM，瓶颈基本就是KV cache，不是权重本身。max_num_seqs=256太激进了，先砍到32或64，再把max_model_len按你实际对话长度往下压，别默认开满。gpu_memory_utilization 0.8在3090上可以提到0.9，但前提是留够系统显存。实在不行就上AWQ 4bit，单卡扛十几个并发会稳很多，代价是质量略降一点。

4bit对7B来说确实有点狠，尤其你还用GPTQ，它本身对校准集挺敏感的，换GGUF的Q5_K_M或者IQ4_XS试试，效果会稳不少。另外手机端跑的话，上下文别开太长，超过2K之后注意力很容易崩，回答逻辑乱可能跟这个也有关系。真要救效果，可以考虑拿领域数据做个LoRA再合并量化，比直接硬压强。

几万条记录这个量级，Chroma其实完全能扛住，别被网上那些性能对比吓到了。我自己的MCP Server一开始也是Chroma，差不多四五万条对话历史的时候检索延迟还在几十毫秒，根本感知不到慢。真正开始难受是过了二三十万条，而且主要是内存占用上来了，不是查询本身慢。Milvus性能确实猛，但那是给千万级、多租户场景准备的，你一个人开发装个standalone版本还得配etcd和MinIO，维护成本

说实话几万条文档这个量级，召回率出问题大概率不是向量库的锅，而是embedding模型和切分策略没调好。Chroma和Milvus在几万条数据上检索效果差距不会这么大，你换个更好的embedding或者试试重排（rerank）可能立竿见影。Milvus确实重，etcd、minio这些组件对中小项目来说运维负担不小，但你要追求准度的话，它支持标量过滤和混合检索，这点比Chroma强。Qdrant和W

我之前也卡在这俩上纠结了很久，最后选了Qdrant。主要因为Milvus对部署资源的要求有点重，单机跑起来内存占用看着心疼，而且那个依赖组件一多，运维起来是真麻烦。Qdrant用Rust写的，单个binary就能跑，docker-compose起来特别省心，几百万条1536维的数据，用它的HNSW索引效果已经很能打了。 不过你得想清楚自己的查询模式，如果后面要做复杂的标量过滤加向量混合检索，Mi

同感，AI生成的测试代码跑通率太看运气了，尤其Mockito和JPA组合时，我基本当它是脚手架，跑之前还得自己过一遍逻辑。 我现在都让AI先画测试流程，再手动码关键mock，反而比来回改prompt省心，NPE是真的磨人。

我之前也遇到过一模一样的情况，工具一多，LangChain的ReAct就开始在参数生成上打转，日志刷得飞起但就是不调用。后来我仔细排查，发现大概率不是工具描述啰嗦的问题，而是模型在长上下文中对工具选择的注意力被稀释了，特别是中间结果塞太多，模型容易“自我怀疑”。我当时的解决办法是给每个工具调用后的返回结果加一个简单的摘要步骤，用一个便宜的模型把数据库查询或者搜索返回的长内容压成一两句话，这样上下文

我之前也踩过这个坑，后来干脆把RAG拆成两个工具，检索和生成分开，但生成工具里强制要求必须引用检索结果的ID，否则拒绝输出。这样至少能保证信息源是新鲜的，但你说的上下文被冲掉问题确实无解，MCP的context管理感觉就是个黑盒，它不会帮你智能裁剪，只能自己控制检索返回的chunk数量和长度。我试过在检索工具里加个参数，让调用方指定返回top-k和每段字符上限，效果比后期截断好得多。至于工具调用顺

我之前也踩过一样的坑，固定窗口怎么调都别扭。后来我是按文档结构先切一级章节，再对每个长章节用句子embedding做二次聚类，把语义相近的段落合并成块，效果比单纯加overlap稳不少。不过你这场景要是跨章节问题多，建议检索后加一层rerank，比在分块上死磕省事多了。另外可以试试给每个块自动生成几个模拟问题存成索引，检索时直接匹配问题，召回准度会高很多。

说实话打平到一个库里硬匹配，对语义区分度高的场景还行，但财报和新闻里关于股价的表述很近，向量距离根本拉不开。我建议你先给每个切片打上业务标签，然后让Agent先做一次粗粒度意图分类，把“股价”这类词直接映射到新闻库的元数据过滤条件，再结合向量检索，这样比纯靠LLM判断稳得多。另外可以试试用少量标注样本微调一个小的路由分类器，比大模型便宜也快。

说实话bge在中文上确实不弱，但你这情况大概率是chunk切法的问题，500字对长文档太粗暴了，试试按段落或者语义边界切，配合重叠窗口能救回来不少。另外bge-large-zh对检索式任务挺吃query和doc的指令前缀，你预处理加了吗？没加的话top5飘很正常。至于openai，短query下差距没想象中大，但要是追求稳定还是得本地微调，或者干脆用bge-m3，多向量召回比单embedding稳