终身学习创业修炼册

“请”可能真有点用，我试过加礼貌词后输出确实稳一些，感觉像是激活了模型训练里的礼貌模式，不全是玄学。

写代码我一般用0.2到0.3，再高就容易瞎编库函数了。top_p可以压到0.9左右，repeat_penalty别超过1.1，不然代码里重复的变量名会被莫名改掉。其实Qwen2.5-7B本身代码能力就那样，参数调再好也有限，不如换个coder版本试试。API和Ollama底层调参逻辑差不多，但API那边有些平台会偷偷改默认值，最好自己显式传参。

维度不是越高越好，关键看模型本身训练得咋样。你拿128维的小模型去跟ada-002比，那肯定不公平，人家1536维是拿海量数据喂出来的。中文技术文档我试过bge-large-zh（1024维）和m3e-base（768维），768维在16G内存上跑几万条完全没问题，检索质量也够用。建议你先拿几百条真实query做个召回测试，对比top5命中率，比瞎猜维度靠谱多了。

我之前也踩过一模一样的坑，后来发现光靠prompt真压不住，模型该编还是编。你可以试试把“仅根据上下文”换成更具体的指令，比如“先引用原文条款，再用一句话解释它怎么对应问题”，这样能逼它贴着材料走。另外top3召回没问题不代表排序对，可以打印出来看看第一条是不是真的最相关，有时候法条之间太像了，模型也懵。实在不行就上少样本示例，给一两个标准问答格式，比空喊“别瞎编”管用多了。

200万向量这个量级其实挺尴尬的，说大不大说小不小，Milvus集群三节点扛得住但架不住你近实时写入和查询抢资源。你监控看到的段合并吃CPU基本就是根因，Milvus的segment compaction在写入频繁的时候特别凶，索引还没建完查询就得扫全段，延迟不抖才怪。我之前类似规模调过几个参数，把dataCoord的segment小文件合并阈值调大，同时给查询节点单独隔离资源，别跟index n

先看看召回的内容里有没有互相矛盾的片段，模型经常是把不同文档的结论硬拼到一起了。

这个问题挺典型的，我一开始也踩过类似的坑。AI写代码确实擅长搭骨架，但工程细节上它经常“想当然”，比如编码问题它默认就是UTF-8，多线程它只管写出来能跑通，至于锁释放、异常处理这些它不太会主动兜底。你遇到的不是prompt姿势问题，而是这类边界情况本身就需要你自己有判断力。我现在用AI辅助写代码的方式是：让它先出个草稿，然后我自己逐行看，重点检查异常处理、资源释放、编码声明这些地方，发现不对就追

这个问题其实挺典型的，我一开始搭RAG也踩过一模一样的坑。top-k设成10以上，召回一堆东西，模型就开始自由发挥了，尤其是技术手册这种本身就有很多相似表述的语料。后来我的做法是先把检索结果做个重排，用cross-encoder或者简单的MMR来降冗余，效果比单纯调top-k好不少。另外你可以试试在prompt里明确要求模型只依据最相关的片段回答，如果片段之间冲突就指出冲突而不是硬编一个答案。还有

这块确实头疼，我现在的做法是给每个工具加一层校验，参数先用schema卡一遍，返回结果也做异常兜底，不然模型偶尔传个空值或者格式不对就直接崩了。另外重试机制也得有，但别无脑重试，区分下是网络抖动还是参数错误，后者重试多少次都没用。还在考虑加个fallback工具链，主工具挂了能自动切备选，你们有试过这种吗？

并发一上来延迟飙到10秒，大概率是排队而不是单次推理慢，先看看vLLM的metrics里等待队列是不是爆了。A100单卡跑7B其实够用，关键是把gpu_memory_utilization拉到0.9左右，max_num_seqs别设太小，不然batch根本填不满。量化对显存有帮助但对延迟提升有限，可以试试开chunked prefill，长prompt场景效果挺明显。多卡不是必须的，先确认是不是请

两张A100 80G跑7B按理确实不该爆，我觉得问题大概率不在模型本身，而是vLLM那套默认配置太激进了。你试过把gpu_memory_utilization压到0.85左右吗？留点余量给KV cache的动态增长，很多时候OOM就是缓存预估没跟上实际并发。另外Qwen2.5-7B如果用FP16加载，权重也就15G左右，剩下那么多显存全被KV cache吃掉了，max_model_len设太大也是

分块和embedding确实得搭配着调，bge这类模型对语义完整度挺敏感的，512字符硬切容易把一句话拦腰截断。你那个“修改密码”召回“密码复杂度”的情况，更像是query和chunk的语义粒度没对齐，试试按标题切完再用递归分块，保留段落完整性。粗召回加cross-encoder重排我这边实测有效，尤其FAQ场景，top20重排到top5能明显压掉那些沾边但不答的。不过重排会加延迟，得看你的响应要

20万条lists才100太少了，建议先按sqrt(n)调到400左右，probes也提到20试试。

你这个情况我去年做内部运维知识库时也踩过，bge-large-zh对通用语义是够用的，但企业内部的缩写、产品代号、流程黑话它真不一定吃得透，尤其是操作步骤这种query，关键词往往比语义更重要，纯dense很容易被那些“讲概念”的长文档带偏。你可以先别急着换模型，拿几条badcase把query和召回的chunk拿出来对比看看，到底是embedding漂了还是chunk本身就没切对。操作步骤类的文

我之前也遇到过类似情况，感觉光说“健壮”太抽象了，AI根本不知道你具体要啥。后来我把要求改成“每个IO操作必须包try-except，网络请求必须设timeout=10”，效果就好很多。few-shot确实有用，给一两个带完整异常处理的例子，它模仿得挺像。自查的话可以生成完再发一句“检查上面代码有没有遗漏异常处理，有就重写”，比一次性要求靠谱。

几百个用户真没必要上Pinecone，Chroma或者Qdrant本地跑完全够，省下的钱够你调好几轮embedding了。Milvus索引调半天召回还降这事我也踩过，大概率是nlist和nprobe没配好，小数据量直接用HNSW默认参数反而稳。距离计算基本都支持余弦和L2，但有些库默认归一化有些没有，换库时这块最容易翻车，记得确认下。

可以试试按标题层级切，overlap给个10%到20%就够，别硬调数字。

我之前也踩过这个坑，后来是把重排序做在检索之后，只把top3到5个chunk塞进MCP返回，比单纯截断靠谱不少。窗口滑动其实不太适合RAG，因为chunk之间语义不连续，滑了也容易丢关键信息，不如在检索侧控制粒度。你说的MapReduce思路可以试试用MCP的sampling或者让agent自己多轮调用，虽然麻烦点但效果还行。

T4那点带宽确实是硬伤，才320GB/s，跑fp16的7B模型基本就是卡在显存读写上了，换A10或者4090会好很多。量化的话可以试试AWQ或者GPTQ的int4，ChatGLM社区有现成的量化权重，效果掉得不多，生成速度能翻两三倍。另外vLLM的版本也很关键，老版本对T4的paged attention支持一般，建议升到最新版再试试。

我一般会在项目根目录放个.cursorrules文件，把组件模板规范写清楚，比如“只保留显式传入的props，禁止添加未使用的className和onClick”，这样比每次在prompt里强调管用多了。另外补全的时候尽量先自己把函数签名和关键props敲出来，让它只填内部逻辑，别让它自由发挥接口层。AI确实有过度设计的倾向，尤其训练数据里那些“完整示例”害的，习惯就好。