原贴链接

我很高兴宣布Arch - 一个开源智能提示网关，它采用（快速）大型语言模型（LLM）构建，用于安全处理提示、强大的可观测性以及将提示与应用程序接口（API）无缝集成以用于智能体用例。https://github.com/katanemo/arch。Arch建立在（并且由其核心贡献者构建于）Envoy代理之上，秉持以下信念：提示是微妙且不透明的用户请求，它需要与传统超文本传输协议（HTTP）请求相同的能力，包括安全处理、智能路由、强大的可观测性以及与后端（API）系统集成以实现个性化 - 所有这些都在业务逻辑之外。Arch采用数十亿参数以下的大型语言模型（LLM）构建，它处理与提示的处理相关的关键但无差异的任务，包括检测和拒绝越狱尝试、智能调用“后端”API以满足提示中表示的用户请求、向上游大型语言模型（LLM）路由并提供故障恢复以及集中管理提示和大型语言模型（LLM）交互的可观测性。核心特性：*基于Envoy构建：Arch与应用服务器一起运行，并基于Envoy经过验证的HTTP管理和可扩展性特性来处理与提示和大型语言模型（LLM）相关的入站和出站流量。*用于快速智能体和检索增强生成（RAG）应用的[函数调用](https://huggingface.co/katanemo/Arch - Function - 3B)。Arch使用其最先进的大型语言模型（LLM）来处理快速、成本效益高且准确的基于提示的任务，如函数/API调用以及从提示中提取参数。*提示[防护](https://huggingface.co/collections/katanemo/arch - guard - 6702bdc08b889e4bce8f446d)：Arch集中提示护栏以防止越狱尝试并确保安全的用户交互，无需编写一行代码。*流量管理：Arch管理大型语言模型（LLM）调用，提供智能重试、自动切换和有弹性的上游连接以实现持续可用性。*基于标准的可观测性：Arch使用万维网联盟（W3C）跟踪上下文标准来实现跨应用程序的完整请求跟踪，确保与可观测性工具的兼容性，并提供指标来监控延迟、令牌使用和错误率，有助于优化人工智能应用性能。

讨论总结

这个讨论围绕开源智能中间件Arch展开。有评论者提出项目以Arch命名可能在搜索结果方面存在问题，也有人认为这个名字很有趣或者很合适。同时，还有关于项目技术方面的疑问，如模型存放位置、硬件要求、是否可使用自有模型等，也有人表达了对项目的兴奋与认可，还有幽默诙谐的评论将其与Arch Linux关联起来，整体氛围积极多元。

主要观点

  1. 👍 项目以Arch命名在搜索结果方面可能存在问题
    • 支持理由：可能与其他内容冲突导致搜索困难
    • 反对声音：无
  2. 🔥 认为Arch作为新开源项目名称很有趣
    • 正方观点：没有给出具体理由只是主观觉得有趣
    • 反方观点：无
  3. 💡 关注模型存放位置和运行的硬件最低要求
    • 这是了解项目运行环境和硬件门槛的基础问题
  4. 💡 对Arch的推出感到兴奋并认可其功能
    • 觉得它能确保运行顺利安全，是提示的智能中间人
  5. 💡 认可项目复用Envoy的功能并关注模型使用的灵活性
    • 复用Envoy功能是明智之举，想知道能否使用自有模型

金句与有趣评论

  1. “😂 Not being mean but why name it Arch? You might have a tough time in the search results…”
    • 亮点：直接指出项目名称可能带来的搜索结果问题
  2. “🤔 Arch is certainly an interesting choice of name for a new open source project”
    • 亮点：单纯从名称角度给出正面评价
  3. “👀 Yo dawg, we heard you like Arch (Linux) so we made Arch so that you could use Arch on Arch”
    • 亮点：利用名字相同制造幽默关联

情感分析

总体情感倾向是积极的。主要分歧点较少，在项目名称方面存在不同看法，有的认为可能存在搜索结果问题，有的觉得有趣合适。可能的原因是大家从不同角度看待项目名称，以及个人的命名习惯和理解不同。

趋势与预测

  • 新兴话题：关于项目使用自有模型的探讨可能会引发后续更多关于项目灵活性和兼容性的讨论。
  • 潜在影响：如果项目得到广泛关注，可能会影响智能中间件领域对于项目命名、功能复用以及与用户自有资源兼容性等方面的考量。

详细内容：

《关于开源智能中间件 Arch 的热门讨论》

近日，Reddit 上出现了一则有关“🚀 Introducing Arch - open source intelligent middle-ware for fast and observable agentic apps”的帖子，引发了众多网友的关注和热烈讨论。该帖子获得了大量的点赞和评论。

原帖主要介绍了 Arch 这一开源智能提示网关，它基于快速的大型语言模型（LLMs）构建，旨在为代理应用程序的提示提供安全处理、强大的可观测性以及与 API 的无缝集成。帖子还提供了相关的链接https://github.com/katanemo/arch。

帖子中提到，Arch 建立在 Envoy Proxy 之上，并阐述了其核心观点，即提示如同传统的 HTTP 请求一样，需要具备安全处理、智能路由、强大的可观测性以及与后端（API）系统集成以实现个性化等功能。

讨论的焦点主要集中在以下几个方面：

首先，关于项目名称“Arch”，有人提出质疑，认为这个名字可能会在搜索结果中造成困扰。例如，有用户说：“Not being mean but why name it Arch? You might have a tough time in the search results…” 而另有人回应称这是一个经过激烈讨论的话题，并考虑是否将项目名称更新为 cli“archgw”。

其次，对于 Arch 项目的一些有趣或引发思考的观点也不断涌现。比如，有人说“Arch Gone Wild, I dig it.”，还有人认为“Arch 是一个有趣的新开源项目名称选择”。

此外，一些用户还关心技术层面的问题。比如，有人询问“where do those models live? Local or cloud? What is the minimum requirement for hardware to run?”，得到的回复是“Arch 可以配置为在本地运行其所有模型（因为它们很小，总共需要 4GB 内存），目前出于速度和性价比的原因，默认 Arch-Function 在云端运行。其他实例如意图检查、越狱检查等在本地运行。”

还有用户关心能否使用自己的模型，得到的答复是可以。

讨论中的共识在于大家对 Arch 这一项目的创新性和潜力都表示了一定的认可，同时也期待其在实际应用中能够发挥出色的作用。

特别有见地的观点如“Totally exciting to see Arch rolling out! It’s like a smart middleman for prompts, making sure everything runs smoothly and securely. The name ‘Arch’ fits since it’s bridging the gap between user requests and backend systems, kinda like an architectural framework.”，丰富了对 Arch 项目的理解。

总的来说，Reddit 上关于 Arch 的讨论展现了大家对这一开源智能中间件的浓厚兴趣和深入思考，也为项目的发展提供了多样的视角和建议。