Ollama 不是产品：构建生产级开源大语言模型应用

像 Ollama 这样的工具让本地大语言模型实验几乎毫无摩擦。安装运行时，拉取模型，发送提示，几秒钟内本地助手就会回答。这很有用。但这也是整个旅程中最容易的部分。

终端演示不是应用。本地模型不是产品。一个高效的开源大语言模型应用需要受控的数据摄取、检索、权限、评估、日志记录、提供商抽象、部署纪律，以及解决实际业务问题的用户工作流。

核心论点很简单：Ollama 是运行时，不是产品。产品存在于模型周围的应用层。该层决定了哪些文档可见、哪些块被检索、使用哪些提示、如何评估答案、如何记录失败，以及系统在日常工作中是否值得信赖。

这就是本地 AI 对于构建私人助手、内部知识工具、基于大语言模型的 SaaS 功能或企业工作流副驾驶的团队变得有趣的地方。模型可以在本地运行，但隐私、可靠性和商业价值只有在整个系统被正确设计时才存在。

Ollama 是运行时，不是产品

Ollama 在本地运行和服务开源模型方面表现出色。它尤其擅长探索、开发者工作流、概念验证，以及希望在不立即承诺使用云提供商的情况下测试模型行为的团队。它通过 API 和兼容层暴露本地模型交互，使得连接现有的 OpenAI 风格工具更加容易。

这并不意味着 Ollama 解决了应用问题。它不会自动知道用户可能阅读哪些公司文档。它不会创建租户隔离、文档版本控制、审计追踪、来源归属、评估数据集或特定于业务的 UI 工作流。这些责任仍然属于应用架构。

• Ollama 帮助解决：本地模型执行、快速实验、基于 API 的模型访问、离线优先的概念验证以及开发者生产力。
• Ollama 本身不解决：访问控制、RAG 质量、文档生命周期、租户边界、评估、审计日志、监控、回退行为或企业工作流设计。
• 架构错误：将本地推理视为已经是安全的 AI 产品。

模型是最容易的部分。应用层才是产品价值所在。— 架构原则

演示、概念验证和生产是不同的阶段

许多开源大语言模型项目失败，是因为团队将可用的演示与生产能力混淆。区别并非表面上的。每个成熟度级别都有不同的目标、不同的风险概况和不同的工程要求。

概念验证可以有意识地小规模。生产不能有意识地盲目。一旦真实用户、私有数据、业务决策和合规期望进入系统，架构必须变得明确。

RAG 的定位

检索增强生成是连接语言模型与私有业务知识最常见的桥梁。模型不会神奇地知道内部文档、合同、工单、产品规格或运行手册。应用必须在要求模型回答之前检索相关上下文。

一个实际的 RAG 流程如下所示：

1. 文档从受控源上传或同步。
2. 文本被提取、清理并分割成块。
3. 块接收元数据，如租户、所有者、文档版本、来源 URL、访问范围和时间戳。
4. 为每个块生成嵌入。
5. 向量存储在 pgvector、Qdrant 或其他检索层中。
6. 查询时，应用在检索前检查权限。
7. 通过相似性搜索和元数据过滤器检索相关块。
8. 提示构建器将选定的上下文注入模型请求。
9. 生成带有引用、置信度边界以及在检索较弱时无答案回退的答案。

RAG可以减少幻觉，但无法完全消除。糟糕的分块策略、薄弱的元数据、缺失的权限过滤器、低质量的嵌入或过于宽泛的检索，仍然可能产生令人信服但错误的答案。严肃的RAG系统需要阈值、引用、检索日志和评估。

实用的本地开源大语言模型架构

一条现实的生产路径并不需要特殊的基础设施。对于许多团队来说，一个强大的初始架构可以使用常规的Web栈：Nuxt作为前端，Nitro或Node API作为后端，PostgreSQL作为记录系统，pgvector用于检索，Ollama作为本地运行时，Prisma用于数据访问，以及后台工作进程用于数据摄取和嵌入。

