在实际 AI 大模型应用开发中，我们常常面临一个核心矛盾：一个绝佳的创意（Idea）与将其稳定、高效、规模化实现所需的基础设施（Infra）之间，存在着巨大的鸿沟。许多团队在模型选型、算法调优上投入大量精力，却忽略了支撑整个训练、评估、部署流程的底层工程体系，这直接导致了实验难以复现、迭代效率低下、资源浪费严重，最终让好的想法停留在纸面。OpenAI 在推进如 RLHF（Reinforcement Learning from Human Feedback）等复杂技术时，其强大的基础设施能力被认为是关键成功因素之一。而国内开源社区推出的“天授”等框架，也正是在尝试填补这块基建空白。本文将从工程实践角度，探讨如何构建服务于大模型应用（特别是类似金融问答机器人这类复杂场景）的可靠基础设施，涵盖从模型高效微调、RAG 增强到服务化部署的全链路关键设计。
本文适合正在或计划将大模型技术落地到具体业务场景的 AI 应用开发工程师、算法工程师以及技术负责人。我们将以一个“金融大模型问答机器人”项目为蓝本，但重点不在于复现一个具体的问答界面，而在于剖析其背后支撑快速迭代和稳定服务的Infra 哲学。你将了解到如何系统性地设计技术栈，如何将 SFT、LoRA、RAG、量化等技术点串联成可运维的流水线，以及如何借鉴 OpenAI 等团队在工程化上的最佳实践，避免陷入“有想法，无铲子”的困境。
1. 理解“基建哲学”：为什么 Idea 需要 Infra 来承载
在 AI 项目，尤其是大模型项目中，“基建”远不止是服务器和网络。它是一套完整的工程体系，确保从数据准备、模型训练、评估验证到服务部署、监控运维的每一个环节都可靠、高效、可复现。
1.1 从 OpenAI RLHF Infra 看工程化挑战
OpenAI 并未完全公开其 RLHF 基础设施的全部细节，但从其论文、博客和开源社区的逆向工程中，我们可以窥见其面临的工程挑战，这些挑战在我们的项目中同样存在：
- 大规模分布式训练：动辄千亿参数的模型，需要在数百甚至数千张 GPU 上并行训练，涉及复杂的模型并行、数据并行、流水线并行策略，以及梯度同步、通信优化等问题。
- 复杂流水线编排：RLHF 包含预训练、有监督微调（SFT）、奖励模型训练、强化学习（PPO）等多个阶段，每个阶段依赖前一个阶段的产出，且需要管理海量的中间状态和检查点。
- 数据管理与版本化：用于 SFT 的指令数据、用于奖励模型训练的人类偏好数据，都需要严格的版本控制、去重、质量校验和 lineage 追溯。
- 实验管理与复现性：任何算法或超参数的调整，都必须能精确复现实验环境、代码版本、数据和训练过程，以进行科学的对比分析。
- 成本与资源效率：GPU 资源极其昂贵，基础设施需要最大化利用率，支持弹性伸缩、任务排队、抢占式调度，并对训练和推理成本进行精细核算。
这些挑战决定了，如果没有一套强大的基础设施，RLHF 这类复杂技术几乎不可能从研究论文走向稳定可用的产品。我们的“金融问答机器人”项目虽然规模可能较小，但同样需要应对数据流水线、多阶段训练、服务部署、效果评估等系统性工程问题。
1.2 “天授”框架的启示：开源社区的基建尝试
“天授”（Tianshou）是一个基于 PyTorch 的强化学习库，以其模块化、高性能和良好的文档著称。虽然它主要聚焦于强化学习算法本身，但其设计哲学体现了优秀的基建思维：将算法逻辑与环境交互、数据收集、模型存储等基础设施解耦。开发者可以像搭积木一样组合不同的策略、网络和环境，而底层的数据流和训练循环由框架稳定地负责。 对于我们的项目，这种“解耦”和“模块化”的思想至关重要。我们需要构建的 Infra，其目标也是将数据预处理、模型微调、知识检索、服务接口等模块标准化，让开发者的精力集中在业务逻辑和算法改进上，而不是重复编写数据加载、分布式训练启动脚本或 HTTP 服务包装代码。
1.3 金融问答机器人的基建需求分析
假设我们的项目目标是构建一个能准确、可靠地回答用户关于理财产品、市场规则、投资风险等问题的机器人。其核心基建需求可以分解为：
- 数据层：处理非结构化的金融文档（PDF、Word、网页），进行清洗、分割、向量化，并构建可快速检索的向量数据库。
- 训练层：支持对选定的大模型（如 Qwen）进行高效的监督微调（SFT），可能涉及参数高效微调技术（如 LoRA），以及后续的奖励模型训练和强化学习优化（如 PPO/GSPO）。
- 推理/应用层：提供稳定的 API 服务，能够接收用户问题，协调检索增强生成（RAG）流程，调用微调后的模型生成回答，并处理流式输出、上下文管理等。
- 评估与运维层：建立自动化的效果评估 pipeline（如回答准确性、相关性、安全性），监控服务 API 的延迟、吞吐量和错误率，并支持模型的平滑更新与回滚。
接下来，我们将围绕这些层次，构建一个具体可操作的基建方案。
2. 项目基建设计与核心组件选型
在开始写代码之前，明确的技术选型和架构设计能避免后期的推倒重来。我们基于“模块化”和“可复现”的原则进行设计。
2.1 整体架构图（概念层面）
[用户请求] | v [API 网关 / FastAPI 服务] <--- 处理认证、限流、路由 | v [应用编排层 (LangChain/自定义)] <--- 协调 RAG、模型调用、后处理 | | |----------------------------- | | v | [向量数据库 (Chroma/Weaviate)] | ^ | | v | [大模型服务端点] | (本地部署的 Qwen 微调模型 或 | 兼容 OpenAI API 格式的代理) | ^ | | | [知识库文档] --> [文档处理流水线] --> [文本嵌入模型] [离线部分] | v [训练与评估流水线] (SFT/LoRA/PPO 训练、量化、评估)2.2 核心组件与技术栈详解
| 组件层级 | 推荐技术选型 | 选型理由与备注 |
|---|---|---|
| 大模型 (LLM) | Qwen(通义千问) | 优秀的开源中文大模型，对金融领域知识有一定基础，支持上下文长度长，社区活跃。作为基座模型。 |
| 应用框架 | LangChain/LlamaIndex | LangChain 提供了丰富的 Chain、Agent、Tool 抽象，适合快速构建复杂应用。LlamaIndex 更专注于 RAG 场景，对数据连接器和索引构建有深度优化。两者可结合使用。 |
| 后端服务 | FastAPI | 异步高性能，自动生成 API 文档，与 Python AI 生态无缝集成，是包装大模型服务的理想选择。 |
| 向量数据库 | Chroma(轻量) /Weaviate(功能全) /PGVector(与 Postgres 集成) | 存储文档向量，支持高效相似性检索。Chroma 简单易用；Weaviate 自带向量化模块和过滤功能；PGVector 适合已用 Postgres 的团队。 |
| 嵌入模型 | BAAI/bge-large-zh-v1.5或text2vec | 优秀的中文文本嵌入模型，将文档和问题转换为向量，用于检索。 |
| 高效微调 |
