为什么用LangChain4J？
LangChain4j 的 AiService 注解式编程（@SystemMessage、@UserMessage、@MemoryId）和 Spring 生态无缝集成； 它提供了模块化RAG比较完整的抽象（ContentRetriever、ContentAggregator、QueryTransformer、QueryRouter、EmbeddingStore），可以在不改动框架的前提下替换实现，相比spring ai的支持要更完整。 但我们也踩过的坑（RRF 去重 bug、全文检索不支持 filter）。
向量数据库用的什么?为什么用这个？
我们用的是 Elasticsearch，不是 Milvus、Pinecone、Weaviate 这类专用向量数据库。这个选型有几个考虑： 第1，我们的场景天然需要"向量 + 全文"双通道检索。汽车知识库的内容有大量精确术语（比如车型代号、故障码、配件编号），这些用向量检索反而可能因为语义泛化而召回不准，BM25 全文检索在这种精确匹配场景下更可靠。ES 天然同时支持 KNN 向量检索和 BM25 全文检索，一套基础设施搞定两件事。如果用 Milvus 做向量、再单独部署一套 ES 做全文，运维成本翻倍。 第2，团队已有 ES 运维经验。在引入 RAG 之前，ES 已经用在其他业务场景里了，不需要额外引入新的中间件。 但 ES 做向量库也有劣势，面试时可以坦诚讲：ES 的向量索引用的是 HNSW，但不像 Milvus 那样支持 IVF_PQ 等多种索引类型和量化策略，在超大规模（亿级向量）场景下性能不如专用向量库。但是其实也够了，我们当前知识库规模在十万级 chunk，ES 完全够用。
Embedding 模型用的哪个？
用的是阿里的 text-embedding-v4（通过 DashScope 兼容 OpenAI 接口调用），向量维度 1536，最大token数8192。 选它的原因主要是：我们的知识库是中文汽车领域内容，阿里的 embedding 模型在中文语义理解上表现比较好；同时 1536 维度和 OpenAI 的 text-embedding-ada-002 对齐，维度不会太高导致存储和计算成本过大，也不会太低损失语义表达能力。 批量写入时 maxSegmentsPerBatch=9，也就是每次 API 调用最多 embedding 9 条文本。这个值是根据 DashScope 的接口限制和实际测试调出来的。
为什么用MinerU，他有啥好处？
我们当时选 MinerU，其实主要是被它‘好用’和‘省钱’这两点打动的。 最开始我们试过用 GPT-4o 或者一些通用的多模态大模型去解析文档，结果发现效果并不理想。像一些复杂的表格、数学公式，或者那种带水印的 PDF，通用大模型经常识别错乱，而且调用 API 的成本太高了，稍微上点量，费用根本扛不住。 后来换成 MinerU 之后，最直观的感受就是它的解析质量特别稳。它好像是专门针对文档版面做了优化的，像跨页表格、公式这些难啃的骨头，它能直接还原成结构化的 Markdown 或者 LaTeX，我们拿来做 RAG（检索增强生成）的时候，切出来的片段质量高了很多，大模型回答的准确率也跟着上去了。 另外对我们工程团队来说，它的落地成本很低。它支持私有化部署，数据不用出内网，合规上完全没问题。 所以总结下来，选它就是因为它在‘解析精度’和‘落地成本’之间找到了一个特别好的平衡点，比调通用大模型 API 划算，比自己去造轮子又省事儿太多了。
Reranker 用 BGE ONNX 本地推理 vs 调 Cohere/阿里云远程 API，为什么？
我们用的是：bge-reranker-v2-m3-ONNX，onnxruntime 1.17.1，JVM 进程内加载， 远程 Reranker API 每次调用增加 100-300ms 网络延迟，RAG 链路本身已经有多次 LLM 调用（意图识别 + 查询改写 + 路由 + 生成），Reranker 的延迟会雪上加霜。 本地 ONNX 推理零网络开销，延迟在 10-30ms 级别。但代价是 JVM 内存占用增大（ONNX 模型加载后占几百 MB）。
为什么要加 Neo4j 图数据库？直接 ES 检索不够吗？
ES 擅长文本相似度匹配，但不擅长关系推理。 比如"Model 3 和 Model Y 共用哪些配件"——这需要沿着 CarModel -[USES_PART]-> Part <-[USES_PART]- CarModel 的路径做图遍历，ES 做不到。再比如"某个配件影响了哪些车型"（反向传播查询），这是图数据库的强项。 但 Neo4j 的引入增加了系统复杂度：需要维护图数据、保证图数据和关系型数据库的一致性、Text2Cypher 的准确率不如 Text2SQL（Cypher 语法对 LLM 来说更陌生）。所以设计了 fallback 机制——Cypher 查不到就降级到知识库检索。
为什么同一个系统用了三种不同的 LLM？
qwen3-30b-a3b-instruct-2507（意图识别 + 查询改写 + 路由 + RAG 生成），qwen3-vl-plus（图片描述），qwen3.5-flash（标题生成）。 不同任务对模型能力的要求不同，用不同模型可以平衡效果和成本。 RAG 生成需要最强的推理能力，用 30B 模型；图片描述是多模态任务，必须用 VL 模型；标题生成是最简单的任务（把一段对话概括成几个字），用最便宜的 flash 模型就够了。如果全部用 30B 模型，标题生成这种简单任务的 API 成本是浪费的。