持续研究内容实践笔记

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

我最近也在搞类似的东西，感觉先别急着动LLM，top3排序不对大概率是embedding对领域词不够敏感，先拿几百条query-doc对微调embedding，成本低见效快。等召回稳了再看LLM，prompt模板跟着调一调基本能兜住，指令理解没那么脆弱。微调数据最好贴近真实检索出来的片段结构，别拿整篇文档喂，不然和线上分布对不上反而更乱。

我之前也卡过这个问题，后来发现512和256其实都不是关键，关键是切分的时候得带点语义边界意识。你举的那个合同例子特别典型，我现在的做法是先按段落切，再对超长段落用句子级滑窗，窗口之间保留20%左右重叠，这样甲方乙方那段至少能有一块同时包含双方义务，召回时不会只捞到半截。重排序确实能救一部分，但别指望它把切坏的语义补回来，它更多是把噪音压下去。bge-reranker-base本地跑压力不算大，我

K8s 上跑 MCP 服务确实容易踩这个坑，本地好好的上生产就断，太常见了。你服务端日志没报错但客户端超时，我第一反应是看 Service 和 Ingress 那层有没有 idle timeout，很多云厂商的 LB 默认 60 秒就掐连接，MCP 的 SSE 长连接正好撞枪口上。heartbeat 这块官方 SDK 的间隔是可以调的，生产环境网络抖动大的话适当缩短心跳、加上重连退避会稳不少。另外

我之前两个都深度用过，说下真实感受。LlamaIndex在索引结构和retrieval这块确实细，node parser和各种retriever开箱即用，几万篇文档的metadata过滤和引用溯源做起来比LangChain顺手不少。但LangChain生态是真的大，后面接agent、监控、eval工具链基本不用自己造轮子。我的建议是别二选一，检索层用LlamaIndex、编排和工具链接LangCh

GPU利用率才30%基本说明不是算力瓶颈，是在等数据或者调度卡住了。AWQ配vLLM有时候确实会掉性能，你可以换FP8或者直接bf16跑一下对比，7B的bf16在4090上也放得下。另外重点看下是不是没开enable-prefix-caching或者dtype设成了float16但实际走了fallback路径，启动时加--enforce-eager先排除CUDA graph的坑，vllm版本和CU

IVF_FLAT得先把向量归一化再建索引，不然内积和余弦对不上，nprobe调再高也白搭。

bge中文确实不差，但你得加个指令前缀，不然效果差一截，chunk 500偏小可以试试800带重叠。

我拿Qwen2.5-7B做结构化输出时也踩过类似的坑，温度0.3到0.5之间反而比0.2更稳，太低模型容易卡在某个token上反复吐同样的东西。top_p我一般压到0.8左右配合温度0.4，repetition_penalty给1.05就行，再高会开始乱改字段名。真要严格JSON的话建议直接贪心解码加格式约束，或者上outlines这类工具，比调参省心多了。

这种情况太常见了，top5里明明有正确答案但模型就是不用，我遇到过好几次。有个容易忽略的点是context拼接的方式，如果你只是简单把5条chunk用换行拼起来，模型很容易被第一条带偏，尤其是第一条看起来也相关但实际不对的时候。bge-m3的检索质量其实还行，但它的相似度分数分布可能很平，导致真正对的那条在语义空间里没拉开差距，模型自己也不会去"挑"。可以试试把最相关的chunk放到context

loss先降后升这个曲线其实挺典型的，2.3到1.8再弹回2.5，大概率不是MCP协议本身的问题，更像是过拟合或者训练后期发散。2k条数据对1.5B模型来说确实偏少，尤其如果tool_call这种结构化字段占比高，模型很容易先记住格式再开始瞎编。你可以先确认一下tokenizer对特殊token的处理，比如tool_call的起始结束符是不是被拆成了多个token，这种情况会让模型很难学到稳定边界

这个现象我也遇到过，而且不止一次，感觉不完全是模型的锅。加了角色设定之后，模型其实是在给自己“加戏”，它会倾向于去满足这个角色的人设，而不是老老实实执行你后面的具体指令。尤其是“资深编辑”“金融专家”这种带身份感的词，模型会自动脑补出一堆跟角色相关的行为模式，结果就是格式约束被稀释了。我自己试下来，角色越具体、越有画面感，跑偏的概率就越高。后来我干脆把角色描述改成功能性的，比如“用简洁客观的语言总

双4090跑32B确实吃力，试试TP=2加FP8，vLLM对FP8支持还行，比AWQ强不少。

我也踩过这个坑，日志里Server明明返回了，但Claude那边就是收不到，最后发现是stdout里混进了别的东西。你检查一下代码里有没有print调试语句没删干净，或者某些库往stdout打日志，MCP对stdio通道的纯净度要求挺高的。建议所有调试输出都改到stderr，stdout只留给协议本身的JSON-RPC消息。另外返回结果记得包在jsonrpc 2.0的标准结构里，id和result

KV cache才是吃显存大头，别光盯着量化，试试gpu layers拉满加kv int8量化。

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

我也卡过这坑，后来发现是Node版本太旧，换到20以上就好了。

数据没做指令格式化是大坑，loss不降正常。ChatGPT重写一遍确实有用，我试过。

这个坑我去年底也踩过，当时用MCP接Qdrant，metadata过滤死活不生效，排查了两天才发现是schema里field定义和实际payload结构错位了。MCP的schema不是简单描述字段类型就行，它其实要求你把metadata当成一个完整的object来声明，而不是把它拆成扁平的entity和field，很多人卡就卡在这一步。你那个source=pdf拿到空结果，大概率是MCP serv

先查下是不是没设eval模式，BN的running stats没同步过去，我踩过这坑。