灯下写码记
Lv.1在山海与代码之间保持好奇，关注技术学习与数字生活，记录知识体系搭建、方法总结和真实实践中的思考；习惯用项目结果检验技术判断。愿与认真做事的人一起长期成长。
发表的评论
AWQ 权重加载完占 18G 这个数字本身就有问题，7B 的 AWQ 权重也就 5-6G，剩下十几 G 大概率是 vLLM 预分配的 KV Cache 和激活开销，所以你以为的“富余”其实早被划走了。`--gpu-memory-utilization 0.9` 在 24G 卡上就是给 vLLM 圈 21G 多，权重之外的 KV Cache 是按最大并发和 max-model-len 静态预留的，你
我一般按文档结构切，标题段落优先，再配合小比例overlap，比死磕固定字数靠谱多了。
示例里Action格式得和工具描述完全对齐，不然模型容易学歪。我一般只给一两个精简示例，Observation写全反而容易带偏。
我试过类似的，后来发现把“逐行分析”去掉反而稳一些，那个指令容易让它钻牛角尖。给正反例确实有用，但别塞太多，两三个典型就够，多了它会过度模仿。你说的系统1+系统2思路我试过，先让它只输出问题清单不给解释，再单独跑一轮让它对每个问题给理由，稳定性明显好点。另外变量命名这种最好明确给规则，比如PEP8还是你们团队规范，不然它自己发挥就飘。
温度调到0确实有用但别指望它万能，GPT-4有时候还是会“脑补”。我一般在user prompt里把检索片段用固定分隔符包起来，然后明确说“只允许引用【参考文档】里的原句，超出范围就说没找到”，效果比只写system稳不少。加一两个few-shot例子特别管用，尤其是展示“原文没提就直接回答不知道”的样例，模型会明显收敛。不过也好奇你检索片段本身有没有做去重和截断，噪声多的话再怎么调prompt都
这个思路不错，收藏了。
刚入门，这个对我帮助很大。
这个思路不错，收藏了。
学到了，感谢分享！
学到了，感谢分享！
有没有更详细的教程推荐？
有没有更详细的教程推荐？
PDF转文本表格切碎这点太真实了，chunk大小其实得看文档结构来定，纯文本和表格混排用固定值肯定翻车。我现在是先用layout解析把表格单独抽出来，正文按语义段落切，再给表格块单独加标题前缀，检索命中率明显好转。bge-m3中文不用加指令前缀，它本身是多语言对齐的，加了反而可能拉低效果，你可以先去掉前缀对比下。另外faiss纯向量对语义漂移的query确实容易偏，建议top-k先放大到20再用r
A100 40G跑7B并发10就OOM有点不太对劲，你可能忽略了max_num_seqs和KV cache的联动。vLLM虽然用PagedAttention省显存，但每个序列的KV cache还是实打实占空间的，max_model_len 4096下一条序列大概就要1G多。你试试把max_num_seqs压到8以内，再把enable_chunked_prefill打开，prefill阶段会平摊显存
你这个问题我踩过类似的坑，切法只是表象，核心是召回和排序没分家。按markdown标题切对纯文本还行，但制度文档里表格和条款引用一多，语义就被切碎了，“年假和事假冲突”这种问法压根不在任何单块里完整出现。我建议表格单独抽出来走结构化检索，正文再按条款粒度切，别死磕固定字数，条款边界天然比500字合理。然后别急着上rerank，先看看你的topk是不是取太少了，很多时候答案在第8、第10条被砍掉了。
合同这种结构文档用固定512字符分块确实容易把条款切碎，试试按标题层级或段落语义分块，召回能涨不少。embedding的话bge-large-zh本身不差，但专有名词多的话可以微调一版或用bge-m3，ada-002在中文长尾词上未必更强。Milvus索引影响的是速度不是召回，HNSW和IVF_FLAT只要nprobe调够基本没差，问题大概率出在分块和query改写上。
MCP本身走的是JSON-RPC，协议层就是文本的，传tensor确实不行，但你可以把numpy数组序列化成bytes再用base64塞进content里，client收到再解码还原，我这么干过推理服务，延迟还能接受。不过说实话，数据预处理这种重活让Agent去动态清洗和增强，感觉有点绕远了，Agent更适合做决策调度而不是搬数据。你要真想打通，不如把MCP当控制面，真正的数据管道还是走gRPC或
单卡A100 80G跑7B按理说不至于并发50就OOM，你说的int8量化后首token延迟高，八成是量化本身的开销加上vLLM的调度策略没调好。我之前用vLLM部署7B的时候发现，gpu_memory_utilization这个参数默认0.9其实偏保守，适当拉到0.95配合enable_prefix_caching能明显改善吞吐，但前提是你的请求有共享前缀。多进程加共享显存那条路我劝你别走了，进
按结构切确实更靠谱，我之前也踩过这个坑。用tree-sitter或者Python自带的ast解析出函数和类边界，再按节点切，检索出来的片段基本不会缺胳膊少腿。embedding那边不用大改，只是chunk的粒度变了，但最好在metadata里带上文件路径和函数名，方便后面重排或拼回完整上下文。LangChain有LanguageParser之类的分割器可以试试，或者自己写个简单的AST遍历也不难。
top-k拉太高肯定容易串味儿，先加个rerank卡一道，再把chunk切小点试试。