阿南Data手记
Lv.1Open-sourceenthusiast，关注工具与工程实践，主要关注数据工程，分享数据管道建设、分析方法与可视化及真实项目复盘；不追求堆砌概念，只记录验证过的经验。技术会变化，解决问题的方法值得长期积累。
发表的评论
你这个问题我踩过一模一样的坑。角色设定和输出规范应该放在生成阶段的system prompt里，别混进检索用的query里，不然embedding肯定被带偏。我现在是先用原始问题检索，再用LLM把用户问题改写成2-3个查询去多路召回，效果稳很多。你那个“资深专家”的设定留着给最后的生成环节用就行，检索阶段越干净越好。
24G跑7B其实挺宽裕的，你OOM大概率是KV cache吃太多，试试vLLM的gpu_memory_utilization设0.85左右，再加--max-model-len限制到4k，基本能稳住。量化的话AWQ确实比GPTQ稳，可以配vLLM的awq_marlin内核，速度损失不大，代码生成也还过得去。实在不行就上两张卡张量并行，比死磕单卡量化舒服多了。
这个问题我上个月也踩过，当时差点把整个图推倒重来。后来发现其实不是LangGraph的问题，而是我图里边的条件边写得太贪心了，想在一个节点里判断所有分支，结果状态传递的时候字段覆盖得一塌糊涂。你试试把“查库存”和“生成报价”拆成两个明确的节点，中间加一个纯校验节点，只负责检查库存字段有没有值，没有就强制回退到查库存节点，别让模型自己选。另外工具调用顺序乱，很多时候是tool_choice没锁死，模
vLLM 在 Agent 这种单请求、多轮短输出的场景下确实容易水土不服。它的强项是吞吐量，靠 continuous batching 把并发请求攒在一起跑，但你单用户跑 Agent 时基本就是 batch=1，PagedAttention 的优势发挥不出来，反而多了一层调度开销。15 秒这个延迟，先别急着换框架，用 nvidia-smi 看看 GPU 利用率是不是一直趴在 20% 以下，如果是，
我之前也踩过这个坑，固定长度切块确实很容易把语义切碎。后来试了按段落或者标题层级来切，再配合一点重叠窗口，召回质量好了不少。另外可以看看late chunking那类做法，先让embedding模型过完整文档再切，上下文保留得更完整。
微调LLM对检索本身影响不大，它主要改的是生成阶段怎么用检索结果，检索准确率还是看你embedding和召回策略。我之前也踩过这个坑，1000条数据对LoRA来说太少了，而且如果问答对里答案和原文chunk重合度不高，模型根本学不到对齐关系。你试试在训练数据里把正负chunk都拼进prompt，让模型学会区分相关和不相关内容，效果可能比单纯微调问答对明显。学习率3e-4对LoRA偏高了点，容易把原
8G卡跑13B得靠GGUF的Q4_K_M量化，llama.cpp能塞进去但速度就10 token/s左右。你这需求不如直接上API省心。
我一般把检索片段编号后让模型逐条引用，最后再综合回答，能减少它偷懒忽略后面内容。
我也遇到过类似情况，后来发现光靠调Prompt确实很难根治。我的经验是把任务拆成两步：先让模型只做分类，再做摘要，别让它一次干太多事，稳定性会好不少。另外输出JSON出错的话，可以用function calling或者结构化输出功能，比在Prompt里求它靠谱。评估工具我试过promptfoo，能批量跑测试集对比不同版本，比自己手动试省心多了。
我也踩过这个坑，大概率不是 JSON 格式的问题。stdio 模式下最容易出事的是 stdout 混进了别的东西，比如你代码里某个 print 或者库的日志输出，会把 JSON-RPC 的消息流污染掉，客户端解析就卡住了。建议把所有调试输出都改到 stderr，stdout 只留协议消息。另外确认下返回内容有没有按行 flush，缓冲没冲出去也会一直等。
你这个情况我遇到过，大概率是分块把合同条款切碎了，违约金计算标准往往跨好几段，按500字硬切很容易丢上下文。建议先试试按条款结构切，比如以“第X条”为边界，再叠加一点重叠。bge-large-zh中文其实够用，但合同这种同质化文本，光靠embedding确实容易混。query改写可以加，把“违约金计算标准”扩成“违约金 计算方式 比例 逾期”这类关键词，召回会稳不少。
72B用AWQ 4bit单卡确实不现实，光权重就36G左右，加上8k上下文的KV cache，60G打不住很正常。我之前双卡A100 80G跑vLLM，上下文开到16k，batch也就勉强到4。Llama3 70B显存压力差不多，架构几乎一样，别指望省多少。offload到CPU速度会掉到个位数token/s，长文本总结基本没法用，经费紧的话建议先租卡验证配置。
我现在都是先让模型把用到的表字段列出来确认一遍，再让它写SQL，这样能提前拦住不少编字段的情况。few-shot确实有用，但示例最好挑那种容易搞混的场景，比如LEFT JOIN和INNER JOIN的区别，光给正确示例它还是可能犯错。另外温度调到0也挺关键的，默认值下它太爱自由发挥了。
你这个问题大概率不是embedding选错了，bge-large-zh本身没问题。我怀疑是技术手册和会议纪要混在一起，语义空间被稀释了，报销流程这种八竿子打不着的内容都能被召回，说明向量空间里噪声太多了。建议先做个粗分类，至少把手册和纪要分开建索引，再上BM25加向量的混合检索，对“服务器宕机”这种关键词明确的query效果会好很多。另外512字符对技术手册来说可能太长了，关键排查步骤容易被淹没，
跨页表格这个坑我也踩过，PyPDF2确实只能应急，它连基本的单元格边界都保不住。后来我试过pdfplumber配合camelot，前者对有线表格识别还行，后者对无边框表格更友好，但两者都挺挑PDF质量的，扫描件基本没戏。转markdown再切块这个思路方向是对的，关键是切的时候别按固定token切，得按表格语义切，比如把整个表头加数据行作为一个chunk，再在metadata里标注它属于哪张表。跨
BGE加rerank这套确实稳，3090上量化跑勉强够用，要不试试把reranker换成小模型？
说实话你这个情况我太懂了，24G跑7B FP16确实卡在临界点上，就差那么一口气。我的建议是先别急着上A6000，4090其实能挖出不少潜力，关键在vLLM的KV cache和continuous batching，你可以试试把max-model-len调低点，比如2048或者3072，同时开--gpu-memory-utilization到0.95，这样不仅显存够，吞吐还能上来。至于量化掉效果，
你说的这个情况我太有同感了，代码审查这活儿对GPT-4来说确实是个“薛定谔的稳定”场景。我试过几次之后感觉，问题可能不在约束多少，而是你给它的“工作流”不够明确，它自己在那儿摇摆。比如“逐行分析”这种指令，它容易走极端，要么盯着语法细节漏了逻辑，要么为了显得有深度开始脑补性能问题。 我现在的做法是把审查拆成两个独立的Pass，而不是塞进一个Prompt里。第一轮只让它干一件特别窄的事：找拼写错误
检索这块的问题大概率出在query改写上，建议先看看召回结果再赖框架。我试过直接调API自己写，反而更清楚卡在哪。
我也纠结过这个问题，最后两个都写了一遍才踏实。说实话，学术研究和打比赛用PyTorch真的顺手，调试起来脑子不用切换，但真到上线的时候，TensorFlow那套 Serving和生态确实省心不少，尤其团队里要是有人维护过生产环境，基本都倾向后者。