企业内部 RAG 知识库私有化方案

内部 RAG 知识库私有化方案

面向场景：第三方医疗器械检测机构，业务员/内部员工需要基于公司已有知识（报价、检测标准、SOP、FAQ）检索提问，获得准确、可溯源的答案。文档定位：从「该不该自己搭」「脱敏走 API 可不可行」到「买什么显卡、怎么部署」的完整论证与落地笔记。整理自面试备战讨论。

一、需求背景

第三方医疗器械检测机构（CNAS/CMA/GLP），服务 6000+ 企业，业务涉及生物相容性、加速老化、灭菌验证、无尘洁净室检测等。

业务员会面对不同客户的大量提问（报价、周期、送样要求、资质、检测标准等），希望：

把公司已有知识（报价单、合同、检测标准、SOP、FAQ）放入一个知识库；
能对知识做拆解、分块；
业务员提问时，能基于已有知识输出准确答案（而非让模型自由发挥）。

这本质上就是 RAG（检索增强生成）知识库问答。

二、核心争论：自己买卡 vs 走云端 API？

问题提出

想搭 RAG 知识库供内部员工检索。最初判断：可能要自己买显卡、搭大模型接口，因为调用大模型公司的 API 会存在信息泄露问题。

这个判断对吗？—— 一半对，需要修正

对的部分（保留）：检测机构数据极敏感（客户送检器械、材料配方、检测结果、商业机密），受 GLP / CNAS / 客户保密协议约束，绝不能出内网。

把知识库文档发给云端 API = 把客户数据交给第三方，是合规事故。数据安全的意识是加分项。

要修正的部分：不能把"知识库私有化"和"大模型私有化"混成必须一起做的一件。RAG 系统要分层看：

知识库本身（文档 + 向量库）：必须完全内网私有（这一层是底线，用户判断正确）；
大模型推理这一层：有 3 种落地方式，不是只有"买显卡"一条路（见下表）。

方案

怎么做

数据安全

成本/维护

适用

全私有化

本地买 GPU，部署开源模型（Qwen/DeepSeek）+ 本地向量库

完全不出内网，最安全

高（买卡+运维+调优）

强合规、预算足

本地向量库 + 云端大模型 API

知识库/向量检索留内网，只把「问题+召回片段」发云端

中（片段仍是知识内容，有风险）

低

预算有限、敏感度可控

混合

敏感数据走私有，非敏感走 API

中高

中

多数企业实际做法

初步结论：检测行业强合规，倾向本地部署开源模型 + 本地向量库；而非一律买显卡，应按合规和预算分级选型。

三、我的关键质疑：脱敏 + 云端 API 为什么不可行

针对「本地向量库 + 脱敏后调云端 API」这条路，逐条论证它为什么在检测行业是伪命题：

质疑 1：字段级脱敏 → 查询意义丧失

做法：把客户名、公司名、产品型号、配方、价格、联系方式替换成泛化值。
反驳成立：业务员问"这个客户这批器械报价多少"，脱敏后云端拿到的是"某客户某器械报价××"，答了个寂寞。
本质：脱敏越干净越没信息，越不脱越泄露——结构性矛盾，无法两全。

质疑 2：白名单过滤 → 总有遗漏

做法：命中敏感字段的片段直接拦下不发。
反驳成立：安全领域铁律——规则匹配永远有漏（没写到的字段、变形的写法、藏起来的信息）。检测行业合规是"零容忍"，不是"尽量"，只要有遗漏 = 不安全。规则脱敏在强合规面前本质不可行。

质疑 3：最小化发送 → 无法量化、不精准

做法：只发最相关的 1-2 个片段。
反驳成立："最小化"是拍脑袋的模糊概念：剪多少算最小？剪多召回缺、答案不准；剪少等于没剪。既无法度量，也无法保证效果，不是工程上能"可信执行"的方案。

质疑 4：天长地久，数据一点一点外泄

最狠、最对的一条：任何"允许敏感数据出内网"的机制，哪怕每次只漏一点，累积就是慢性失血，且无法追溯哪一次漏了、无法举证合规。
对要过 GLP/CNAS 审计的机构，这是一票否决。

结论

