实战派LLM应用札记

几十万分片用Chroma确实会有点吃力，它更适合小规模快速验证。可以试试Qdrant，单机Docker就能跑，不用etcd那些，性能比Chroma好不少，迁移成本也低。混合检索我觉得挺有必要的，纯向量对关键词匹配确实弱，尤其专有名词多的时候，BM25加向量召回率提升很明显。

我也踩过这坑，后来发现关键是模型对“约束词”的敏感度远高于礼貌用语。像“严格按格式”“只输出JSON”这种硬指令，本质是在压缩它的输出分布，比调温度靠谱多了。所谓高级模板失灵，多半是任务边界没对齐，不是玄学。建议你把失败案例里的输入输出对整理成小测试集，改一版prompt就跑一遍，慢慢就有手感了。

500字符固定切确实容易把语义切碎，尤其技术手册这种标题层级明显的文档。我一般先用标题递归切，再按段落合并，块大小控制在300-800字符之间，看内容密度调。你说的“网络”误召回，很可能是因为chunk里混了太多无关上下文，embedding被稀释了。另外可以试试加个rerank模型，先粗召回再精排，比单纯调k值管用。

退款和换货语义太近了，光调embedding没用，加个query改写把意图先分类再检索试试。

几十万文档量其实两个都能扛，关键还是看你团队有没有人愿意折腾运维。Milvus功能确实全，但你要是用standalone还好，集群版那套etcd、pulsar、minio的组合，没点k8s底子真容易踩坑，我见过不少团队光调部署就耗了一两周。Qdrant单机部署是真的省心，一个二进制文件跑起来就能用，过滤这块它的payload索引做得挺顺，按时间戳或user_id筛基本是原生支持，混合查询写起来比M

我一般让Copilot管补全，ChatGPT只用来理逻辑，别让它俩写同一段代码，省得来回改格式。

温度调到0.1试试，知识库别塞中间，放开头结尾模型才记得住。

我之前也踩过这个坑，后来发现关键不是prompt写多长，而是把“硬约束”和“软引导”分开。硬约束就那几条：必须基于检索内容、不确定就说不知道、引用要标来源编号，这些写死没毛病。但回答的结构和语气别定太细，不然模型就变成复读机了。我现在的做法是system里只放角色和边界，具体任务指令放到user message里动态拼，比如检索回来的片段质量高就让它“整合归纳”，质量差就让它“仅提取原文相关句子”

18G不算离谱，vLLM预分配显存加KV cache本来就吃得多。首token慢先看下是不是没开chunked prefill。

试试把查库存和报价拆成两个子图，主图只负责路由，别让模型自己选顺序。

几百万条embedding用faiss确实容易卡内存，我之前也踩过这个坑。后来换了Qdrant，Docker起一个单节点很省事，增量更新和payload过滤都挺顺，资源占用比Milvus轻不少。不过你要是查询并发真不高，pgvector其实也够用，就是过滤条件复杂了之后性能会有点拉胯。建议先拿Qdrant试一周，不行再换Milvus也不迟。

这个问题挺典型的，多步推理任务里Agent确实很容易“跳步”。我自己的经验是，光靠Prompt里写“严格按步骤”基本没用，因为模型本质上是在做概率生成，不是在执行程序。你可以在每一步后面加一个明确的“输出检查点”，比如要求它必须先输出当前步骤的结论，再进入下一步，这样能稍微约束一下。但更关键的是，你提到的用代码拆解步骤其实是对的方向，把多步流程做成状态机或者函数调用，让Agent只负责每一步内部的

我最近也踩过类似的坑，用LLM直接做长文本精排确实容易翻车，尤其是财报这种信息密度高、关键句又分散的文本。ChatGLM3-6B本身上下文窗口有限，你就算硬塞进去，它注意力也早就被稀释了，更别说精准判断相关性。我后来换成先分段做粗筛再聚合打分，比如把长doc切成小块分别算相关性，然后取top片段代表整篇，效果比整篇塞进去好不少。另外你可以试试用bge-reranker-large这类专门的cros

几十万切片这个量级其实挺微妙的，说大不大说小不小，chroma翻车大概率不是它本身的问题，而是默认的HNSW参数和距离度量没调，你换embedding模型当然救不回来。我自己的经验是，这个规模下qdrant和milvus单机版都能轻松扛住，延迟差距在几十毫秒级别，真正影响召回的是你的切块策略和是不是加了rerank，别把锅全甩给数据库。pgvector我劝你先别碰，它做过滤+向量混合查询时的执行计

两卡A100跑Q4量化的8B还能爆显存，感觉问题不在模型本身，而是vLLM的gpu_memory_utilization默认值可能设太高了，它会把大部分显存预留下来做KV cache。你可以先把max_model_len压到2048以内，再把utilization调到0.8试试，2k上下文KV cache其实占不了多少。另外tensor parallel=2对这种小模型反而增加通信开销，单卡跑可能

这个坑我也踩过，后来发现关键是别让它一口气写完整脚本。我一般会拆成两三步：先让它只列依赖和函数结构，确认没问题再让它填具体实现，最后单独要一段带try的异常处理。另外在prompt里明确写“用pandas，只用标准库和pandas”，能少很多缺库的破事。还有个小技巧是让它先输出requirements.txt再写代码，这样它自己会把import理清楚。

我之前也踩过这个坑，问题往往不在prompt写得多细，而是检索片段太碎、上下文里噪音太多。你可以试试把top5压到top3，再给每段标个来源和日期，prompt里明确说“优先用标注最新的内容，冲突时以它为准”。另外“不知道就说不知道”这句真得加，不然模型特别爱自己脑补。模板的话，system写“仅根据提供的资料回答，资料不足时直接说未找到相关信息，不要补充外部知识”，user里把文档编号列清楚再提

中文分块确实是个坑，我前段时间也折腾了好久。你试的256和512其实对中文来说偏小了，中文一个字符承载的信息密度比英文高不少，512 token在中文里差不多能塞下七八百字，语义单元经常跨越这个边界。我现在用的方案是递归分割加自定义separators，把“。”、“；”、“\n\n”放在优先级最高的位置，然后才是“，”和空格，这样至少能保证句子完整。bge-large-zh本身支持512 toke

十万条以上光靠调nprobe确实不够，建议加个reranker先粗召回再精排试试。

几百万条embedding如果不想折腾，pgvector确实够用，过滤和增量更新都天然支持，Docker起个Postgres就完事。但你要是对检索延迟敏感，Qdrant在中等规模下资源占用和过滤性能会明显舒服一些，单机Docker跑也没啥负担。Milvus功能全但组件多，几百万这个量级有点杀鸡用牛刀了。faiss换掉主要是为了增量，这点上pgvector和Qdrant都能省不少心。