一只企鹅追着需求跑日记

换模型不如加一步关键词召回，bge对实体确实钝，混合检索加个BM25立竿见影。

这情况我也踩过坑，110M的BERT转TRT反而变慢，大概率不是动态shape的锅，而是算子融合没吃透。你试试把onnxruntime的execution_mode设成ORT_SEQUENTIAL，然后开enable_cpu_mem_arena=False，有时候内存池分配策略会影响小batch的延迟。另外你说profiler显示在CUDA上，但有没有留意过是不是有算子被拆成了多个小kernel？

这问题我太有同感了，加“注意”和“重点”基本没用，模型压根不认这种情绪词。我试下来最管用的是把约束条件直接写成“必须/禁止”的硬性规则，比如“必须用requests库”“禁止引入额外依赖”，比什么“核心逻辑”管用十倍。另外顺序确实影响很大，把最关键的那条需求放第一句，后面全当背景信息写，模型会默认前面优先级高。还有个小技巧，把你要排除的情况明确写出来，比如“不要处理文件不存在的情况”，这比说“请关

这现象挺常见的，我试过塞太多代码进去，它反而容易把早期定义的东西给“忘了”，感觉是注意力被稀释了。

24G跑14B AWQ还OOM，大概率不是显存不够，是vLLM默认把KV cache吃太狠了，你可以先试试把gpu-memory-utilization调到0.85，max-model-len砍到4096，这样能省出不少空间。另外检查下是不是装了最新版vLLM，有时候版本bug也会导致显存分配异常。如果调完还是不行，那确实建议换8B，14B在单卡上折腾性价比太低，而且你租3090的钱都够跑好几轮小

重叠降到20以内，reranker留着，速度慢就换小模型。混合检索值得加，尤其长文档场景，纯向量容易漏关键词。

之前我们在类似场景做过对比，Qdrant胜在部署简单，但80万向量其实不算大，Milvus的索引类型和标量过滤配合度更高，延迟能压到个位数毫秒。10亿级的话Qdrant单机肯定吃力，但用集群模式成本会上去，Milvus分布式虽然重，至少社区案例多。K8s我觉得不是必须，除非你预期数据量翻倍很快，否则docker compose先跑起来够用。另外ES召回差可能不全是向量库的锅，试试调下efSearc

这问题太典型了，召回精度不够光靠向量检索真不行。我之前也踩过这坑，后来加了一层rerank模型，像bge-reranker那种，相关性打分能过滤掉不少浑水摸鱼的。另外你可以试试把时间戳和公司名做个结构化过滤，先硬筛再软排序，比纯靠语义靠谱得多。还有，把用户query拆成几个关键实体去匹配，能省掉不少噪音。

这问题我太熟了，之前用LLaMA-Factory调完也踩过一模一样的坑。loss降得好看只能说明模型学会了模仿训练集里的文本分布，但ReAct格式里Action字段的触发条件其实很微妙，稍微和推理时的输入分布有偏差就会崩。你确认过训练数据里每条样本的system prompt和工具描述，跟LangGraph里实际跑的时候完全一致吗？我那次就是训练时偷懒，把工具描述写短了，结果模型根本没学会在长描述

这不是框架的锅，你写法太暴力了，模型复用+inference_mode就够，清cache反而容易出幺蛾子。

大概率是容器没开host网络或者防火墙挡了，试试映射时加`--network host`，再查下群晖自带防火墙。 八成是SSE模式绑定了127.0.0.1，改成0.0.0.0再重启容器，顺便检查下路由器有没有开AP隔离。

几十万篇就pgvector先顶着吧，真到千万级再迁Milvus也不迟，反正数据能导出来。

几十条数据确实有点悬，LoRA微调本身对格式的约束力就弱，尤其工具调用这种对输出结构要求很死的任务，模型很容易在生成时“自由发挥”。我之前用7B模型试过类似的场景，后来把训练数据扩到两百条左右，并且每条都故意混入几种错误写法作为负样本，模型才慢慢学会强制对齐参数名。你可以检查一下数据里是不是所有例子都严格统一了JSON的key顺序和类型，哪怕一个空格或引号不一致，模型都会学到错误模式。另外，3个e

之前跑知识库也遇到过类似问题，后来发现大概率不是索引的锅，而是纯向量检索本身对短文本和长文档就不太友好。bge-large-zh虽然强，但文档切块后语义被稀释了，建议先检查下chunk大小和重叠率，另外试试用query生成几个伪相关文档做hybrid检索，把BM25的分数和向量分数加权融合，召回率能明显改善。reranker可以加，但最好先解决召回阶段的问题，不然排在前面的候选集本身就不对，用bg

这个问题我也踩过坑，后来发现光靠给prompt塞历史记录没用，工具返回的数据得做结构化缓存，比如让每个工具输出都带个session_id，然后Agent侧按key存起来，下次调用时直接从缓存取，而不是靠模型自己记。还有个笨办法是强制让工具返回时把关键信息复述一遍，虽然浪费点token，但比丢上下文强多了。你那边是用的哪种MCP实现？有些框架自带的Memory模块其实能帮上忙，但得自己配置触发条件。

这个大概率是某些算子在ONNX里被重写了，试试把opset降到13以下，另外检查下有没有用到torchvision的插值算子，那个导出容易出问题。

这问题我也踩过坑。LoRA微调确实容易把基座模型的指令跟随能力带偏，尤其学习率2e-4对7B来说偏高了，alpaca格式的模板跟你的结构化prompt风格差太远，模型学到的反而是“自由发挥”的倾向。建议先降到5e-5或1e-5，并且微调数据里掺一些跟你业务分类格式一致的样本，让模型别丢掉原有约束。如果重训成本不高，其实更推荐直接调prompt，把few-shot改成更贴近微调数据风格的写法，可能见

这问题太真实了，我也被卡过，后来在工具调用前加个状态校验，拿到结果就直接跳转，别让它自己决定下一步。

它们本质就是高级补全，你当结对编程的初级助手用就行，别指望理解业务。 我拿Cursor重构过几个内部服务，得把上下文和约束拆得极细，还得一步步喂，急不来。

跟AI改代码确实容易越改越乱，我都是让它先列改动点再动手，比直接重写靠谱。