既然检测机构的数据安全是零容忍、脱敏走 API 又不靠谱，这条路就该排除。核心敏感业务必须本地私有化——本地跑开源模型 + 本地向量库，数据完全不出内网。GPU 成本是强合规的必要安全成本，不能省。

最终收敛：可行路径 = 本地私有化部署（而非脱敏折中）。

四、买什么样的显卡（重点）

核心铁律：显存大小决定能跑多大参数的模型

买卡前先定模型，反推显存，再选卡。

显存估算公式：

模型权重 ≈ 参数量 × 每参数字节数

FP16（全精度推理）：约 2GB / 10亿参数

INT8（量化）：约 1GB / 10亿参数

INT4（量化）：约 0.5GB / 10亿参数 再加约 1.2 倍余量（KV cache + 激活值）。

常见模型所需显存（估算）

模型参数量

FP16

INT8

INT4

内部知识库问答够不够

7B（Qwen2.5-7B）

~14GB

~7GB

~4GB

小团队够用

14B（Qwen2.5-14B）

~28GB

~14GB

~8GB

中团队推荐 ✅

32B

~64GB

~32GB

~18GB

更准、量大用

70B+

~140GB

~70GB

~40GB

需多卡/大显存

以上为估算值，实际以模型官方页为准。

具体建议

一张 48GB 专业卡（如 A6000 / L20 / L40S）即可，跑 14B 模型，几百人内部并发没问题。
不用一上来就顶配：按业务规模选，避免过度投资。

为什么推荐专业卡而非游戏卡

维度

专业卡（A6000/L20/L40S）

游戏卡（RTX 40/50）

显存

48GB

24GB（少量 32GB）

ECC 内存

支持（数据更稳）

不支持

驱动

稳定，适合 7×24 长期推理

游戏向，长跑易过热

适用

企业级长期服务

个人/开发测试

企业级场景优先专业卡。

五、从 0 到 1 部署全流程

Step 1 · 装环境（顺序：驱动 → CUDA → Docker）

装 NVIDIA 显卡驱动：官网按型号下载，装完 nvidia-smi 验证（能看到显卡型号和驱动版本）。
装 CUDA：GPU 运算工具包，装与推理引擎兼容的版本（一般 CUDA 12.x），nvcc --version 验证。
装 Docker + NVIDIA Container Toolkit：强烈建议用 Docker 部署（CUDA/推理引擎/模型一键打包、可复现）。装 nvidia-container-toolkit 后，验证：docker run --gpus all nvidia/cuda:12.x nvidia-smi。

一句话：驱动 → CUDA → Docker(GPU 版)。用容器隔离环境，最省心、最可复现。

Step 2 · 部署开源模型（两种方式按场景选）

方式 A：Ollama（最省事，先跑起来/小规模）

# 1. 装 Ollama
curl -fsSL https://ollama.com/install.sh | sh
# 2. 拉一个中文模型（Qwen 通义千问）
ollama pull qwen2.5:14b
# 3. 启动，自动加载到 GPU
ollama run qwen2.5:14b

自动 GPU 加速，并提供 OpenAI 兼容接口（http://localhost:11434/v1），后端 Java 直接调。

方式 B：vLLM（生产级，高并发——推荐！！！！）

docker run --gpus all -p 8000:8000 \
  vllm/vllm-openai:latest \
  --model Qwen/Qwen2.5-14B-Instruct \
  --gpu-memory-utilization 0.9

启动后提供 OpenAI 兼容接口（http://localhost:8000/v1），Java 后端照常调。

选型：先跑通、人少 → Ollama；上生产、人多并发 → vLLM。 两者都提供 OpenAI 兼容接口，后端对接一致。

Step 3 · 接成 RAG（让模型基于知识库回答）

单有大模型只会"瞎编"，要让它基于知识库回答，加两层：

本地 Embedding + 本地向量库（Milvus / Chroma）：把报价、标准、FAQ 切分、向量化、存本地向量库，数据完全不出内网。
检索 → 拼 Prompt → 调本地模型：员工提问 → 向量检索召回相关片段 → 拼进 Prompt → 调本地大模型 → 生成带引用的答案。

完整链路：员工提问 → 本地检索（召回报价/标准片段）→ 拼进 Prompt → 本地大模型（Qwen 14B）→ 基于知识库回答 → 返回业务员。全程不出内网。

