深夜机器学习备忘录

之前我们团队也纠结过这个，最后选了Milvus，主要是数据量上来后Pinecone那个费用确实肉疼。不过运维这块真得提前做好心理准备，我们没用K8s，直接docker-compose跑单机版+milvus集群的轻量模式，几百万人量级也能顶住。召回率的话，其实跟向量化模型关系更大，数据库影响真没那么玄乎。中文场景主要注意分词和embedding模型的选择，Milvus的hybrid search对B

温度调低确实有用，我一般设0.1-0.2，基本能压住脑补。另外你试试在prompt里加一句“每个回答必须包含至少一处原文引用，没有就直接拒绝”，比单纯说“不知道”管用得多。 还有个坑是top5块之间可能互相矛盾，模型会挑着编。我后来会把每块前面标上“文档A/B/C”，并明确说“仅当多个来源一致时才可综合表述，否则以第一条为准”。你可以观察下是不是检索质量本身有问题，比如语义相似度阈值太低，混进来

20 tokens/s对7B来说确实偏低了，我怀疑瓶颈不在vLLM本身，而在数据预处理或者batch策略上。你试试把max_num_seqs调大点，比如从默认的256往上加到512，有时候并发请求少反而喂不满GPU的算力。另外，Qwen2.5的7B如果没量化，FP16在A100上理论吞吐应该能到80+，你检查下是不是显存碎片化严重，可以试着把gpu_memory_utilization设到0.95

我之前也踩过这个坑，后来发现多半不是timeout的问题，而是LangChain的Agent循环里tool调用链太长，模型在等中间结果时容易卡住。你试试把工具描述写得更精简，还有把max_iterations调小一点，别让它在没必要的步骤上反复横跳。另外gpt-3.5-turbo对复杂工具调用的稳定性确实一般，换个4o或者用function calling模式会省心很多。

这问题我太有同感了，之前我们上线RAG也是这德行，后来发现核心不在chunk或embedding，是生成阶段太依赖检索结果了。你可以试试在prompt里加一层“基于检索信息自由发挥”的指令，比如让模型先总结再补充常识性建议，gpt-3.5其实有能力做到，只是你给的约束太死。另外，把温度调高到0.7-0.9会自然很多，但得注意别让事实跑偏。 我碰过更坑的是，用户问天气，系统把湿度风速全念出来，后来

这个问题我踩过一模一样的坑，后来发现光调chunk size真没用。你提的rerank其实只能解决排序问题，治不了内容断层，我后来用父子chunk结构好很多——检索小片段但把整篇/大段落一起喂给LLM，上下文连贯性立刻上来了。另外bge-m3可以试试加个query指令前缀，或者对召回片段做个简单的关键词去重，也能减少重复内容。不过说真的，RAG对长文逻辑确实天生弱，有时候不如直接让模型先读全文再回

直接跟它说“只准用pandas，别给我换库”，然后代码里写死，它一般就老实了。 我也遇到过，后来干脆在prompt里加一句“禁止使用列表推导式”，效果还行。

我之前也试过bge-large-zh配500的chunk，结果跟你差不多，后来发现是切分太机械，把条款语义切断了。可以先拿几个典型query去跑top20，看召回里有没有相关片段，如果有但排得靠后，那基本是检索排序的问题，直接上rerank能救不少。要是压根没召回到，再回头调chunk重叠或者换更细的切分规则，比如按标题或段落边界切。建议先把这三个环节拆开测，别一上来就换模型，成本高还不一定对症。

我之前也踩过这个坑，光靠prompt约束确实不够。后来把检索回来的chunk按相似度分数做了个加权拼接，分数低的干脆不喂，效果稳了不少。你那个“差一口气”可能不是prompt问题，是chunk里混了太多噪音，试试把召回topK调小点，或者做个简单的rerank（比如用cross-encoder）再进LLM。另外可以把query改写成更具体的问句再检索，有时候原始问题太泛，召回内容就飘了。

试试按段落切分，先语义分段再定chunk，overlap设个128就行，效果比硬切稳很多。 我们项目最后用递归字符切分器，chunk按模型token上限的1/3，overlap设chunk的10%左右，速度准确率平衡得还行。

loss曲线正常但生成结果变呆这个现象我见过不少次，核心嫌疑就是2万条同场景客服数据太聚焦了，LoRA虽然参数少但照样能把注意力头死死拽向你的业务话术，尤其3个epoch对这么小的数据量偏多，1-1.5个epoch可能就够。秩和lr倒不是大问题，2e-4配常见秩数（比如8-16）在中文底座上一般不会直接毁掉通用能力，真正危险的是数据多样性不足——你想想，模型每步更新都在强化“如何回答客服问题”，但

这问题我遇到过，最后是把子图的状态key全部改成独立命名空间才解决的，不然内层覆盖外层是必然的。Reducer别自己硬写list合并，可以用operator.add配合默认值，或者干脆给每个节点单独维护一个状态字段，别全塞在一个dict里。Checkpoint机制确实能解决一部分同步问题，但我觉得你更可能是图结构设计上耦合太紧了，试试把检索结果按时间戳或任务ID存到单独的状态槽里，读的时候指定版本

Ollama的API不是MCP协议，得用mcp-ollama桥接工具，别直接用11434端口。 你试下把serverURL换成MCP网关地址，模型参数不用改，qwen2.5能跑。

24G跑7B FP16按理说不会直接OOM啊，你是不是把max_seq_len和batch size都拉满了？我3090跑同款模型12G显存都能勉强塞下，建议先检查下transformers的generate参数，把beam search关了改成贪心解码，再把KV cache的缓存策略调成分块式。说回量化，GPTQ对中文支持确实弱，我后来改用AWQ 4bit效果会好一点，乱码基本消失，逻辑断链也少

数据比例得调，通用语料至少占六成，不然真会越学越傻。工具触发问题八成是prompt没约束好，试试加个意图分类步骤。

说实话别太纠结框架本身，你研一这个阶段PyTorch绝对够用，组里师兄用啥你就跟着深耕哪个，写代码效率高对idea验证帮助更大。TF部署那套东西等你真到了工业界再补也不迟，而且现在很多公司算法岗其实更看重模型能力和工程思维，框架只是工具。至于移动端部署，PyTorch转ONNX再转TFLite的链路已经很成熟了，除非你要做特别底层的优化，否则那点性能差距真没到影响offer的地步。

这问题我上周刚踩完坑，vLLM 0.6.3对Qwen2.5的prefix caching支持有点迷，你那个第一个请求慢大概率是没开--enable-prefix-caching，加上LangChain每次会带不同的system prompt，cache全失效了。显存剩8G但KV cache不够，典型的预填充峰值把block表撑爆了，你试试把--max-num-seqs调小到8或者16，别让它一次塞

vLLM吃显存确实比FastChat狠，但吞吐量真不是一星半点，6B模型上两张4090跑vLLM绝对够，PagedAttention主要调个max-num-seqs和gpu-memory-utilization就行，别用默认值。显存分配建议tensor并行开2，每张卡留个2-3G给KV cache，不然长文档容易爆。量化的话实测AWQ比int8稳，速度提升大概20-30%，但文档检索场景下质量损失

量化到4bit影响不大，我7B模型配16G跑Agent稳得很，关键是关掉历史缓存只留最近几轮。 试试加个mem0做外部记忆，别全塞显存里，CrewAI和AutoGen也不省资源，本质还是模型在吃。

vLLM的PagedAttention确实能救急，显存占用能砍一半，吞吐还翻倍。不过乱码多半是量化参数没调好，换AWQ试试。