用户问题 | v
前端界面 | v
API / 后端 | +--> 身份验证 +--> 租户和角色权限检查 | v
检索层 | +--> PostgreSQL元数据 +--> pgvector或Qdrant向量搜索 +--> 相似度阈值 | v
提示构建器 | +--> 系统提示 +--> 检索到的文本块 +--> 来源引用 +--> 无答案规则 | v
大语言模型提供者抽象层 | +--> Ollama / 本地模型 +--> 云端模型备用 +--> 未来自托管运行时 | v
带来源的答案 | v
日志、追踪、指标、评估数据集

这种架构保持了模型的可替换性。Ollama可以作为第一个运行时，但系统不应锁定在单一推理引擎上。清晰的架构将用户工作流、检索、提示构建、模型提供者和可观测性分离开来。

• 前端：Nuxt或其他Web界面，用于经过身份验证的用户工作流。
• 后端/API：Nitro、Node.js或FastAPI，用于编排、权限和提供者路由。
• 数据库：PostgreSQL，用于文档、用户、租户、角色、提示、日志和元数据。
• 向量搜索：pgvector用于简单的集成检索，或当向量搜索成为专用服务时使用Qdrant。
• 模型运行时：Ollama用于本地执行，llama.cpp服务器用于轻量级服务，或vLLM用于更高吞吐量的GPU服务。
• 存储：本地文件系统或兼容S3的对象存储，用于上传的文件和提取的工件。
• 工作进程：后台数据摄取、分块、嵌入、重新索引和文档版本处理。
• 可观测性：日志、指标、提示追踪、检索追踪、延迟跟踪和评估结果。

生产就绪检查清单

以下检查清单是本地模型演示与可用开源大语言模型应用之间的区别：

• 每个文档和文本块都有tenant_id。
• 在检查用户和角色权限之前，检索被阻止。
• 文档包含元数据、来源、所有者、版本、生命周期状态和保留策略。
• 分块策略已记录并针对真实文档进行了测试。
• 嵌入模型的选择是明确的并且有版本控制。
• 向量索引配置是可重现的。
• 相似度阈值防止弱上下文被盲目使用。
• 答案尽可能包含来源引用或来源参考。
• 当检索置信度过低时，使用无答案回退。
• 提示模板有版本控制并受发布管理。
• 从一开始就构建大语言模型提供者抽象层。
• 结构化输出在下游使用之前经过验证。
• 评估数据集包含真实问题、预期来源和不可接受的答案。
• 检索日志显示每个答案使用了哪些文本块。
• 监控延迟、令牌使用量、GPU/CPU负载和错误率。
• 隐私和保留规则涵盖上传、提取的文本、文本块、嵌入、提示、响应和日志。
• 部署、备份、恢复、回滚和事件处理路径已记录。

这与企业交付操作系统直接相关：有用的人工智能不仅仅是模型决策。它关乎交付纪律、证据、控制、指标和运营所有权。

提供者抽象：不要绑定单一模型

本地模型对于隐私敏感用例、离线场景、成本控制和内部实验非常有价值。云端模型在复杂推理、编码、多语言准确性或多模态任务方面可能仍然更强。生产应用不应将任何单一模型视为永久基础设施。

提供者抽象允许相同的应用工作流调用Ollama、OpenAI、Gemini、Anthropic、Mistral、vLLM或其他自托管端点，而无需重写产品。应用根据用例、数据敏感性、延迟、成本和质量要求来决定提供者。

type LlmProvider = "ollama" | "openai" | "gemini" | "anthropic" | "vllm"; type ChatInput = { provider: LlmProvider; model: string; tenantId: string; userId: string; question: string; context: Array<{ chunkId: string; sourceTitle: string; text: string; }>;
}; async function chat(input: ChatInput) { await assertUserCanAccessContext(input.userId, input.context); const messages = buildRagMessages({ question: input.question, context: input.context, rules: [ "Answer only from provided context when possible.", "Cite source titles.", "Say when the context is insufficient." ] }); return llm.chat({ provider: input.provider, model: input.model, messages, trace: { tenantId: input.tenantId, userId: input.userId, promptVersion: "rag-v3.2" } });
}

关键思想不是TypeScript语法。关键思想是边界。应用拥有权限、检索、提示规则、追踪和评估。提供者只产生模型输出。

