yihong0618 和朋友们的频道 头像

消息来源频道

yihong0618 和朋友们的频道

@hyi0618

频道8,612 位成员公开可见0 人在线

yihong0618 和朋友们的频道

成员规模8,612 位成员
在线情况0 人在线
消息总数10,129 条消息
浏览量总数3,285,753 次浏览

在这个频道里搜索消息……

t.me/hyi0618

记一次开源软件的「买椟还珠」
Arch 是一个 LLM API 网关,它基于 Envoy 开发且开发者也来自 Envoy 贡献者,所以作为一个网关软件的品质是有保障的。
https://github.com/katanemo/archgw
Arch 最基本的功能是定义多个 LLM provider, 这样用户只需要根据名称就可以通过同一个 endpoint 来访问。从架构上看,Arch 应当做到支持不同标准的 API (OpenAI, Claude, Gemini) ,但目前只有 OpenAI,且没有相互转换的功能。
Arch 比较亮眼的功能之一是 Prompt Guard, 他们专门训练了一个叫作 Arch-Guard 的分类器模型专门用于对用户输入的 prompt 进行过滤和分析,以保护 LLM 不受攻击。这个功能让应用开发者从这类必要但与产品无关的琐事中解放出来,非常好。
Arch 另一个有趣的功能叫 Prompt Target,可以在配置中定义工具,使得网关本身具备对工具的使用能力。比如定义一个获取货币列表的工具,和一个获取货币之间的汇率的工具,就可以让所对接的任意 LLM 实现回答用户汇率转换问题的能力,无论 LLM 本身是否支持工具调用。
与 Arch-Guard 类似,他们专门训练了一个 Arch-Function 模型,在把用户提示词发给 LLM 前首先用 Arch-Function 处理一遍,如果有工具调用,则先调用工具获得结果,再重新组织提示词发给 LLM。我个人认为这种方式存在一些问题,比如无法干涉工具调用的分析过程,无法引入用户确认工具是否执行的流程,无法用函数等更灵活的方式定义工具等等。我更希望在我的应用中定义 agent 的实现逻辑,让整个流程清晰可控。网关就应该做好 routing, rate limiting, security, transformation, observability 等专长,不用干涉应用本身的逻辑。不过这也的确为快速实现提供了多一个选择,有其价值所在。
回过头来看,Arch 最吸引人的地方并不在于它作为网关的本职功能,而在于它附带的 Arch-Guard 和 Arch-Function 这两颗“珠子”。虽然主打的是 LLM 网关,但真正让我想继续研究的,却是它顺手造出的模型能力。如果说 Arch 是椟,那这些模型或许才是更值得珍视的“珠”。这让我意识到,开源项目中的附加组件,有时反倒蕴含着更大的价值 。