4.1 大模型与AI开发平台

4.1 大模型与AI开发平台

本节摘要：腾讯云的 AI 能力以混元大模型为核心。混元提供可调用的通用 AI 能力——文本生成、对话、代码生成、图像生成等，通过 API 调用即可集成到应用。围绕大模型有三种典型应用模式：最轻的是直接调 API（用通用能力，不加定制）；中等的是检索增强生成 RAG（检索自己的知识库再让模型基于检索结果回答，注入领域知识）；最重的是微调（用自有数据训练改变模型行为）。TI-ONE 则是给需要训练自己模型的团队提供的集成化机器学习开发平台。本节讲这些能力和选型。

学习目标

阅读完本节，你应当能够：

1. 说清混元大模型提供哪些能力，怎么调用
2. 区分大模型应用三种模式（直接调、RAG、微调）的成本和效果
3. 解释 RAG 怎么给大模型注入领域知识
4. 理解微调适合什么场景、代价多大
5. 说清 TI-ONE 平台在 AI 开发流程里的角色

问题与直觉

大模型火了之后，几乎所有团队都在想"怎么用 AI 提升我的产品"。最直接的尝试是调混元（或别的）大模型的 API——把用户输入发给模型，拿回生成的回复。这条路能快速跑通，让产品立刻有"AI 功能"。

但很快会遇到通用大模型的局限：它不知道你公司的内部知识（产品文档、历史工单）、它可能会"幻觉"（编造不存在的事实）、它的语气风格可能不符合你的品牌。比如做一个客服机器人，通用模型不知道你们家的退换货政策，会瞎编一个，闯祸。

解决这个问题的思路从轻到重有三种。最轻的是 RAG（检索增强生成）——把你的知识库做成可检索的，用户提问时先检索相关知识，再把知识塞进给模型的提示里，让模型基于真实知识回答。这能有效减少幻觉、注入领域知识，且不需要训练模型，成本中等。最重的是微调——用你的数据训练模型，改变它的行为（让它学会某种风格、某种领域知识）。微调效果最深但成本最高（要数据、要算力、要迭代）。

选哪种取决于你的问题类型、数据量、预算和团队能力。本节把这三种模式讲透，帮你判断该走哪条路。

核心原理

2.1 混元大模型的能力

混元是腾讯自研的大模型系列，提供多种 AI 能力，通过 API 调用：

调用方式是标准的 API：你的应用发 HTTP 请求（带 prompt 和参数），服务返回模型输出。按调用量（token 数）计费。这种"模型即服务"的模式让你不用自己部署大模型（那要昂贵的 GPU 和复杂的运维），直接用厂商的。

混元的能力覆盖：对话和问答（做聊天机器人、客服）、文本生成（写文案、摘要、翻译）、代码生成（辅助编程）、多模态（图像生成和理解）。能力随版本迭代持续增强。

2.2 大模型应用的三种模式

直接调 API：最简单，写好 prompt 就能用。适合通用任务（通用写作、翻译、摘要）和快速原型验证。局限是模型不知道你的私有知识、行为风格是通用的。优化手段是 prompt 工程——精心设计提示词引导模型输出想要的结果。

RAG（Retrieval-Augmented Generation，检索增强生成）：解决"模型不知道我的知识"的问题。流程是：把你的知识库（文档、FAQ、手册）切块、转成向量存进向量数据库；用户提问时，把问题也转成向量、在向量库里检索最相关的几段知识；把检索到的知识塞进给模型的提示（"基于以下信息回答：[检索到的知识]，问题是：[用户问题]"）；模型基于这些真实知识生成回答。

RAG 的价值：注入领域知识（模型回答基于你的真实文档）、减少幻觉（有依据而非瞎编）、知识可更新（更新文档库即可，不用重新训练模型）。代价是要搭建和维护检索系统（向量库、文档处理管线），且检索质量影响最终效果。

微调（Fine-tuning）：用你的数据进一步训练模型，改变它的行为。适合需要特定风格（让模型用你们品牌的语气说话）、特定领域深度（医疗、法律等专业领域）、或特定任务优化（专门做某个分类或提取任务）的场景。代价高：要准备高质量训练数据、要 GPU 算力、要迭代调优、模型更新后可能要重新微调。

💡 关键直觉：优先考虑 RAG 而非微调。很多团队一上来就想微调，觉得"训练过的才专业"。但微调成本高、迭代慢、且其实不适合注入"事实知识"（微调让模型学会风格，但记不住具体事实）。知识注入用 RAG 更合适——更新知识只要更新文档库。微调留给"改变模型行为模式"的场景（风格、任务格式）。常见组合是 RAG（注入知识）加少量微调（调风格）。

2.3 TI-ONE 开发平台

TI-ONE（腾讯云智能机器学习平台）是给需要训练自己模型的团队提供的开发环境。它覆盖机器学习的完整流程：

数据准备：数据标注（给图片画框、给文本分类）、数据清洗、特征工程。

模型训练：提供训练环境（不用自己搭 GPU 集群）、常用算法库、训练任务管理（提交、监控、调参）。

模型部署：训练好的模型一键部署成 API 服务，提供推理接口。

