ChatGPT的Reward模块的可能替代方案

Posted 2023-04-11 CoderOnly

Reward Model 是用 Policy Model 的预测结果 再人工标注 得到的训练数据 训练的，这个训练 Reward Model 数据也可以是text-generation格式的。

替代方案1

Policy Model 的预测结果 再人工标注 得到的（本来给Reward Model的）训练数据 直接用来训练 Policy Model，
把这部分数据 汇入 Policy Model 的训练数据，就能取消 Reward Model 模块了。

替代方案2

Policy Model 的预测结果 再人工标注 得到的（本来给Reward Model的）训练数据 直接用来训练 Policy Model，
把这部分数据 取代 Policy Model 的训练数据，就能取消 Reward Model 模块了。

总结

因为本质我们需要的是优质的text-generation格式的数据而已。

在 Wildfly 中用于模块间服务注入的 OSGI 替代方案是啥？

【中文标题】在 Wildfly 中用于模块间服务注入的 OSGI 替代方案是啥？

【英文标题】：What is the alternative to OSGI for inter-module service injection in Wildfly?在 Wildfly 中用于模块间服务注入的 OSGI 替代方案是什么？

【发布时间】：2013-07-26 10:54:22

【问题描述】：

我们正在解开一个经典的传统单片 EAR 打包 Java EE 应用程序。我们（最复杂的）组件布线模式如下：组件 A“需要”接口 X，而组件 B 和 C (... N) 各自“提供”接口 X。我们的要求是打包和部署 A、B、C和 X 分开独立，以最大限度地减少停机时间并最大限度地减少业务影响。

因此，我们需要必要的稳健性，以允许在运行时删除和添加（重新部署）接口的提供者（B，C），而不需要重新部署接口的消费者（A），也不需要重新启动服务器。该解决方案将在 Wildfly 8 上运行，但只要在 Wildfly 8 上运行，就可以使用其他技术。

我们已经使用 JBoss-OSGI 和 Weld-OSGI 实现了一个 POC，它满足了我们的所有要求，并为我们提供了一个极好的迁移路径。然而，在 Wildfly 8 Alpha 3 中，JBoss-OSGI 已从默认发行版中删除。这让我们认为我们应该探索更符合 Wildfly 背后人们的想法的替代方案。

因此，问题是，在 Wildfly 8 上，有什么替代 OSGI 的模块间服务注入可以满足我们的要求？

为了预算、简单性、性能开销和公司政策，我们不得不取消以下内容： 1。远程 EJB 2。网页服务 3。 JSON/休息 4。 SCA

请注意，这不是要求就 OSGI 的可行性进行辩论，也不是对不同解决方案进行评估或比较。我只是在寻找任何符合我们标准且不基于 OSGI 的解决方案。

【问题讨论】：

我很感激你不想辩论，你说得对，*** 不是辩论的地方。但是……您说 JBoss-OSGi 满足了您的所有要求，并提供了一个极好的迁移路径。需要明确的是，JBoss-OSGi 仍然可用并受到 Red Hat 的支持，尽管现在它是一个可选的附加组件，而不是开箱即用的。所以我真的不明白这个问题的动机。

有效点。是的，JBoss-OSGI 仍然可以作为附加组件使用。但是，Red Hat 的支持是一个更棘手的问题，不包括在 EAP 等之外，这是我首先关心的问题。此外，当 Wildfly 背后的重要人物并没有真正购买它时，在 Wildfly 上使用 JBoss-OSGI 是有风险的。再一次，我不想争论他们观点的有效性，但它存在的事实是使用 JBoss-OSGI 的风险。最后，我觉得我错过了他们为这样的场景实际想到的更明显的解决方案，而且我倾向于用 OSGI 概念思考可能让我对此视而不见。

嘿@ArjanTijms，你真的巡视整个 *** 以确保人们说“Java EE”而不是广泛理解的术语 JEE 和 J2EE？您对命名法和商标的投入令人钦佩，但有点狭隘……我的意思是为什么不将 OSGI 更正为 OSGi？

我想我理解你的推理，虽然我不同意。虽然 Red Hat 的一些人不购买 OSGi，但其他人肯定购买。从核心产品中删除 OSGi 似乎是由一个派系成功推动的，但我相信他们将很难杀死 JBoss-OSGi 附加项目。无论如何...你是客户，Red Hat 不应该关心支持你想做的事情，而不是你试图猜测他们认为你“应该”做什么？

@NeilBartlett 感谢您的评论，是的，我确实尝试过。请注意，SO 本身也将 JEE 和 J2EE 重命名为 Java EE（参见 ***.com/tags/synonyms，过滤例如 JEE）。另请参阅此答案：***.com/questions/17762084/…您对 OSGi 等的看法是正确的。如果我碰巧在同一个句子中发现它们，我偶尔也会尝试改进它们，但我每天只编辑几分钟，不幸的是，在那段时间我只能做这么多。

【参考方案1】：

