灯下写码记

PDF转文本表格切碎这点太真实了，chunk大小其实得看文档结构来定，纯文本和表格混排用固定值肯定翻车。我现在是先用layout解析把表格单独抽出来，正文按语义段落切，再给表格块单独加标题前缀，检索命中率明显好转。bge-m3中文不用加指令前缀，它本身是多语言对齐的，加了反而可能拉低效果，你可以先去掉前缀对比下。另外faiss纯向量对语义漂移的query确实容易偏，建议top-k先放大到20再用r

A100 40G跑7B并发10就OOM有点不太对劲，你可能忽略了max_num_seqs和KV cache的联动。vLLM虽然用PagedAttention省显存，但每个序列的KV cache还是实打实占空间的，max_model_len 4096下一条序列大概就要1G多。你试试把max_num_seqs压到8以内，再把enable_chunked_prefill打开，prefill阶段会平摊显存

你这个问题我踩过类似的坑，切法只是表象，核心是召回和排序没分家。按markdown标题切对纯文本还行，但制度文档里表格和条款引用一多，语义就被切碎了，“年假和事假冲突”这种问法压根不在任何单块里完整出现。我建议表格单独抽出来走结构化检索，正文再按条款粒度切，别死磕固定字数，条款边界天然比500字合理。然后别急着上rerank，先看看你的topk是不是取太少了，很多时候答案在第8、第10条被砍掉了。

合同这种结构文档用固定512字符分块确实容易把条款切碎，试试按标题层级或段落语义分块，召回能涨不少。embedding的话bge-large-zh本身不差，但专有名词多的话可以微调一版或用bge-m3，ada-002在中文长尾词上未必更强。Milvus索引影响的是速度不是召回，HNSW和IVF_FLAT只要nprobe调够基本没差，问题大概率出在分块和query改写上。

MCP本身走的是JSON-RPC，协议层就是文本的，传tensor确实不行，但你可以把numpy数组序列化成bytes再用base64塞进content里，client收到再解码还原，我这么干过推理服务，延迟还能接受。不过说实话，数据预处理这种重活让Agent去动态清洗和增强，感觉有点绕远了，Agent更适合做决策调度而不是搬数据。你要真想打通，不如把MCP当控制面，真正的数据管道还是走gRPC或

单卡A100 80G跑7B按理说不至于并发50就OOM，你说的int8量化后首token延迟高，八成是量化本身的开销加上vLLM的调度策略没调好。我之前用vLLM部署7B的时候发现，gpu_memory_utilization这个参数默认0.9其实偏保守，适当拉到0.95配合enable_prefix_caching能明显改善吞吐，但前提是你的请求有共享前缀。多进程加共享显存那条路我劝你别走了，进

按结构切确实更靠谱，我之前也踩过这个坑。用tree-sitter或者Python自带的ast解析出函数和类边界，再按节点切，检索出来的片段基本不会缺胳膊少腿。embedding那边不用大改，只是chunk的粒度变了，但最好在metadata里带上文件路径和函数名，方便后面重排或拼回完整上下文。LangChain有LanguageParser之类的分割器可以试试，或者自己写个简单的AST遍历也不难。

top-k拉太高肯定容易串味儿，先加个rerank卡一道，再把chunk切小点试试。

哈哈`v3_真的最终版`太真实了，我上个月也是这么过来的。后来我逼自己改了个习惯：每次改Prompt之前先想清楚这次到底要解决哪一个具体问题，一次只动一个变量，改完立刻拿同一批测试case跑一遍对比。不然你根本不知道是语气调整影响了格式，还是新加的few-shot把原来的边界搞模糊了。另外我现在会把Prompt当代码管，扔进git里，每次commit写清楚改了什么、为什么改、哪些case验证过，回

我们线上也是A10跑7B，最后选了双卡张量并行，vLLM直接开TP=2，显存压力小很多，长上下文也稳。AWQ确实省显存但吞吐掉得明显，GPTQ稍微好点但也就那样，量化这坑我踩过一轮还是觉得加卡最省心。如果预算卡死只能单卡，试试vLLM的gpu-memory-utilization调到0.9加上enable-prefix-caching，能榨出一点空间。llama.cpp那个Q4_K_M质量还行但并

ChatGLM3-6B做rerank确实有点吃力，它本身上下文窗口和长文本理解就不是强项。我们之前试过用bge-reranker-large专门做精排，比拿生成模型硬做效果好不少，尤其是财报这种信息密度不均的文本。另外你可以试试把长文档按段落切了分别打分再聚合，别整篇塞进去，模型根本抓不住重点。

参数填错这事我也踩过坑，2万条日志3个epoch loss降得快，恰恰说明模型可能只是记住了格式模板，没真正学会参数约束。你数据里如果负样本少，模型没见过"填错被纠正"的信号，推理时自然容易放飞。我之前用类似规模的数据微调，发现漏必填字段很多时候是训练时把多轮对话截断了，工具调用和返回结果没对齐，模型学了个半吊子。换个角度想，7B做严格结构化输出确实有点吃力，但更关键的是解码策略，你试试加cons

5-10个人用14B直接vLLM吧，A100 80G显存够得很，流式输出也稳，部署比TGI省心多了。

跨境电商这条路子倒是挺对，人形机器人现在最大的问题就是找不到真实场景跑数据。不过说实话，海外家庭环境比国内复杂多了，光是欧美那种地毯加宠物毛发的组合，就够避障算法喝一壶的。我比较好奇的是他们怎么解决售后问题，机器人坏了总不能寄回国内修吧，本地化服务网络没建起来的话，规模化出海就是空话。

在prompt里加一句“只import实际用到的库，别加多余的”会好很多，我这么干之后清爽多了。

我也遇到过，后来把规则校验从prompt里抽出来，用独立脚本每轮检查，改了就直接回滚。

只训prompt embedding确实容易这样，尤其GPT类模型，软prompt初始化没弄好基本等于随机噪声，loss降得慢太正常了。我自己的经验是学习率得比全量微调大一个量级，1e-2到5e-2都试过，epoch一般10到20就够，再多容易过拟合。BERT和GPT差别挺大的，BERT双向注意力对prompt更敏感，GPT单向的话prefix tuning效果通常比prompt embeddin

我也有过这疑惑，后来发现关键是别把MCP当“让模型调模型”的中转，而是当统一的工具网关。比如你有一堆内部服务、数据库、权限系统，LLM直接写代码反而不好控，MCP能收口鉴权和审计。至于GPU常驻，推理服务本来就该独立部署，MCP服务器只做转发，别把模型塞进去。并发就靠后端服务自己扩，MCP层无状态就行。

4090跑70B基本别想了，除非用2bit量化再把上下文压到512以内，那输出质量已经没法看了，代码补全经常给你编API。我之前用llama.cpp跑Qwen2.5-32B的Q4_K_M，24G显存刚好塞下，速度大概20 token/s出头，但上下文一过8k就开始明显变慢。你要是主要做代码补全和文档总结，其实14B到32B这个区间性价比最高，7B确实有点不够用。GGUF的Q4量化质量损失没那么夸张

都2024年了还纠结这个属实没必要，图像生成这块PyTorch的生态基本是碾压级别的，diffusers、timm这些库拿来就能用，TF那边你得自己造不少轮子。TF Serving部署确实香，但你现在离部署还远，先把模型跑通调明白再说。师兄们默认PyTorch不是没道理的，跟着大部队走省心。Transformer练手可以看看minGPT或者Annotated Transformer，代码短适合啃。