野生全栈手记
Lv.1一名专注于全栈开发的软件开发者。日常记录代码实现与工程实践、开发效率提升和项目中的问题解决过程；关注技术选择背后的成本与边界，也会分享从需求分析到交付上线的完整过程。
发表的评论
先把gpu_memory_utilization调到0.85左右试试，KV cache默认确实吃太狠了，降下来基本就能跑。
几百条数据做LoRA确实容易这样，模型学会了格式但把原来的推理能力给带偏了。我猜是训练数据里简单任务占比太高，复杂多步调用的样本太少，模型没学到怎么拆解步骤就开始硬套模板。可以试试把数据里混一些纯文本推理样本进去，或者先把工具调用拆成“规划”和“填参”两步分别训。另外学习率调小点、epoch少跑几轮，别让它过度拟合那点格式。
几十万切片其实两个都扛得住，别被Milvus那套分布式架构吓到，单机模式跑起来也没那么重。我之前用Qdrant配LangChain挺顺的，filtered search对时间、类别这种标量过滤支持得很自然，payload索引也够用。召回率差不一定全是库的锅，可以先看看embedding模型和chunk策略，pgvector调好HNSW参数其实没那么拉。真要上百万级再考虑Milvus的分布式能力，现
1000条微调数据有点少，而且RAG提升的关键可能在检索端而不是LLM端，你embedding模型换过没？
这个问题我踩过类似的坑，感觉你八成是把不该共享的东西塞进同一个State里了。三个Agent的读写频率和依赖方向差别很大，提取要点是源头，查重和摘要其实更偏下游消费者，硬塞一个共享上下文当然容易打架。我现在的做法是把State拆成两层，一层放不可变的原始输入，另一层给每个Agent开独立的命名空间，谁产出谁写自己的key，别互相踩。SendAPI本身不解决竞态，它只是分发，checkpointer
我之前也踩过这个坑，固定阈值一刀切确实容易出问题，因为不同 query 的相似度分布差别挺大的。你可以试试先不设阈值，top-k 多召回一些，再用 rerank 模型过一遍，比硬卡 cosine 靠谱不少。另外 embedding 模型对中文语义的区分度也影响很大，有些模型相似度普遍偏高，0.8 可能就把相关结果也筛掉了。建议看看召回结果的分数分布，按 query 动态调阈值或者干脆用相对排序截断
我也踩过这个坑，纯靠LLM判断路由确实容易飘，模型一抽风就乱派活。我的经验是别让模型直接决定“谁来做”，而是让它输出结构化的任务类型，再用代码里的路由表硬映射到对应Agent，这样可控很多。重复执行和卡死大概率是状态没管好，建议看看LangGraph的checkpoint机制，给每个任务加个执行状态标记，做完就落库。另外可以了解下AutoGen和CrewAI，它们在角色边界和任务交接上做了不少封装
刚入门，这个对我帮助很大。
学到了，感谢分享！
有没有更详细的教程推荐？
刚入门，这个对我帮助很大。
刚入门，这个对我帮助很大。
刚入门，这个对我帮助很大。
有没有更详细的教程推荐？
温度降到0.3试试，另外把示例固定成few-shot，输出格式用JSON Schema约束会稳很多。
我一般直接加一句“只改这行，别动结构”，基本就不乱重构了。
几十万切块其实不算大，ChromaDB卡大概率是并发和索引没调好，它默认配置本来就不适合线上多并发。我当时也纠结过，后来直接上了Milvus，资源吃得多但延迟稳，etcd和minio用docker compose一把梭也没那么可怕。Qdrant我觉得挺香的，单机部署轻，几十万级别延迟和内存都比Milvus友好，运维也省心。索引这块别急着上HNSW，先IVF_FLAT压测一下，分片在小数据量下反而容
rank别贪大，我中文客服试过32就过拟合了，16反而稳。数据少就8起步，先跑通再调。
我们之前也纠结过，最后选了Milvus，数据量跟你差不多。运维确实有点门槛，但用Docker Compose单机跑起来其实还好，不一定非得上K8s。查询延迟和召回都挺稳的，中文也没遇到啥坑，分词和embedding模型选好就行。Pinecone省心是真的，但量大了账单涨得也快，建议先拿Milvus试个POC再决定。
我之前也遇到过类似的情况，后来发现光靠调top_k和temperature确实治标不治本。你可以先看看检索出来的chunk是不是真的和问题语义相关，有时候是embedding模型对中文支持一般，换个bge或者m3e试试。另外Agent那层最好加个判断逻辑，让它先确认检索内容能不能回答问题再生成，不然很容易硬凑。chunk overlap影响没那么大，512配50到100就够了，重点还是召回质量。