六、本方案的沉淀价值

体现了「数据安全 + 行业合规」意识；
体现了「会做架构分层权衡」（分清知识库层 vs 模型层）；
体现了「对脱敏方案的反驳论证」（字段脱敏/白名单/最小化三者的不可行）；
体现了「能落地」：从选卡（显存估算）到装环境到部署到接 RAG 的全链路。

PS：

一、FP16 / INT8 / INT4 是什么？（先搞懂"精度"和"量化"）

核心概念：大模型的参数（权重）是一堆小数，需要用"字节"来存储。每个数用多少字节存，就是"精度"。 位数越多越精确，但也越占显存。

精度

每个数占几位/几字节

存 1GB 参数约需显存

效果

FP32

32 位（4 字节）

~4GB

最精确，但最大最占显存（训练常用）

FP16

16 位（2 字节）

~2GB

半精度，"全精度推理"一般指它（精度损失极小，速度/省显存兼顾）

INT8

8 位（1 字节）

~1GB

量化，更省显存，精度略降但基本可用

INT4

4 位（0.5 字节）

~0.5GB

深度量化，最省显存，精度有可感知下降

"全精度推理"：就是用 FP16（或 FP32）存权重，精度损失最小，但显存占得多。 "量化"：就是把 FP16 的权重压缩成 INT8/INT4，用更低精度存——省显存、可能加速，代价是精度略降、答案可能没那么"精细"。

一句话：精度越高越准但越占显存，量化越狠越省显存但越"糊"一点。选哪个 = 显存够不够 + 答案要多准的权衡。

为什么通常推荐 FP16 而不是更省显存的 INT8/INT4？因为 14B 在 48GB 卡上 FP16（~28GB）放得下，就没必要量化——保证答案质量第一。只有当显存放不下 FP16 时才去量化。所以显存越大，越能"不量化、保质量"。

二、选什么卡

RTX A6000 48GB 全新卡，市场参考价约 3–4 万元人民币。

中关村在线成都渠道报价：约 ¥38,499（2026-09 行情）1；
部分批发/渠道（Made-in-China）：约 US$2,000–4,000 / 张（约 1.5 万–3 万）2；
注意：价格波动很大，二手卡、渠道货会明显更便宜，全新正规渠道约 3 万多。实际采购以前价格和正式报价为准。

给个量级参考（方便你讲"为什么值得买"）：

方案

一次性成本

后续成本

买卡（本地私有化）

约 3–4 万（一次性）

电费/运维，无按量费

调云端 API

几乎零门槛

按 token 持续付费，量大了很可观 + 合规风险

具体讲这三张卡分别多少钱（核实行情）

显卡

厂商

显存

市场参考价（2026 行情）

定位

RTX A6000

NVIDIA

48GB

全新约 3–4 万（中关村渠道 ¥38,499）1

专业工作站卡（Ampere 架构，老一代）

Tesla L20

NVIDIA

48GB

全新约 2.4–2.7 万（京东 ¥24,199，商家 ¥20,144–27,000）2

数据中心推理卡（Ada 架构，新一代，性价比高）

L40S

NVIDIA

48GB

全新约 6 万左右（京东 ¥6 万）3

数据中心全能卡（Ada 架构，渲染+推理都强）

注意：批发/二手渠道价格波动很大（Made-in-China 有更低批量价），以上是全新正规渠道的参考行情，实际采购以正式报价为准。

怎么选？（这三张都是 48GB，都能跑 14B）

既然三张显存一样（都 48GB），区别在架构代次 + 价格 + 算力：

A6000

L20（推荐）

L40S

架构

Ampere（老一代）

Ada（新一代）

Ada（新一代）

价格

3–4 万

2.4–2.7 万（最便宜）

6 万（最贵）

定位

工作站

数据中心推理专用

渲染+推理全能

对"纯 RAG 知识库问答"

够用但偏贵

够用且最划算 ✅

性能最强但溢价

给科标这种"内部知识库问答"场景的结论：

