私有 LLM 部署：企业的实用 RAG

私有 LLM 部署与检索增强生成提供可审计、领域准确的答案，同时保持数据在您的周边内。 本指南为工程和产品团队提供了一条紧凑而实用的路线，从模型选择到安全 RAG 管道、评估和最小化生产蓝图。

选择符合约束条件的模型和嵌入

选择一个满足您的延迟、成本和许可约束的模型。 最近的开放权重列表如 Leafy.dev 和 PocketLLM 显示了从小型 7B 模型到 70B 系列的广泛范围；较小的模型降低了托管成本，并使本地推理成为现实，而较大的模型则改善了开箱即用的推理。 对于索引和运行时，使用相同的供应商或 L2 兼容的嵌入模型，以避免向量漂移。 我们观察到，为静态文档预先计算嵌入大约能将查询延迟减少一个前向传播的时间，并简化回滚过程。

安全的向量存储和隐私技术

对于许多少于 500 万个向量的团队，嵌入式 Postgres 和 pgvector 是一个操作上简单的默认选择，而管理服务如 Pinecone、Weaviate 和 Milvus 则以更高的成本和专业功能交换较低的操作要求。 Inductivee 和 Tensoria 基准讨论了 100 万到 1 亿向量数据集的吞吐量和成本差异，表明选择依赖于向量大小、每秒查询次数（QPS）以及是否需要多区域复制。

在静态情况下加密向量，并为密钥使用信封加密。 对向量存储应用严格的 IAM，并要求所有服务连接使用 mTLS。 有关威胁建模和红队指导，请咨询我们的 LLM 安全手册 LLM security playbook。 如果您需要正式的隐私保证，请在我们的教程中查看差分隐私选项和安全聚合 differential privacy techniques。

我们在实践中遇到的一个问题是配置错误的服务帐户暴露了向量元数据。 将元数据视为高敏感性，并在与向量相同的控制后面进行锁定。

衡量相关性、幻觉、延迟和成本

使用检索指标如 Hit@k、MRR 和 NDCG 进行检索，并使用参考评估和无参考评估框架如 RAGEval 和 RAGAS 来评估完整性、幻觉和无关性。 RAGEval 和 RAGAS 为领域任务提供情景特定的测试，并建议自动 LLM 作为评估的依据。 监控三个生产信号：检索精度、答案可信度和尾部延迟。 在实践中，提高检索器的召回率往往比增加模型规模更有效地减少幻觉现象。

私有 LLM 部署的蓝图

最小蓝图：在 VPC 后容器化模型服务，一个具有锁定网络 ACL 的独立向量存储集群，一个发出短期令牌的认证代理，以及一个能够记录检索 ID 和答案的可观察性堆栈，以进行审计。 从单区域 VPC 托管的模型开始，以保证延迟可预测性，且只在必要时添加跨区域复制。 小规模部署的固定成本会更高，但控制和隐私会更好。

显而易见的反对意见是供应商创新。 云托管的 LLM 服务将更快发展，并且在摊销工程成本时可能会更便宜。 我估计：对于每月查询量超过几百万的持续高查询量，托管推理在总拥有成本上往往胜出。 然而，对于受监管的数据或严格的驻留规则，私有部署是唯一可行的选择。

试试看：下面的两个提示展示了如何揭示基础及检测不支持的陈述。

这个提示要求模型使用提供的上下文回答查询，并列出其使用的源 ID。 期待简洁的答案和源引用。

给定以下带有 ID 的上下文片段，回答用户问题，并包括您使用的前三个上下文 ID 的编号列表和每个 ID 的确切引用证据。
上下文 1 [id=C1]："..."
上下文 2 [id=C2]："..."
用户问题："解释 X 并引用支持的三个片段。"

这个提示要求模型在自己的答案中标记不支持的主张。 期待一个简短的列表，其中每个句子标记为是否有支持，并提供支持的上下文 ID（如可用）。

您生成了这个答案。 对于每个句子，标记它是否完全由提供的上下文支持，并给出支持的上下文 ID，或标记为不支持。
答案："..."
上下文：C1，C2，C3

我们观察到，采用检索参数进行的小型可重复实验会发现可信度最大的改善。 保持评估的可重复性，并将检索 ID 与答案一起记录，以进行根本原因分析。