深夜大模型备忘录

我之前也踩过这个坑，后来发现核心问题往往不是模型不行，而是你的工具描述和prompt里对“什么时候该用哪个工具”写得太模糊了。建议把每个工具的description写得更具体，比如“当需要数学运算时调用”，而不是“计算器”，这样模型误判概率会低很多。中断大概率是输出格式解析失败，可以试试在prompt里强制要求只输出JSON格式，并且用Pydantic解析器来兜底。另外max_iterations

说实话我之前也纠结过这个问题，最后是直接上了BGE-large-zh没换OpenAI。中文场景下，ada-002对中文语义的理解确实不如专门训练的中文模型，尤其是一些领域术语和口语化表达，BGE的向量空间会更贴合。不过你说的召回率没评测，我建议可以拿你们自己的文档抽个几百条做个小测试，用hit rate和MRR看下，比网上任何教程都靠谱。 至于Rerank，确实能兜底，但别指望它完全弥补Embe

这问题太真实了，我上个月刚被折磨完一轮。试下来感觉pdfplumber直接抽表格结构还行，但一遇到跨页或者合并单元格就原形毕露，后来干脆放弃纯文本流，改用OCR管线把整页转成Markdown再喂给模型。表格转文本这块，我踩过最大的坑就是切块——别按固定token切，最好先按行识别，保留表头作为每块的上下文前缀，比如“资产负债表-流动资产-应收账款”，这样embedding检索时语义才不散。另外有个

我都是让它按我写好的接口和数据结构来补，不然版本一混就白搭，还是得自己先定好骨架。

function calling确实是正解，尤其是字段缺失这种问题，靠prompt很难根治，模型本质上还是概率生成，输出长度和格式稍微一飘就容易崩。我之前也踩过这个坑，后来直接改成在prompt里要求“把JSON放在```json代码块里”，再配合正则提取，基本能挡住90%的脏数据。不过最稳的还是直接走API的structured output或者function calling，让模型自己按sc

试试把任务拆成独立小步，每步单独校验输出，比硬控思维链稳多了。

4090跑7B其实挺极限的，你试没试过把max_batch_size调大然后用continuous batching？vLLM确实能省不少显存，关键它把KV cache和激活内存都优化了，你那个4bit慢多半是量化没走对路，试试GPTQ或者AWQ的预量化版本，乱码大概率是校准集没弄好。另外多请求复用同一个模型实例就是vLLM的核心功能，不用自己折腾GPU共享，直接上vLLM把torchserve换

这问题我上周刚踩完坑，MCP那层协议本身只管消息传递，它不关心你payload里是tensor还是别的，所以“Expected tensor, got dict”基本就是你handler里没做反序列化导致的。官方示例确实全是JSON，那是因为他们demo都是文本任务，你这种图像输入得自己在service端把base64字符串先解出来，再走torch的frombuffer之类的转成tensor，没捷

这太正常了，MCP现在就是个协议层，动态更新还得自己搞，别指望生态帮你解决。 监听文件变化触发增量索引呗，或者干脆定个短周期轮询，比手动强点但本质还是半自动。

说实话你这准确率瓶颈不太像数据量的问题，5000条做四分类其实够用了。我怀疑是LoRA只改了attention层的权重，对这种短文本语义抽取任务来说，模型底层特征根本没被充分激活，你可以试试把target_modules全开了，或者直接全量微调几轮对比下。另外合同文本里专业术语和数字占比高，Llama-2的tokenizer对这类内容不一定友好，要不要先做下词表扩充或者用领域预训练模型做底座？我之

说实话6.7B这个量级跟Copilot背后那套大模型比上下文理解本来就是降维打击，别太指望它跨文件推理。我试过把相关代码片段直接粘到prompt里让它续写，比光靠注释强不少，但变量名冲突还是得靠人工改。另外你可以试试把温度调低到0.1，补全会更保守但至少不会乱编变量。

我倾向方案二，先查再塞context，模型调用工具容易把格式搞乱，延迟其实可控。 我们实测过，方案一模型经常误触发检索，反而不如后端直接塞top-k稳定。

说实话bge-large-zh在领域专有名词上确实容易飘，尤其产品手册这种术语密集的文本，纯向量召回天然吃亏。我建议你先拿BM25跑一下同样的query对比，大概率能看出差异。另外重排的话可以看看bge-reranker-base，几G显存就能跑，个人项目完全够用。

遇到类似情况的话我建议先别急着换模型，固定512字符切分对产品手册这种结构化文档确实容易把操作步骤拆散，试试按标题或章节段落来切，保留语义完整性。另外BM25能命中说明关键词匹配是有效的，可以看看是不是embedding检索时被太长的上下文稀释了，考虑先做召回归一化或者混合检索再rerank。还有个小点，ada-002对中文长尾术语本来就一般，但你换bge提升不大可能跟chunk粒度关系更大，可以

说实话我第一反应是问题可能不在embedding模型上，而在你的检索策略和模板本身的结构上。你举的例子“产品介绍”和“技术方案对比”语义上确实有重叠，尤其当用户输入比较简短时，向量空间里它们可能离得很近。我之前做类似工具时发现，光靠纯向量召回很容易把“意图边界”弄模糊，后来我加了一层规则前置过滤，比如先用关键词或小模型粗分类一下用户意图，再在限定类别里做向量检索，效果直接提升了一个档次。另外你也可

我基本不会直接merge，尤其是涉及到并发、重试、状态机这种带隐式时序的逻辑，AI写出来经常是“看起来对但经不起推敲”。我的习惯是让它生成初版，然后自己把边界条件和异常路径重新捋一遍，相当于把它的代码当伪代码看。测试兜底确实必要，但只能证明它“跑得通”，不代表资源管理和竞态没问题。省时间是真的，但信任度还是得看具体场景，工具适合写胶水代码，核心逻辑还是得自己把关。

把业务规则拆成小函数喂给AI，让它只补逻辑别自由发挥，异常处理自己兜底。

大概率是field的type定义成了string而不是keyword，Chroma那边过滤必须用keyword类型才能精确匹配。

我之前也踩过这个坑，后来发现问题往往不在prompt本身，而是改写后query和embedding模型的匹配度变了。bge-small对口语化文本的分布可能更友好，你改成书面语反而拉远了向量距离。建议试试把改写prompt限定为“补充同义词和实体，不改变句式”，或者直接对比一下改写前后在向量空间里的相似度。还有个偷懒的办法：用原始query和改写query各检索一遍，结果做个加权融合，效果通常比单

我之前也踩过这个坑，动态batch建议还是别用-1，显式指定min/max那个API是对的。你推理结果对不上大概率不是算子回落，而是TensorRT对某些层做了精度调整，试试关掉FP16或者设`setFlag`看下。固定batch确实省心，但如果你batch波动大，可以按1/4/8做三个优化profile，运行时选最近的那个，工业场景够用了。另外你检查下预处理和后处理是不是在TensorRT外面做