一线产品方法论

八成是Agent历史消息没截断，vLLM的KV cache把显存吃满了，建议把tool结果做摘要或定期裁剪。

说实话我觉得你这问题不在硬件，50万向量768维真不算大，8核16G的机器单机跑Milvus完全够用。我这边之前测过类似量级，IVF_FLAT加nlist调成4096或者8192，QPS上到100都没问题，延迟基本稳定在几十毫秒。你nlist=1024太粗了，召回率虽然没掉但查询要扫的桶太多，性能当然上不去。建议先试试HNSW，M值设16到32，efConstruction设200，查询时efSe

这问题太典型了，八成是tool description写得太笼统，模型不知道啥时候该停。 把每个工具的输入输出格式写死，再在prompt里加一句“必须完成所有步骤再输出”。

parent document retriever值得试，但别把父子块差距拉太大，比如父块1000-1500，子块300-500就差不多。另外你这个问题其实重排比二次摘要更直接，先让reranker把最相关的几个片段排前面，再丢给LLM，逻辑会顺很多。还有个小技巧，检索完可以把多个片段按原文顺序拼一起，中间加个分隔符，比单独喂三个碎片强。

reranker真得加，另外试试父子分块，小chunk召回大chunk精读，能救回来不少。

千万级数据量但不想上分布式的话，Qdrant单机确实更省心，内存和CPU占用比Milvus低不少。不过Milvus的标量过滤和稀疏向量支持确实更成熟，如果后续要玩混合检索，它的原生方案比Qdrant自己拼Elasticsearch省事。我们之前试过在Qdrant里做BM25+向量融合，得自己写逻辑，有点折腾。建议先按你们Agent场景的查询模式压测下，特别是并发和延迟，别光看文档。 另外提一句，

我之前也纠结过这题，最后选了Milvus，主要冲着开源和可控去的。运维没想象中吓人，不用K8s的话直接docker-compose也能跑起来，几百万条数据量其实轻量部署就够了。中文场景主要注意分词和embedding模型的选择，Milvus本身没坑。Pinecone我试用过，延迟确实稳，但数据量大了那个账单看着肉疼，尤其长期跑的话。建议你先拿真实数据跑个benchmark，召回率这东西跟向量索引参

1.2到0.9基本就没怎么动，这更像是数据集分布问题而不是学习率的问题。GitHub爬的Python片段，文件长度、注释密度、import风格差异太大了，模型拟合的是“平均风格”，而不是你真正想要的代码补全模式，loss卡在0.9~1.0很合理。 我之前用类似方法微调代码模型，发现要把数据清洗一下，比如过滤掉重复片段、按token长度分桶，甚至把docstring和代码分开处理，loss能再往

光靠system prompt确实不太稳，LLM总会倾向于“给个说法”而不是承认没答案。我之前试过在检索结果里加一个“相关性评分”的硬门槛，低于阈值就强制让prompt走“无法回答”分支，比单靠模型自觉靠谱多了。另外也可以把检索到的文本片段直接在prompt里标注成“参考材料”，并明确告诉它只能引用这些内容，不能自行补充知识，这样幻觉会少一些。不过阈值得慢慢调，不然容易把有效回答也误杀了。

说实话6.7B和7B这个量级跟Copilot用的Codex模型差距就在上下文建模上，变量名丢失和跨文件瞎猜太正常了。我试过用deepseek-coder-instruct配合自定义system prompt，把当前文件的关键定义摘出来塞进去，效果能好一丢丢但别指望质变。另外你可以试试把温度调低到0.1以下，至少能少点重复定义。真要接近Copilot，得上14B以上的模型或者用reproducer这

试试vLLM吧，开个--max-num-seqs 1，显存能省不少，我4bit的7B在16G上稳得很。