既然您询问的是 WildFly 背后的人的想法，我将向您推荐以下邮件列表消息。它由 David Lloyd 发布到 Jigsaw 开发列表中，他（我相信）是 WildFly 所基于的 JBoss Modules 的设计师。上下文是关于在 Jigsaw 中引入服务模型的讨论：http://mail.openjdk.java.net/pipermail/jigsaw-dev/2012-February/002161.html

David 似乎在说服务本身的理念 存在缺陷——即您不需要它们！ – 或者 Java 6 中引入的 ServiceLoader API 已经充分解决了该要求。

但是，众所周知，ServiceLoader 不适用于使用类加载器隔离的模块系统，其中包括 OSGi 和 JBoss 模块。这是因为 ServiceLoader 使用类路径扫描，并且在模块系统中没有“类路径”。在 OSGi 中，我们已经指定了一种适配 ServiceLoader 的方法（尽管它很糟糕并且需要字节码转换）。也许 JBoss Modules 也有处理这个问题的方法，但我通过快速扫描他们的文档找不到任何东西。

无论如何，正如我在上面的评论中所说，我对你的动机感到困惑。您显然可以从 OSGi 提供的服务模型中受益，而且 JBoss-OSGi 仍然可用并受到 Red Hat 的支持……那么为什么不继续使用它呢？特别是如果 WildFly 开箱即用并没有明确提供任何您想要的东西。

【讨论】：

非常相关的链接，它澄清了很多。我可以看到 David Lloyd 的发展方向，但在我们的案例中，我实际上认为可以提出一个很好的论据来支持服务理念。并不是说我有那种奢侈，因为它是一个遗留应用程序。请参阅上面关于我的动机的评论。

您能否支持关于红帽仍然可用并支持 jboss-osgi 的说法？据我所知（而且我很长一段时间以来一直在思考这个问题，也得到了 RH 的支持）它从未得到 Red Hat 的支持，只有社区的努力，并且如今甚至没有。此外，它不适用于任何最终版本的 Wildfly（请参阅 this 和 this）OOB，并且负责集成的人员 (Thomas Diesler) 不再是 Red Hat 的员工。

好的，我刚刚注意到这条消息是在 2013 年写的。当时至少有一个想法是支持 JBoss-OSGi，所以这个答案可能在这方面已经过时了。跨度>

【参考方案2】：

Apache Felix 可以作为“OSGI 主机”嵌入到您的应用服务器中。然后您可以为所需的系统创建插件机制。您的所有服务都可以实现为“捆绑”。服务器中的 OSGI 主机可以在部署文件夹中找到捆绑包，并安装/启动它们。然后，您可以在不重新启动应用程序服务器的情况下启用您的 web 服务、rest 和其他服务。

【讨论】：

虽然 Felix 确实是 JBoss-OSGI 的替代品，而且您的解决方案可以很好地工作，但它并不能让我们远离 OSGI。请记住，在这方面，我们正试图将我们的想法与 Wildfly 8 世界保持一致，一个没有 OSGI 的世界。 Wildfly 的 jboss-modules 基础架构提供了许多与 OSGI 相似的功能，因此必须可以在不实际使用 OSGI 的情况下实现某种类似 OSGI 的解决方案。不过，我会把你的建议放在我的待办事项清单上......

'没有 OSGI 的世界'。 Apache Felix 为您提供 osgi 功能，而不是 WildFly。然后您可以使用 IPojo 或等...但是您也想摆脱 OSGI 解决方案，而不仅仅是因为 WildFly 的限制？

正确。请参阅我对 Neil Bartlett 评论的回复以了解我的推理。

【参考方案3】：

在我工作的地方，当 JBoss-OSGi 为 declared dead 时，我们必须选择一些东西才能继续项目。我们采用了 JBoss Modules + EJB 方法，因为它们实际上得到了 Red Hat 的支持。 JBoss Modules 用于静态模块依赖，EJB 用于运行时注入服务。

我们不使用远程 EJB，而是使用 EJB 3.x 本地 EJB，并且您的列表中没有丢弃它，所以我想提供这个是可以的。

【讨论】：

这确实解决了模块间注入的需求，但据我所知，当您注入EJB的接口时，您必须指定实现。这意味着您创建了对特定实现的静态依赖——在我的问题中是 B 或 C。 Neil 提到的 OSGi 和 Java ServiceLoader 框架都提供了一种方法来提供接口的多种实现，并且只在运行时决定使用哪一个。

@AmpieBarnard 嗯。不，您不必指定实现。这就是重点。我们有很多单一接口的实现，您可以更改运行时。

我很难过。请您附上一些代码，其中您有相同接口 X 的两个 EJB 实现（B 和 C），将接口注入 EJB A，部署两个实现，然后在运行时决定使用哪个实现？

我手头没有这样的例子，那是为我的雇主完成的工作。但我看不出需要从哪里指定实现 - EJB 通常基于具有商定名称空间的 JNDI 查找，而不是对实现进行硬编码。

除非指定实现是指指定 JNDI 名称？应该使用可移植的 JNDI 命名空间，而不是与实现类绑定的东西......