pgvector vs Qdrant

对于许多开源大语言模型应用来说，向量存储的决策在开始时很简单：如果PostgreSQL已经是你的记录系统，pgvector是一个很好的起点。它将元数据、权限、文档记录和向量紧密地结合在一起。这降低了操作复杂性。

Qdrant在向量搜索需要成为专用服务时变得更有吸引力：更大的检索规模、高级过滤、专门的索引、混合搜索模式或检索基础设施的独立扩展。

一个实用的原则：当PostgreSQL已经承载了你的业务数据且检索规模适中时，从pgvector开始。当向量搜索本身成为产品能力时，迁移到Qdrant。

安全与隐私的现实考量

本地推理并不自动意味着安全的AI。它只意味着模型执行可以在本地进行。完整的数据路径仍然重要：上传的文件、提取的文本、分块、嵌入、日志、提示、响应、备份、开发者访问、管理工具和分析导出。

嵌入向量也需要谨慎对待。它们不是原始文档，但仍然表示从敏感内容中派生出的信息。将它们视为受保护数据路径的一部分，特别是当它们与元数据、源记录、用户查询或租户标识符关联时。

• 在访问规则明确之前，不要索引文档。
• 在没有租户和角色过滤器的情况下，不要检索分块。
• 在没有保留规则的情况下，不要记录完整的提示和响应。
• 除非策略允许，否则不要将敏感上下文发送到云端模型。
• 不要假设本地等于符合GDPR；合规性取决于完整的处理设计。
• 不要让评估和调试副本成为不受控制的影子数据集。

这就是多实例SaaS架构重要的地方。如果租户、角色、数据所有权和运营边界薄弱，添加本地LLM可能会放大风险而非降低风险。

评估不是可选项

一个生产级的Open-LLM应用需要一个评估循环。没有它，团队只能依赖轶事。几个好的演示答案并不能证明检索有效、提示稳定，或者模型在实际使用中行为安全。

一个最小的评估数据集应包括真实的用户问题、预期的源文档、不可接受的答案、无答案的情况，以及针对先前失败的回归测试。每次对分块、嵌入、提示、模型提供商或检索阈值的更改，都应针对该数据集进行测试。

• 检索评估：系统是否获取了正确的源分块？
• 答案评估：答案是否基于检索到的上下文？
• 安全评估：系统是否避免了禁止的披露或未经授权的数据访问？
• 运营评估：延迟、失败率和成本是否保持在可接受范围内？
• 回归评估：模型或提示升级是否破坏了之前正确的行为？

RAG减少了幻觉，但并未消除评估的必要性。评估是将聪明的原型转变为不断改进产品的控制循环。

部署纪律：模型即发布事件

更换模型不是无害的配置调整。它可能改变答案风格、推理行为、语言质量、延迟、令牌使用、引用纪律和故障模式。在生产环境中，模型升级应像发布事件一样处理。

这意味着要对提示、嵌入模型、检索设置、模型标识符、提供商路由和评估结果进行版本控制。同时也要有回滚逻辑。如果新模型导致基于检索的答案变差或结构化输出中断，系统需要一条可控的路径回到已知良好的配置。

这符合交付与变更和AI就绪平台架构相同的运营逻辑：稳定的交付需要可重复的控制，而非英雄式的手动修复。

结论：生产始于演示结束之处

Ollama可以开启旅程。它使本地模型执行变得可访问，并降低了实验的门槛。这很有价值。但生产应用始于演示结束之处。

模型只是一个可替换的组件。真正的产品是围绕它的受控系统：摄取、权限、检索、提示、提供商路由、评估、日志、监控、部署、备份和用户工作流。这就是隐私变得真实、质量变得可衡量、商业价值变得可重复的地方。

一个严肃的开放LLM应用是通过工程纪律构建的，而不是通过运行一次本地模型。Ollama可以启动旅程，但生产应用从演示结束的地方开始。

主题：

Ollama, 开放LLM, RAG, pgvector, Qdrant, 本地AI, LLMOps, 提供商抽象, 企业AI架构