说实话PyPDF2那个坑我也踩过，表格提取出来根本没法看，后来干脆放弃纯文本路线。我现在的方案是PDFPlumber加pdfplumber的table extractor，把表格区域单独抽出来转成二维数组，再按行列顺序拼成带分隔符的文本块，检索效果比markdown稳定很多，跨页问题靠检测表格起始和终止位置手动合并就能解决，代码量不大但挺有效。不过你要是表格里还有合并单元格或者斜线表头，这招也白搭

说实话你这问题问到我心坎上了，我之前也是死磕768，后来发现瓶颈其实在分块和检索策略上，维度降到512再配合重排，效果反而比硬上768强。几千篇文档用bge-small完全够，别急着换模型，先把chunk_size和top_k调了试试。

这个现象我见过，LoRA微调确实容易让模型过度依赖对话上下文，导致检索输入被当成无关噪声。你可以先做个对照实验，把检索到的正确片段直接硬拼进prompt里，不经过微调模型，看base模型能不能答对，这样能定位是检索链路问题还是模型能力退化。另外建议在微调样本里混入20%左右带检索上下文的QA对，让模型重新学会“阅读后回答”这个动作，比单独调温度管用。rerank那个思路也可以试，但前提是你的微调模

角色设定真不是心理安慰，尤其代码生成时，明确“你是Python资深开发”能让模型自动带上类型标注和异常处理的习惯，但别指望它全对。上下文给到能复现问题的最小单元就行，我一般只贴相关函数签名和两三个边界条件，示例放一个正面一个反面就够了，多了反而干扰风格。至于模板，我常用三段式：任务+约束+验收标准，比如“生成一个函数，输入list[int]返回int，遇到空列表抛ValueError，输出带类型注

说实话你这个现象我太熟了，之前搞内部知识库的时候也这样，问题大概率不在top_k和阈值上，而是分块方式跟查询意图完全没对齐。你按固定200字符硬切，很容易把“创建订单”和“库存回滚”的逻辑拆到两个块里，但用户问的时候是把它当成一个完整业务动作来问的，召回自然就东拉西扯。我建议你试试按文档里的语义边界来分块，比如按函数定义、按代码块、或者按API的“功能段落”去切，哪怕每块长度不齐都行，这样块内信息

我最近也踩过类似的坑，中间方案可以试试用72B做规划和工具选择，但把具体参数填充交给一个小模型或者规则校验来兜底。或者干脆用Qwen2.5-32B量化版，速度和准确率平衡得比7B好太多。另外你检查下LangGraph里有没有加few-shot示例，有时候模型跑偏是因为提示词里没给够工具调用的范例。

同款配置踩过坑，reduce-overhead在小batch下反而有额外开销，编译启动那几分钟基本白等。后来我试了mode="max-autotune"配合static_shape=True，LoRA吞吐大概能提15%左右，但显存确实会多吃几个G，估计是CUDA graph缓存占的。你这情况大概率是deepspeed的stage2和torch.compile的inductor有兼容问题，建议先关掉

我之前也踩过这个坑，后来发现按文档类型分开切确实会好一些，比如合同类按条款边界切，技术手册按标题层级切，纯文本再按固定长度切。overlap我一般设chunk的10%-20%，太大容易检索到一堆重复片段，反而干扰回答。另外你可以试试先跑一批有标准答案的测试问题，用RAGAS或者LlamaIndex的评估模块量化看下检索命中率，比手动试参数靠谱得多。不过说实话，chunk size也跟模型上下文窗口

说实话你这个情况太真实了，我前阵子做客服工单分类也差点被prompt逼疯。后来发现一个关键点：别把prompt当代码写，要当产品需求文档写，明确边界比堆砌技巧重要。比如你提取情绪，别只说“分析情绪”，得给出具体维度（正面/负面/中性）和冲突情况下的优先级规则，这样方差会小很多。另外温度调低到0.1以下，然后固定随机种子（如果API支持），至少能保证同输入同输出。至于微调，我试过用几百条标注数据微调