今天，我们将重点探讨对接的业务逻辑。为了帮助大家更直观地掌握其中的规律性，我将通过对比OpenAI与《月之暗面》中的Moonshot两个案例来阐述这一点。通过这样的对比，大家可以更清晰地看到，这些对接业务的整体框架其实非常相似。换句话说，我们要做的工作只是其中的一小部分，但它同样是关键的一环。
好了，接下来我们就开始深入了解这个话题。
模型对接
我们首先需要找到关键的 model 类，所有的具体逻辑实际上都集中在这里。从这部分代码入手，我们可以对比一下两者之间的差异。通过观察，我们会发现，实际上这段代码的结构和写法几乎是固定的，遵循了一定的模式。所有的对接解析逻辑都封装在那些被折叠的部分中。如图所示：
OpenAI方法中的第二个参数实际上也是自适应的，主要用于其内部实现，具体细节将在后续内容中进一步讲解。需要强调的是，这个参数并非强制性的，是否使用取决于具体接口的需求和实现方式。至于流式处理，它与其他常见方法基本相似，具体实现细节可以参照以下示意图：
这段代码的主要目的是通过 OpenAI API 进行聊天请求，处理响应并构建最终的 ChatResponse 对象。它还包含了对工具调用的处理逻辑，允许递归调用以处理复杂的对话场景。
参数解析
可以看到方法内部还是有很多参数的，我们简单看下。
- prompt：这个并不是我们常说的一段人设文本，而是外层Chatclient带回来的参数封装成了prompt对象而已。
- PROVIDER_NAME：模型公司的名字，一个字符串，如：openai、ollama、moonshot等
- CHAT_MODEL_OPERATION：一个枚举类主要用来实现接口的默认方法。通过记录一些信息帮助开发者分析和监控聊天模型的行为。
- observationConvention：客户自定义的观测数据，这里默认为DEFAULT_OBSERVATION_CONVENTION。
- observationContext：用于存储和管理聊天模型交换的元数据
- observationRegistry：和观察相关，但默认是不观察。
剩下的基本都是很简单的理解了。和工具调用有关，暂时不分析。
详细说下DEFAULT_OBSERVATION_CONVENTION类，它主要用于为聊天模型操作生成观测数据（如名称、低基数和高基数键值对）。具体功能如下：
- 获取观测名称：返回默认的观测名称。
- 生成上下文名称：根据请求模型生成上下文名称。
- 生成低基数键值对：包括AI操作类型、提供者、请求模型和响应模型。
- 生成高基数键值对：包括请求和响应的各种参数，如频率惩罚、最大令牌数等。
总结
通过对OpenAI与《月之暗面》中Moonshot案例的对比，我们可以清晰地看到，尽管每个业务对接的实现有所不同，但其整体框架和逻辑结构却高度相似。无论是在模型选择、参数解析，还是流式处理的实现上，都遵循了相同的基本模式。这些对接过程中的每一个小细节，虽然看似琐碎，但它们在整个系统中发挥着至关重要的作用。
我是努力的小雨，一个正经的 Java 东北服务端开发，整天琢磨着 AI 技术这块儿的奥秘。特爱跟人交流技术，喜欢把自己的心得和大家分享。还当上了腾讯云创作之星，阿里云专家博主，华为云云享专家，掘金优秀作者。各种征文、开源比赛的牌子也拿了。
💡 想把我在技术路上走过的弯路和经验全都分享出来，给你们的学习和成长带来点启发，帮一把。
🌟 欢迎关注努力的小雨，咱一块儿进步！🌟
