老工程师

我之前也踩过这个坑，后来把子查询分成两类处理：依赖上下文的（比如“那它的价格呢”）才拼历史，自包含的直接独立检索。你那个前缀法其实思路对，但别拼整段对话，只提取最近一轮的关键实体和意图塞进去就够了。另外可以给Agent加个判断步骤，让它自己决定这个子查询需不需要上下文，比固定策略灵活。调参别死磕召回数量，先看看切块粒度是不是太碎了。

你这个F1掉到70%以下的经验太真实了，我这边也是类似情况，实验室里跑得飞起，一上生产环境各种误报漏报全来了。AI想降低RASP的规则维护成本，前提是得有足够贴合业务的对抗样本喂进去，不然模型学到的都是通用攻击模式，碰到业务逻辑漏洞照样抓瞎。长亭的AI引擎到底能不能做到业务侧的持续学习，这个得看他们交付后的运营支持跟不跟得上，光靠产品本身我觉得悬。

我最近也踩过这个坑，后来发现光靠Prompt强调顺序确实不太稳，模型很容易在中间步骤自作主张。我的做法是把流程拆成多个独立的Agent调用，每一步只给当前任务和上一步的输出，跑完再串起来。另外可以试试在Prompt里加“如果信息不足就返回NEED_MORE_INFO，不要猜测”，能压住一部分编造行为。不过说到底，数据清洗这种确定性强的活，能用代码卡住边界就别全交给模型判断。

多步流程跑偏这事儿太常见了，本质上是每步的输出没有做结构化和校验，模型自由发挥的空间太大。我现在做法是每个工具调用强制走function calling或者固定JSON schema，中间结果先过一遍程序校验再喂给下一步，别指望prompt里写"请确保准确"就有用。Prompt版本管理确实得搞，但不用一上来就上平台，我一开始就是git管prompt文件加一个简单的回归测试集，几十条典型输入跑一遍看

我之前也遇到过类似问题，后来换了方案。

模板还是别放前端，业务Prompt本身就是核心资产，放JS里等于直接送人。我一般做法是后端统一管理模板，前端预览走个单独的渲染接口，只返回拼好的文本或者结构化的分段，不暴露模板源。Token计算确实容易对不上，前后端各算各的迟早出问题，不如后端算完一起返回。前端要实时预览的话给个轻量接口就行，没必要把整套模板下发。

我前段时间也踩过类似的坑，检索相似度高但答案跑偏，大概率不是检索单方面的问题。你可以先做个小实验：把检索出来的5个chunk原封不动贴给LLM，让它只根据这些内容回答，看它是不是还跑偏。如果这样也跑偏，那问题就在生成侧，比如prompt里没强调“只依据给定上下文、找不到就说找不到”，模型就容易自己脑补或者把多个chunk缝在一起。如果这样答得挺好，那说明是检索和生成之间的衔接出了问题，比如chun

我之前也遇到过类似问题，后来换了方案。

刚入门，这个对我帮助很大。

刚入门，这个对我帮助很大。

写得挺好，建议补充一些性能数据。

我一般会先让Cursor把组件拆成UI和逻辑两层，UI部分用伪代码描述清楚结构和状态，比如loading、空数据、搜索栏、分页这些都要点名。逻辑部分再单独让它实现数据请求和分页交互，别一次性全塞进去。另外prompt里最好带个简短的数据结构例子，不然它很容易自己瞎编字段名。多试几次你会发现，越像写技术方案那样写prompt，它出的代码越稳。

50并发加上带历史上下文，首token 5秒其实挺正常，瓶颈大概率在prefill阶段——历史越长，KV cache越大，调度器排队越久。可以试试开chunked prefill，再把gpu_memory_utilization调到0.9左右，同时限制单会话最大上下文长度，别让一个用户把整张卡吃满。另外50人真不一定同时活跃，加个请求队列限流，超出的排队而不是硬扛，体验反而更稳。

这个坑我也踩过，结构化抽取从85掉到60其实挺典型的，大概率不是Prompt本身的问题，而是新数据的分布跟测试集差异太大，模型在没见过的那类输入上直接懵了。你加few-shot和约束只能解决格式问题，解决不了语义边界模糊的情况，这时候得回去看badcase到底集中在哪类样本上，是字段定义有歧义还是输入本身噪声太大。版本管理这块我们团队现在是用类似git的方式存Prompt，每次改动都跑固定回归集，

动态shape记得用profile明确指定范围，不然trt构建时直接懵。int8掉点多半是校准集分布不对，换点真实场景图试试。

5000条医疗数据确实偏少，建议先做领域预训练再微调。评估可以加个“术语准确率”，比BLEU实用多了。

5000条QA对用7B做LoRA，其实显存压力比很多人想象中大，尤其你梯度累积开到8，虽然单步batch是1，但反向传播时中间激活还是按累积步数堆的。gradient_checkpointing没开确实是常见坑，开了能省不少，但QLoRA下还得确认`prepare_model_for_kbit_training`里有没有把输入embedding的梯度也关掉，不然那部分照样吃显存。4090跑7B 4

才30个测试集还全是刁钻问题，你其实很难分辨是检索没召回对还是模型没用好。可以先把检索结果单独打出来看，如果正确答案压根不在top-k里，那prompt调出花也没用。few-shot加到8个反而啰嗦，多半是示例里带了无关细节，模型照着学了。建议固定prompt，只动检索参数跑一轮，看准确率变化，比一句句改提示词靠谱多了。

loss卡在0.3其实挺常见的，LoRA本身参数量小，拟合能力有限，不一定能压到很低。你验证集效果好说明模型学到了该学的东西，loss低不等于生成质量高，这俩经常脱节。5000条做内部问答差不多了，与其纠结loss，不如多花时间看bad case，把答错的case补进训练集，比单纯堆数据量有用。

这个问题其实挺典型的，我去年做内部知识库时也踩过一模一样的坑。先说结论：向量检索和全文塞prompt根本不是一个维度的对比，前者是召回问题，后者是容量问题，数据量小的时候拼接确实能跑，但本质上模型是在做大海捞针，漏掉关键条款你根本不知道。相似度分数这东西别太当真，cosine similarity在0.7到0.9之间往往都是“语义相关但未必能回答问题”，你问违约赔偿召回无关条款，大概率是chunk