算法日志

说实话你纠结的这俩点我太懂了，去年我也卡在同样位置。但你现在做Agent方向的话，我建议还是把PyTorch学透，因为现在LangChain、LlamaIndex这些生态基本全挂在PyTorch上，连HuggingFace的源码都是torch风格，你拿TF去读这些代码会非常痛苦。至于部署那环，ONNX现在对动态图的兼容已经好很多了，而且大模型时代真正上线用的都是vLLM或者TensorRT-LLM

Milvus重运维，小团队慎入，Qdrant上手快但大规模写入性能有待验证。 我们之前用Milvus集群频繁掉节点，后来换Qdrant单机倒是稳，看你们数据量了。

可以试试在prompt里加“若原文无此信息，直接说不知道”，比单纯要求引用管用得多。分段塞进去效果会好点，但别超过模型上下文窗口的70%。

我最近也在搞这个，最大的感受就是不能太信任模型自己输出的参数，尤其是数值类型，经常给你来个字符串或者漏字段。我现在的做法是强制上JSON Schema校验，不合法就自动重试一次，还不行就降级到让模型重新描述意图。另外超时和重试机制一定要设计好，不然一个工具卡住整个Agent就废了。你们有没有遇到那种工具返回结果格式不统一的情况？我这边处理起来特别头疼。

说实话你这个问题我踩过一样的坑，固定512切块对合同这种条款密集的文本太粗暴了，经常把一条完整条款从中间砍断。建议先试试按段落或者语义边界切，再配合重叠窗口，大概率比换embedding更立竿见影。BGE中文合同场景其实够用，但你要是能抽实体做检索前过滤，效果会好不少，不过也别指望一步到位，这种问题得多调几轮才能稳。

试试混合检索加粗排吧，BM25加向量召回能救回不少，另外用hit_rate和MRR量化评估靠谱。 先查下query和文档的元数据匹配，按产品名过滤再检索，chunk_size调半天不如这招管用。

这现象我也遇到过，信息过载时模型反而会迷失重点，有点像给太多选项反而更难做决定。我觉得可以把动态参数压缩成摘要或分类标签，只保留对当前任务最关键的那几个字段。另外模板里的示例真的得小心，一旦写得太具体，模型就会当成金科玉律，建议用“可能包括但不仅限于”这类表述来留点弹性。

说实话你这个问题我当初也踩过坑，8卡3090跑70B看着显存够，但vLLM默认会为每个张量并行rank预留一部分KV cache和activation空间，TP=8时每卡22GB其实是正常的，问题出在显存碎片和预留buffer上，不是单纯容量不够。我试下来最稳的方案是TP=4 + PP=2，这样每卡显存占用能压在16-18GB左右，而且因为3090的NVLink带宽在PP跨机通信上没那么吃紧，推理

分块前先做文档结构解析吧，标题层级拆出来的chunk比纯按字数切强太多了，召回率能提不少。

说实话我跟你体感差不多，但我觉得“边际收益递减”这个判断还是说轻了。我昨晚拿同一道需要多步反证的数学题去跑GPT-5和Claude 4 Sonnet，前者在第三步就开始绕弯子，最后给出一个看似严谨但前提就错的结论，这种幻觉比单纯答案错误更难抓。你提到MoE没有架构级改动，这点我特别认同，因为如果只是把专家路由的粒度调细，理论上推理成本应该明显上升才对，但实测API延迟和4o几乎没差，这本身就说明改

你这情况大概率不是embedding的锅，BGE-M3配faiss够用了。问题可能出在切分策略上，512token对PDF里的长段落来说太碎，语义容易断，建议试试按章节或标题切，或者用父子chunk。另外reranker真得加，尤其top_k调高后，不加的话噪声会很明显，bge-reranker-base跑一下效果立竿见影。还有个细节，PDF里如果表格或页眉页脚没清洗干净，会直接污染向量，你查下预

先解析PDF的结构再切块吧，表格和标题拆开，不然语义全割裂了。

7B对prompt敏感太正常了，参数规模摆在那，跟32B那种稳定度没法比。你试试把任务拆成两步走，先让它生成代码框架，再单独让它补全异常处理和import，比一口气要完整代码稳得多。另外把“确保能直接运行”换成“给出可执行的Python3代码，并包含必要的库导入和try-except块”，具体化要求比笼统强调有用。我最近用Qwen写脚本都这么干，成功率明显上去了。

我最近也在搞类似的Agent，你这个问题我太有同感了。我的做法是保留一个全局的system prompt，把角色、风格、工具定义和通用约束都放进去，然后每个步骤的prompt只写“当前这一步的目标+需要的输入格式+期望输出”，这样至少改一个步骤不会牵扯到其他步骤的基础设定。但你提到的那个“格式重复解释”的问题，我试过在全局prompt里把中间态的数据结构定义好，然后各步骤直接引用字段名，比如规划阶

说实话你遇到的这个情况太典型了，Agent写CRUD和脚本确实快，但一碰状态机或者权限链这种需要全局视角的逻辑，它就会“偷懒”地走最短路径，把中间条件给吞了。我试过的最有效的方式，是别让它直接写代码，而是先强制它用自然语言把整个流程的判定树或者状态转换表列出来，你确认完逻辑再让它翻译成代码，相当于把“思考过程”前置了。另外，对于边界情况，我习惯在prompt里明确给它“反例清单”，比如“如果订单已

说实话你这个问题太典型了，loss降得漂亮但生成崩了基本就是过拟合到法律语料上了，2万条裁判文书风格太单一，模型直接把通用知识给覆盖了。我建议你试试混合10%-20%的通用指令数据，比如Alpaca或者Dolly那类，r降到8甚至4可能也有帮助。eval千万别只看loss，那玩意儿骗人，你拿几个通用数学题和法律问题混着做人工盲测，比什么指标都靠谱。

T4跑7B确实有点勉强，16G显存看着够，但vLLM的显存管理策略可能没吃透。你检查过gpu-memory-utilization参数没？默认值只用到90%，但实际碎片化可能让可用KV cache缩水，吞吐上不去很正常。我之前用A10也遇到过类似情况，后来把max-model-len调低到2048，再把block-size改成16，首token延迟直接降了40%。并发卡死大概率是prefill阶段

说实话维度真不是越高越好，1536维在数据量大时检索延迟和内存开销都很明显，而且ada-002对短文本的语义区分度也没想象中强。我自己的经验是，先看你的文档领域，如果是垂直场景（比如法律、医疗），384维的bge或e5模型往往比通用大模型更精准，还能直接换用HNSW索引。混用不同维度的问题不大，只要保证入库和查询用同一个模型就行，但别用两套模型做相似度对比，会失真。建议你拿一小批标注好的问答对，跑

试试把chunk调到200-300，bge对长文本确实不敏感，查询改写比换模型见效快。 我直接换bge-m3量化版，8G能跑，中文效果比large强一截，分块改300加个重叠。

直接查就够用了，几千篇文档量级根本不需要聚类。ChromaDB这种向量库本身对TopK检索优化得不错，你多加点metadata过滤条件比什么都强。我之前做过一个项目也是类似规模，直接embedding后查，效果挺稳的，召回率基本在90%以上。 聚类那套主要是为了解决超大规模数据下的效率问题，比如百万级以上的向量，或者当你的文档主题特别分散、扰乱了相似度排序时才需要考虑。不过有个点值得关注，就是e