打造生成式人工智能产品：首先需要了解什么

引言

生成式人工智能虽然容易尝试，但要将其转化为人们可以信赖的产品却难得多。一个团队只需几天时间就能将语言模型连接到聊天界面。但要让该界面能够处理真实的客户请求、遵守访问权限、处理公司数据并从错误回答中恢复过来，则是完全另一回事。

对于考虑将生成式人工智能应用于商业场景的企业而言，首要决策并非选择哪种模型，而是该问题是否真的需要开发一款新产品。现成的AI工具或许能满足大部分需求；而当现有软件无法适应所需的工作流程时，定制化实施方案才更有意义。正在评估后者的企业可咨询SysGears的生成式人工智能工程师，共同探讨围绕其特定用例构建产品的技术要求。

生成式AI产品的开发远不止于将模型置于企业品牌界面之后。模型或许能处理语言，但应用程序的其他部分决定了它能调用哪些信息、能否与其他软件交互，以及当其回答偏离目标时会发生什么。这些决策对产品实用性的影响，与模型选择本身同样重要。

如果内部助手检索到过时的政策文件，可能会误导员工。若允许其访问客户记录，访问权限的重要性便与回答质量同等重要。如果应用程序还能修改记录，那么一个看似合理但实际上错误的回答可能会造成实际损害。

这些绝非发布后可以临时补救的细节。它们影响着系统架构、所需的工程投入以及AI开发成本，包括维持产品运行所需的开销。企业在投入开发之前，应当充分考量这些因素，因为此时仍有空间缩小项目范围，或决定使用现有工具即可满足需求。

从需要生成式AI解决的问题入手

令人信服的演示可能会掩盖一个相当普通的业务问题。例如，如果员工花费过多时间搜索内部文档，一个语义搜索系统可能就足够了。但如果他们需要解读长篇文档、提取具体细节，并利用多来源信息起草回复，那么语言模型或许能提供更实质性的帮助。

这一区别从一开始就至关重要。当软件需要理解杂乱无章的非结构化材料，或起草依赖上下文的内容时，生成式AI才能发挥其价值。然而，对于受固定规则约束的任务，普通脚本通常运行成本更低，也更值得信赖。

以一家需要处理源源不断的产品咨询的分销商为例。客户会用各种各样的方式描述同一件商品，因此生成式AI应用程序可以理解他们的请求，调出相关规格，并起草回复。库存水平则是另一回事。这些数据必须来自实时库存记录，而报价必须遵循公司的定价规则，而不是模型随机的生成结果。

这种分工值得明确：让模型处理语言任务，而可预测的操作则尽可能交给传统软件。

在开始任何开发之前，应明确究竟需要改进什么。销售人员可能需要更少的时间来制作报价单；客户可能无需等待客服人员就能获得答复。无论哪种情况，都要记录当前流程的运作方式。否则，团队可能会为采用新的AI界面而欢呼，却不知道这是否真的让工作变得更轻松。

自建与采购：你实际上需要多少控制权？

“自建”与“采购”的决策通常被视为完全自主权与便利性之间的抉择。实际上，两者之间还有多种折中方案。

当企业需要写作辅助、会议摘要、文档分析或通用研究等常见功能时，现成的AI工具是一个明智的起点。这些产品通常所需的工程工作量较少，且其供应商会处理大部分底层基础设施。企业无需先为专门的开发项目投入资金，即可测试员工是否认为某项功能有用。

问题往往出现在通用工具需要适应其设计初衷之外的工作流程时。例如，它可能无法与旧版数据库对接，或者在员工角色各异时无法应用正确的访问权限。此外，其输出结果可能还需要经过重新处理，才能被其他业务系统所采用。虽然API和配置选项有助于弥合这些差距，但它们未必能完全应对既定工作流程中的特殊情况。

当工作流本身构成竞争优势时，当现有产品无法满足关键需求时，或者当应用程序需要与专有数据和内部系统紧密集成时，定制化AI产品的价值就更加凸显。

第三种选择是围绕外部供应商托管的模型构建自己的应用程序。企业负责开发界面及其背后的逻辑，将系统接入现有软件，并建立自己的结果测试机制。 模型本身是通过API访问的，因此无需从头开始训练基础模型。这为企业提供了根据自身工作流塑造产品的空间，尽管仍受制于提供商的定价、模型可用性以及服务限制。

最后这一点值得关注。开发定制化AI应用与开发新的AI模型是截然不同的两件事。训练基础模型需要大量的计算资源、专业知识、合适的数据以及持续的实验。大多数企业并不需要承担这一负担。一个现成的模型，辅以从公司文档中检索信息或精心设计的工具访问功能，可能就已足够。

围绕工作流程选择架构

一旦商业案例明确，接下来的挑战就是决定应用程序将如何运行。模型只是其中一个组件，而且可能并非耗费最多工程时间的组件。

对于文档助手而言，检索增强生成（RAG）通常值得考虑。该应用不再完全依赖模型在训练期间所学的内容，而是从经批准的信息源中检索相关段落，并将它们纳入提示词中。随后，模型利用这些材料来构建答案。

只要检索功能运作正常，基于内部政策或最新产品信息生成的答案通常更具相关性。但这并非万无一失。检索可能调出过时的文档，遗漏关键的注意事项，或者向模型提供一段被其误读的文本。

检索机制本身也需要经过测试。文档如何被分割成片段会影响系统检索到的内容，而且即使检索结果本身很好，如果它来自用户不应查看的来源，也是毫无用处的。员工的访问权限必须贯穿整个检索过程，而不是因为检索恰好揭示了受限内容而被覆盖。应用程序本身需要强制执行授权。不应信任模型来做出这种判断。

微调则服务于不同的目的。当有合适的训练示例时，它有助于调整模型的行为、响应格式或对重复任务模式的处理方式。但当主要问题在于获取不断变化的事实时，它并不能直接替代检索功能。一个基于去年产品目录微调的模型，不会自动知道今天早上发生了哪些变化。

对于范围狭窄的应用程序而言，至少在初期，一个提示词和一个模型 API 可能就已足够。这取决于输入的可预测性，以及系统预期如何处理其输出结果。如果每个响应都需要与大量内部文档进行核对，检索功能可能就变得必要；而对于更简单的任务，这可能只会增加额外负担。

保持首个版本精简，并用真实请求进行测试，而不仅仅是经过精心打磨的演示输入。观察它如何处理模糊的问题或信息缺失的情况。如果它选择蒙混过关而非承认存在知识缺口，那么在添加更多复杂组件之前，必须先解决这个问题。