一路升级全栈修炼册

我也踩过这个坑，光写“严格引用”基本没用，模型该编还是编。后来改成让它先摘抄原文句子再回答，并且明确说“找不到就回答不知道”，幻觉明显少了。长文本建议按语义切短一点塞进去，整段放反而容易让模型抓不住重点。另外可以在prompt里加一句“不要改写、不要总结，只允许基于以下片段回答”，比单纯强调“准确”管用。

试试response_format强制json模式，再配个正则兜底清洗，基本能压到1%以下。

PDF表格提取本来就容易翻车，不如先让AI写单文件跑通再拆模块，幻觉会少很多。

试试把工具返回的JSON结构固定下来，再在prompt里明确告诉它啥样算成功，不然模型容易瞎猜。

这问题我也踩过，后来发现光靠系统提示强调“别乱改”基本没用，Agent该发挥还是发挥。我的做法是把迁移拆成小步骤，每步只让它改一个文件或一类Bean，改完立刻用编译和测试卡住，不通过就回滚重来。另外那个“过度自信”的毛病，可以在工作流里加个强制确认节点，遇到它不确定的命名或逻辑改动就必须先输出方案让你点头。工具层面换不换另说，但代码库级重构确实得靠这种细粒度约束，别指望一句提示词搞定。

我目前用的是bge-large-zh配合本地部署，中文场景效果比ada-002还稳，关键是零API成本。如果你主要跑英文对话，可以试试bge-small或者gte-small，速度飞快，小项目完全够用。向量库这块，Chroma上手确实无脑，但Milvus Lite现在也挺轻量，数据量上万条之后Milvus的检索优势会明显些。建议先用Chroma把流程跑通，后面真遇到瓶颈再迁移也不迟。

分层输出这点太真实了，能改的AI才是好AI，不然生成完还得重画一遍。

你这套配置挺标准的，但检索不稳大概率出在chunk策略上。512字符对中文来说信息量其实不小，关键看你的文档结构，如果是问答对或者条款类的，切太碎反而丢上下文。建议试试按语义或标题层级切，再配合bge-m3的多向量能力，别只存单向量。另外top_k取5偏少，可以加到10再用rerank筛一遍，效果会稳很多。

这个问题我也踩过坑，后来发现关键是把“指代消解”和“检索”拆开做。比如先让模型把“刚才那个方案”改写成一个自包含的查询，再去检索，命中率会高很多。另外我会把每轮的关键实体和结论单独存一份轻量记忆，检索时只带相关的那几条，不把整段历史塞进去。单纯拼历史确实容易被带偏，尤其是话题一换，召回全是上一轮的残留。

加个“必须逐步输出思考过程”的指令试试，我这边用下来对代码结构稳定不少。

双4090别硬刚70B了，换32B的AWQ加vLLM，速度质量都舒服很多。

stdio模式子进程默认工作目录是根目录，你server里读文件用相对路径的话铁定找不到，换绝对路径试试。

Agent这块我也有同感，之前用GLM-4调工具链确实经常翻车，参数对不上是常事。4.5如果真把多轮状态保持做扎实了，那比刷榜有意义多了。不过那个30%一致性提升，我也觉得得看测试集怎么设计的，开放性任务上数据质量的影响可能比架构大。等实测跑几个真实workflow再下结论吧。

我也遇到过这问题，后来发现光在prompt里说没用，得把types文件用@引用到对话上下文里才稳。另外tab补全确实不太吃类型约束，换成agent模式或者手动选中类型定义再让它生成会好很多。还有个偏方是在组件文件顶部先import好类型，AI看到实际引用后乱塞any的概率会下降。cursor有时会自作聪明重定义类型，我一般生成完立刻让它对比types.ts做一次diff修正。

LoRA微调本身可训练参数就少，计算密度低，torch.compile那套算子融合的收益基本被吃掉了，减速不奇怪。reduce-overhead模式主要针对小batch推理场景，训练用它反而容易踩坑，试试default或者max-autotune。显存涨是正常的，编译会缓存一些中间结果和额外kernel，deepspeed stage2下更明显。真想压吞吐的话建议先关掉compile跑个basel

我也踩过这个坑，本地跑Agent最折磨人的确实不是模型选型，而是输出格式的稳定性。你遇到模型把工具返回的JSON当普通文本吐给用户，本质上是它没分清“Observation”和“Final Answer”的角色边界，7B模型尤其容易犯这毛病。我后来换成带function calling微调过的Qwen2.5-7B-Instruct，再配LangChain的structured output par

说实话我对8B模型没啥期待，它记忆和指令跟随本来就有限，模板再花哨也救不了。我自己试下来，把系统提示词压到两三行，明确写“只回答事实，不闲聊”，然后对话历史每轮都截断到最近六条，效果反而比加一堆角色设定稳。 温度这块我也踩过坑，0.6到0.7比较安全，高了必跑偏。建议你直接拿Llama官方推荐的chat模板改，别自创结构。至于万能模板，真没有，每个模型对标点和关键词敏感度都不一样，只能自己拿几十

8卡3090跑70B光权重就要140GB，加上KV cache和激活值，192GB其实很紧。你TP=8每卡22GB说明已经接近极限了，慢大概率是跨卡通信瓶颈，试试TP=4+PP=2，同时把KV cache比例调低点。int8量化能省一半显存，速度反而可能更快，AWQ或GPTQ都可以试。4张卡跑int8其实挺稳，但吞吐量肯定不如8卡，关键看你要并发还是单流延迟。

我跟你情况差不多，也是本地跑Qwen系列配LlamaIndex，当时在Chroma和Qdrant之间纠结了好久。Chroma确实轻，但数据量到几十万条embedding后查询延迟会明显上来，而且它那个持久化偶尔会出些小毛病，不太适合公司内部长期用。后来换了Qdrant，docker起个容器也就几分钟的事，跟LlamaIndex的集成很顺滑，几乎零代码改动迁移过来的。中文文档检索这块，我觉得关键不在

八成是数据格式问题，中文医疗对话得带system prompt约束角色，另外试试3e-5的学习率。