企业需要一个具有宽松许可和赔偿条款的指令遵循模型。
从 watsonx.ai 目录中选择 IBM Granite instruct 模型，而不是第三方托管模型。
原因: Granite 模型由 IBM 构建和治理，并带有 IBM's 的 IP 赔偿条款 — 这是受监管工作负载的默认安全选择。
最后审核：2026年6月
C1000-185 考试涉及的架构模式快速参考。从头到尾阅读，或跳转到任意章节。
企业需要一个具有宽松许可和赔偿条款的指令遵循模型。
从 watsonx.ai 目录中选择 IBM Granite instruct 模型，而不是第三方托管模型。
原因: Granite 模型由 IBM 构建和治理，并带有 IBM's 的 IP 赔偿条款 — 这是受监管工作负载的默认安全选择。
为单轮提取任务选择聊天优化型或指令优化型变体。
使用带明确指令 prompt 的 instruct 变体；将 chat 模型保留用于多轮对话。
原因: Chat 模型期望角色结构化的轮次；对于一次性任务，instruct 模型更简单、更便宜。
合规报告的输出必须是确定性且可重现的。
将解码设置为贪婪模式（无采样），以便始终选择最高概率的 token。
原因: 贪婪解码消除了随机性；带温度参数的采样会引入在审计输出中不希望出现的变异。
创意文案生成感觉重复且平淡。
切换到采样解码并提高温度（例如 0.7-1.0）以扩大 token 分布。
原因: 更高的温度会使概率趋于平坦，从而选择排名较低的 token，增加多样性。
采样输出偶尔会因稀有 token 而偏离主题。
使用 top-k 或 top-p（核）限制采样，将候选 token 限制为最有可能的 token。
原因: top-k 限制候选数量；top-p 限制累积概率质量 — 两者都能修剪导致漂移的长尾。
模型循环，重复相同的短语或句子。
增加重复惩罚参数，以阻止重新生成最近的 token。
原因: 惩罚会降低已出现 token 的概率；单独的停止序列无法修复生成过程中的循环。
生成内容超出答案，进入幻觉式后续文本。
定义一个或多个停止序列（例如“\n\n”、“###”），以便在已知边界处停止生成。
原因: 停止序列确定性地结束输出；仅依靠最大 token 数量会在句子中间截断。
响应在完成请求的 JSON 之前被截断。
提高最大新 token 数量；在需要时设置最小新 token 数量以强制生成最短长度的答案。
原因: max new tokens 限制输出长度；如果太低，它会在右大括号前截断结构化输出。
零样本分类错误标记了边缘情况。
直接在 prompt 中添加少量带标签的输入/输出示例（few-shot）。
原因: Few-shot 示例在不进行任何调优的情况下，在上下文中设置输出格式和决策边界。
团队希望在编写任何代码之前迭代 prompt。
使用 Prompt Lab — 在自由格式、结构化和聊天模式之间切换，调整参数，然后保存为 prompt 模板。
原因: Prompt Lab 是无代码迭代界面；结构化模式清晰地分离了指令、示例和输入。
长文档超出了所选模型的上下文窗口。
分块并只检索相关段落（RAG），或者从目录中选择上下文更长的模型。
原因: 您不能超过模型的 token 限制；塞入更多文本会导致静默丢弃或错误 — 检索是可扩展的解决方案。
Prompt engineering 在需要一致风格的狭窄领域任务上遇到了瓶颈。
在 Tuning Studio 中运行 prompt tuning，以在带标签的示例上学习软 prompt（调优向量）。
原因: Prompt tuning 在不改变基础权重的情况下调整行为 — 比 fine-tuning 更便宜，比长 prompt 更可靠。
模型缺乏最新的、真实的业务知识。
使用 RAG 将答案基于检索到的文档，而不是根据这些事实调优模型。
原因: Tuning 教授风格/行为，而不是新事实；RAG 注入当前有依据的上下文且易于更新。
为助理级 watsonx 项目决定使用 prompt tuning 还是完整的 fine-tuning。
优先选择 prompt tuning：它训练的参数少得多，运行速度更快，并且是 Tuning Studio 中支持的路径。
原因: 完整的 fine-tuning 成本高昂，需要大型数据集，并存在灾难性遗忘的风险；prompt tuning 是 watsonx 的默认选项。
准备数据以对摘要模型进行 prompt tuning。
以预期的 JSON/JSONL 格式提供输入/输出对，并将其分为训练集和验证集。
原因: 干净、有代表性的数据对驱动调优质量；需要一个保留的验证集来评估泛化能力。
调优损失曲线在早期趋于平坦，而验证损失开始上升。
停止或减少 epoch — 模型开始对训练集过拟合。
原因: 训练/验证损失发散是经典的过拟合信号；更多的 epoch 会导致记忆，而不是泛化。
Prompt tuning 结果在不同运行中不稳定。
调整调优配置中的学习率、epoch 数量、批大小和虚拟 token 数量。
原因: 过高的学习率会使训练不稳定；这些是 Tuning Studio 为收敛而暴露的杠杆。
需要客观比较两个 prompt 或调优资产。
使用任务指标（例如，摘要的 ROUGE/BLEU，提取的精确匹配/F1）加上人工评审进行评估。
原因: 生成质量是多维的；自动化指标可以发现回归，但人工评审可以判断忠实度。
调优模型仍然会编造来源中不存在的事实。
使用 RAG 进行 grounding，降低温度，并指示模型只从提供的上下文中回答或表示不知道。
原因: 幻觉更多是 grounding 和解码问题，而不是权重问题；检索加上约束可以解决大部分问题。
只有几十个带标签的示例可用于调整。
坚持使用 few-shot prompting 或轻量级 prompt tuning；不要在少量数据上进行 fine-tuning。
原因: 小数据集在完全 fine-tuning 下会严重过拟合；在此规模下，上下文示例的泛化能力更好。
为分类任务选择要进行 prompt tuning 的基础模型。
选择 Tuning Studio 支持的、适合任务大小的可调优 Granite 基础模型进行 prompt tuning。
原因: 并非每个目录模型都可调优；调优一个较小的受支持模型更便宜，并且通常足以满足分类需求。
生成式输出质量必须在生产中持续跟踪。
针对部署配置 watsonx.governance 评估指标（质量、漂移、生成式 AI 指标）。
原因: Governance 将一次性评估转化为带警报的监控阈值，而不是手动抽查。
同一个调优 prompt 必须服务于许多具有不同字段的输入。
使用命名变量参数化 prompt 模板，并在推理时提供值。
原因: 变量保持一个可重用模板，而不是硬编码输入，并且它们与 API 参数清晰映射。
模型忽略任务指令，只继续文本。
使用指令优化模型，并将 prompt 构造成一个明确的指令，而不是一个需要完成的片段。
原因: 基础补全模型进行模式延续；指令模型经过训练以遵循指令。
需要跨对象存储数据运行交互式 SQL，用于 AI 特征准备。
在对象存储中的 Iceberg 表上使用 watsonx.data Presto 引擎。
原因: Presto 在开放表格式上提供快速联合 SQL，无需将数据复制到数据仓库中。
分析数据需要在 lakehouse 上进行模式演进和时间旅行。
将其存储为由 watsonx.data 管理的 Apache Iceberg 表。
原因: Iceberg 支持对象存储上的模式演进、快照和 ACID 操作 — 这是 lakehouse 的默认选项。
选择用于繁重 ETL 转换与即席查询的引擎。
使用 Spark 进行大型批处理转换/ETL；使用 Presto 进行交互式、低延迟的 SQL 查询。
原因: Spark 扩展批处理计算；Presto 针对快速联合查询进行了优化 — 根据工作负载类型选择。
RAG 需要一个与受治理数据共存的 embeddings 向量存储。
在 watsonx.data 内部部署 Milvus 作为用于相似性搜索的向量数据库。
原因: Milvus 是 watsonx.data 集成的向量存储；将 embeddings 保留在 lakehouse 中可简化治理。
在 Milvus 和 watsonx Discovery 之间选择检索方案。
使用 Milvus 进行您控制的原始向量相似性搜索；使用 watsonx Discovery（基于 Elasticsearch）进行带混合检索的托管企业搜索。
原因: Milvus 是您操作的向量数据库；Discovery 是一个更高层次的搜索服务，内置了摄取和排名功能。
准备文档，以便基础模型能够基于它们提供答案。
分块文档，使用 watsonx.ai embedding 模型生成 embeddings，并在 Milvus 中对其进行索引。
原因: 检索质量取决于合理的文档分块和匹配的 embedding 模型；维度不匹配会破坏索引。
AI 功能需要分布在多个数据库和存储桶中的数据。
在 watsonx.data 中注册数据源，并通过引擎的联合查询功能直接查询它们。
原因: 联合查询避免了昂贵的数据重复，并保持了单一的受治理访问点。
治理团队要求对模型使用的数据进行血缘和访问控制。
在 watsonx.data 目录中对数据集进行编目，并应用 IAM/基于策略的访问控制。
原因: 受治理的目录是数据血缘与模型事实表（factsheet）关联的基础 — 临时存储桶访问会绕过它。
watsonx.ai 项目必须读取为 RAG 准备的湖仓（lakehouse）表。
向项目中添加 watsonx.data 连接，并将表引用为数据资产。
原因: 连接将受治理的 lakehouse 数据暴露给 AI 项目，而无需导出副本。
一个可用的 Prompt Lab prompt 必须成为可重用、可部署的资产。
将其保存为项目中的 prompt 模板资产，然后将其提升到部署空间。
原因: 部署空间是生产边界；prompt 必须先提升到那里才能被提供服务。
应用程序需要一个用于调优 prompt 的低延迟推理端点。
在部署空间中创建在线部署；它会暴露一个评分/生成 REST 端点。
原因: 在线部署提供同步端点；批处理部署用于离线评分作业。
从 Python 应用程序代码调用基础模型。
使用 watsonx.ai Python SDK 的 ModelInference 类，并使用您的参数调用 generate_text。
原因: ModelInference 将认证、模型 ID、项目/空间和参数封装在一个客户端中 — 比原始 REST 更简洁。
非 Python 服务必须调用 watsonx.ai 推理。
使用模型 ID、输入和参数在 JSON 正文中调用 watsonx.ai 文本生成 REST 端点。
原因: REST API 是语言无关的；SDK 只是对相同端点的封装。
对 watsonx.ai 的 SDK 或 API 调用进行认证。
将 IBM Cloud IAM API 密钥换取 bearer token，然后使用该 token 和您的项目/空间 ID 调用端点。
原因: watsonx 使用 IBM Cloud IAM；在每次调用中嵌入原始 API 密钥或硬编码 token 是错误且不安全的。
决定模型资产在开发阶段和提供服务阶段的存放位置。
在项目中进行开发和实验；将资产提升到部署空间以提供服务。
原因: 项目是协作开发沙箱；部署空间包含提升到生产环境、受访问控制的资产。
将检索和生成连接到一个应用程序流中。
嵌入查询，从 Milvus/Discovery 检索 top-k 分块，将其注入 prompt 模板，然后调用已部署的模型。
原因: “检索-然后-生成”的顺序是答案的基础；首先调用模型会使 RAG 失败。
将 GenAI 工作负载映射到 watsonx 产品系列。
在 watsonx.ai 中构建和调优，在 watsonx.data 中存储/查询数据，在 watsonx.governance 中进行治理和监控。
原因: 这三个组件是互补的，不可互换 — 了解各自的功能是核心考试知识。
企业因数据驻留原因需要在本地部署 watsonx。
将 watsonx 作为软件部署在 Cloud Pak for Data (Red Hat OpenShift) 上，而不是使用 IBM Cloud SaaS 服务。
原因: SaaS 在 IBM Cloud 中运行；软件形式部署在您自己的 OpenShift 集群中，以满足驻留/气隙需求。
组织协作式 GenAI 工作及其工件。
使用 watsonx 项目作为工作区，其中包含数据资产、Notebook、prompt 和共享访问的调优模型。
原因: 项目是协作和资产范围的单位；部署空间是独立的，面向生产环境。
控制哪些人可以访问哪些 watsonx 实例和资产。
使用 IBM Cloud 帐户、资源组和 IAM 访问策略/角色来限定访问范围。
原因: watsonx 中的访问是在帐户/资源组级别由 IAM 驱动的 — 而不是仅仅依靠临时的按资产共享。
估算运行基础模型推理的成本。
计算 watsonx.ai 推理的基于 token 的计费，以及 watsonx.data 中预置的引擎/存储。
原因: GenAI 成本主要由输入/输出 token 决定；lakehouse 和向量存储的计算是单独的计费项。
在 watsonx 上绘制生产 RAG 架构。
湖仓数据 → Milvus 中的 embeddings → watsonx.ai 检索 + 生成 → 应用程序，并在整个过程中由 watsonx.governance 进行监控。
原因: 这种端到端流程是考试要求您识别的典型 watsonx 参考模式。
审计师要求提供已部署模型的生命周期和来源记录。
使用 watsonx.governance AI factsheet 捕获模型元数据、血缘和整个生命周期中的审批。
原因: Factsheet 是 watsonx 模型来源的记录系统 — 它文档化回答了“这个模型从何而来”。
生产模型的输出质量随时间下降。
在部署上配置 watsonx.governance 漂移和质量监控器，设置阈值和警报。
原因: 持续监控可以在用户发现之前捕捉到漂移；一次性验证无法检测部署后的衰退。
必须检查模型是否存在对受保护群体的偏颇对待。
在 watsonx.governance 中运行公平性/偏见评估，并在 factsheet 中记录缓解措施。
原因: 负责任的 AI 义务要求对公平性进行衡量和记录 — 而不是仅仅未经衡量的公平性假设。
合规团队需要将 GenAI 系统映射到 AI 法规。
使用 watsonx.governance 跟踪风险，将控制措施与法规关联，并维护可供审计的证据。
原因: 治理将模型风险与法规控制集中在一个地方，这是审计和 IBM 负责任 AI 原则所要求的。