TI-ONE 适合两类场景：一是传统机器学习（训练分类、回归、推荐模型），二是深度学习（训练视觉、NLP 模型）。对于只想用大模型 API 的团队，TI-ONE 不是必须的（直接调混元 API 就行）；对于要训练自己模型的团队，TI-ONE 省去了搭训练环境的麻烦。

工程实践要点

3.1 RAG 的工程实现

RAG 的效果高度依赖检索质量。几个关键实践：

文档切块策略：文档要切成合理大小的块再向量化。块太大（整篇文档）检索不精确、塞进提示太占 token；块太小（单句）丢失上下文。常见做法是按段落或固定字数（如 500 字）切，块之间有重叠（如重叠 50 字）保证边界信息不丢。

向量模型选择：把文本转向量要用 embedding 模型。模型质量直接影响检索效果。用专门优化过语义的 embedding 模型，比通用模型检索更准。

检索后排序：向量检索召回的候选，再用一个更精细的排序模型（reranker）重新排序，把最相关的排前面。这能显著提升最终送给模型的知识质量。

提示工程：怎么把检索到的知识组织进提示很关键。明确告诉模型"基于以下信息回答，如果信息不足就说不知道"，能减少它脱离知识瞎编。

# 概念性：RAG 的核心流程
class RAGSystem:
    def __init__(self, vector_db, embedding_model, llm):
        self.vector_db = vector_db
        self.embedder = embedding_model
        self.llm = llm

    def answer(self, question):
        # 1. 问题转向量
        q_vec = self.embedder.encode(question)
        # 2. 检索相关知识
        chunks = self.vector_db.search(q_vec, top_k=5)
        # 3. 组织提示
        context = "\n".join(c.text for c in chunks)
        prompt = (f"基于以下信息回答问题。"
                  f"信息不足时回答不知道。\n\n"
                  f"信息：{context}\n\n问题：{question}")
        # 4. 大模型生成
        return self.llm.generate(prompt)
​

3.2 大模型应用的几个坑

幻觉无法完全消除：即使 RAG，模型仍可能幻觉（忽略给的知识、自己编）。对事实准确性要求高的场景（医疗、法律、金融），必须有后置校验或人工审核，别让模型输出直接生效。

上下文长度限制：模型能接受的输入有长度上限。RAG 时如果检索回来太多知识塞不下，要控制检索数量。长对话历史也要做摘要或截断，否则超长。

成本控制：大模型按 token 计费，调用频繁或提示很长时成本累积。监控 token 用量、缓存常见问题的答案、对简单任务用小模型而非大模型，都是控制成本的手段。

延迟：大模型生成有延迟（流式输出 TTFT 几百 ms 到秒级）。对实时性要求高的交互要考虑流式输出和首字延迟优化（参考前面实时 AI 章节）。

3.3 何时该自建而非调 API

调混元 API 是最省事的方式，但有些场景值得自建模型部署：

隐私和合规：数据不能出企业（医疗病历、金融数据），不能发给外部 API。这时要自建模型部署在私有环境。

成本：调用量极大时，API 累计费用可能超过自建。自建要买 GPU、要运维，但有规模效应——量足够大时自建更便宜。

定制化：需要深度定制模型（特定架构、特定微调），API 提供的通用能力不够。这时用 TI-ONE 训练自己的模型、自己部署。

⚠️ 常见坑：过早自建。很多团队量没到就为了"省 API 费"自建大模型，结果 GPU 折旧加运维成本比调 API 还贵，且模型质量不如厂商持续迭代的版本。算清账：自建的固定成本（GPU、运维）要除以实际调用量，只有量足够大单次成本才低于 API。量没到之前，调 API 更经济，还省心。

下一节讲大数据处理和向量数据库，看海量数据怎么处理、向量库怎么支撑 AI 检索。

补一条容易被忽略的工程提醒作为本节尾巴：无论选哪种模式，先建评测集再动手。哪怕只有五十个带标准答案的典型问题，也能让"换提示词、换切块大小、换模型"的每次调整有分数可依。没有评测集的 AI 项目只能靠体感迭代，两周后没人说得清改动是好是坏——这是调 API 时代最便宜也最被忽视的工程纪律，值得在写第一行业务代码之前就落到仓库里。

要点速览

• 混元提供可调用的 AI 能力：文本、代码、多模态，通过 API 集成，按 token 计费。
• 三种应用模式从轻到重：直接调 API（通用）、RAG（注入知识）、微调（改变行为）。
• RAG 注入领域知识：检索知识库+塞进提示，减少幻觉、知识可更新，优先于微调。
• 微调改变模型行为：风格、任务格式定制，成本高、迭代慢，留给真正需要改变行为的场景。
• TI-ONE 给训练自己模型的团队：覆盖数据准备、训练、部署，调 API 的团队不需要。
• RAG 效果靠检索质量：文档切块、embedding 模型、检索后排序、提示工程都要做好。
• 幻觉无法完全消除：高准确性场景要后置校验或人工审核。
• 过早自建是坑：量没到自建比 API 贵，算清固定成本除以调用量的账。

下一节讲大数据处理和向量数据库，看海量数据怎么处理、向量库怎么支撑 AI 检索。