"三张 48GB 都能跑 14B 模型、都够几百人并发。如果只做 RAG 知识库问答（偏纯推理、不做渲染），L20 性价比最高（约 2.4–2.7 万）——它是数据中心推理专用卡，价格最便宜、功耗也更低。A6000 老一代偏贵不划算；L40S 渲染强但 RAG 用不上那份渲染算力，6 万属于过度投资。所以内部知识库问答，我建议 L20 优先，预算充足再考虑 L40S。"

一句话给你定心：

"L20 / L40S / A6000 全是 NVIDIA 的 48GB 企业卡，都够跑 14B、都够几百人并发；区别是 L20 新一代又最便宜（约 2.4 万），最适合纯 RAG 问答；A6000 老一代偏贵，L40S 贵在渲染算力、RAG 用不上。"

一句话论证"这笔钱该花"：对检测机构，客户数据泄露是合规事故（一票否决），本地私有化 3–4 万买的是"数据永远不出内网"的安全底线。它是必要安全成本，不是可省的开销。

三、为什么 48GB 就够几百人并发？（关键，讲明白这个你面试就立住了）

这是最容易讲虚、也最值得讲透的一点。核心在**"并发不复制模型"**：

① 模型权重在显存里只放一份（常驻）

14B 模型 FP16 约 28GB，装进显存后，这份权重是"大家共用的一份"——不管你 1 个人问还是 500 人同时问，用的都是同一份已经放进显存的权重。并发再多，模型本体也不会重新占一份。

② 每个请求只额外占"一小块"（KV cache + 中间计算）

每次推理除了用共享的权重，还要临时存"这次对话的上下文"（叫 KV cache）和计算中间量。这部分每个请求独立、但很小（几 MB 到几十 MB 量级，取决于输入长度）。

③ 所以能并发几个 = （总显存 − 模型权重）÷ 每个请求的额外占用

48GB − 28GB（模型权重）= 约 20GB 给所有并发请求共享。每个请求就算占 20–40MB，也能同时容纳几百个请求的上下文。这就是"48GB 够几百人并发"的根本原因。

④ 配合 vLLM 的"连续批处理"

vLLM 这种生产级引擎，能把多个请求打包成一批在 GPU 上同时算（批处理），把 GPU 算力用满——并发越高、吞吐越高，而不是排队干等。

一句话总结：

"48GB 够几百人并发，因为模型权重只放一份（28GB），剩下的 20GB 分给几百个请求的上下文绰绰有余；再配合 vLLM 批处理把 GPU 算力用满。并发瓶颈通常不在'同时能接多少人'，而在'每秒能出多少 token'——而 48GB 的专业卡这个吞吐足够内部几百人用了。"

把三个点串起来，你面试能一气呵成：

"精度分 FP16/INT8/INT4——FP16 最保质量但占显存，量化省显存但糊一点；48GB 卡放得下 14B 的 FP16，就不用量化。A6000 一张约 3–4 万，是强合规下的必要安全成本。至于为什么够几百人并发——模型权重只放一份，剩下的显存分给各请求的上下文，配合 vLLM 批处理，吞吐足够。"

企业内部 RAG 知识库私有化方案

内部 RAG 知识库私有化方案

一、需求背景

二、核心争论：自己买卡 vs 走云端 API？

问题提出

这个判断对吗？—— 一半对，需要修正

三、我的关键质疑：脱敏 + 云端 API 为什么不可行

质疑 1：字段级脱敏 → 查询意义丧失

质疑 2：白名单过滤 → 总有遗漏

质疑 3：最小化发送 → 无法量化、不精准

质疑 4：天长地久，数据一点一点外泄

结论

四、买什么样的显卡（重点）

核心铁律：显存大小决定能跑多大参数的模型

常见模型所需显存（估算）

推荐显卡分档

具体建议

为什么推荐专业卡而非游戏卡

五、从 0 到 1 部署全流程

Step 1 · 装环境（顺序：驱动 → CUDA → Docker）

Step 2 · 部署开源模型（两种方式按场景选）

Step 3 · 接成 RAG（让模型基于知识库回答）

六、本方案的沉淀价值

一、FP16 / INT8 / INT4 是什么？（先搞懂"精度"和"量化"）

二、选什么卡

具体讲这三张卡分别多少钱（核实行情）

怎么选？（这三张都是 48GB，都能跑 14B）

三、为什么 48GB 就够几百人并发？（关键，讲明白这个你面试就立住了）