[HN Gopher] Show HN: Arch - an intelligent prompt gateway built ...
___________________________________________________________________
Show HN: Arch - an intelligent prompt gateway built on Envoy
Hi HN! My name is Adil Hafeez, and I am the Co-Founder at Katanemo
and the lead developer behind Arch - an open source project for
developers to build faster, generative AI apps. Previously I worked
on Envoy at Lyft. Engineered with purpose-built LLMs, Arch handles
the critical but undifferentiated tasks related to the handling and
processing of prompts, including detecting and rejecting jailbreak
attempts, intelligently calling "backend" APIs to fulfill the
user's request represented in a prompt, routing to and offering
disaster recovery between upstream LLMs, and managing the
observability of prompts and LLM interactions in a centralized way
- all outside business logic. Here are some additional key details
of the project, * Built on top of Envoy and is written in rust. It
runs alongside application servers, and uses Envoy's proven HTTP
management and scalability features to handle traffic related to
prompts and LLMs. * Function calling for fast agentic and RAG
apps. Engineered with purpose-built fast LLMs to handle fast, cost-
effective, and accurate prompt-based tasks like function/API
calling, and parameter extraction from prompts. * Prompt
guardrails to prevent jailbreak attempts and ensure safe user
interactions without writing a single line of code. * Manages LLM
calls, offering smart retries, automatic cutover, and resilient
upstream connections for continuous availability. * Uses the W3C
Trace Context standard to enable complete request tracing across
applications, ensuring compatibility with observability tools, and
provides metrics to monitor latency, token usage, and error rates,
helping optimize AI application performance. This is our first
release, and would love to build alongside the community. We are
just getting started on reinventing what we could do at the
networking layer for prompts. Do check it out on GitHub at
https://github.com/katanemo/arch/. Please leave a comment or
feedback here and I will be happy to answer!
Author : adilhafeez
Score : 27 points
Date : 2024-10-10 17:45 UTC (5 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| sparacha wrote:
| Hey HN - my name is Salman and I am Adil's Co-Founder. Would love
| to hear and get feedback. Here is a link to our public roadmap,
| please lets us know if there are things you'd like for us to work
| on first
|
| https://github.com/orgs/katanemo/projects/1
| adilhafeez wrote:
| You can also see current list of issues at
| https://github.com/katanemo/arch/issues, and can also post new
| feature requests and bug fixes there.
| lionkor wrote:
| Hi, I'm curious how preventing jailbreaks protects the _user_?
|
| > Prompt guardrails to prevent jailbreak attempts and ensure safe
| user interactions [...]
| adilhafeez wrote:
| Jailbreak ensures a smooth developer experience by controlling
| what traffic from user make its way to the model. With
| jailbreak (and other guardrails soon to be added) developers
| can short-circuit response and with observability developers
| can get insights on how users are interacting with their APIs.
| sparacha wrote:
| That's a fair point - technically it protects the application
| from malicious attempts to subvert the desired LLM experience.
| The more specific language (and I think we could do better
| here) would be that Arch ensures users remain within the bounds
| of an intended LLM experience. That at least was the intention
| behind "ensure safe user interactions"...
| debarshri wrote:
| Lately, I have seen few gateways around LLM. Namely, openrouter,
| portkey.ai, etc.
|
| My key question is, who would be the ideal customer who would
| need a proxy or a gateway like this? Why couldn't it be an
| extension or plugin of existing LBs, proxies etc.
| sparacha wrote:
| Two things
|
| 1/ Arch builds on Envoy so that we don't re:invent all the
| HTTP(s)/TCP level capabilities needed in a modern gateway for
| applications. So in that sense, we agree with you that it
| should "extend" something vs. rewriting the whole stack. There
| are several security and robustness guarantees that we borrow
| from Envoy as a result of this. To be more specific, a lot of
| Arch's core implementation today is an Envoy filter written in
| Rust.
|
| 1/ Arch's core design point is around the handling and
| processing of prompts, which we believe are nuanced and opaque
| user request that require secure handling, intelligent routing,
| robust observability, and integration with backend (API)
| systems for personalization - all outside business logic. This
| requires the use of models and LLMs that are fast, cheap and
| capable to help developers stay focused on application
| features. For example, Arch uses (fast) purpose-built LLMs for
| jailbreak detection, converts prompts into API semantics for
| personalization, and (eventually) automatically routing to the
| best outbound LLM based on the complexity of a prompt to
| improve the cost/speed of an app.
|
| We believe #2 will continue to be different and evolve further
| away from traditional API/HTTP routing that it will require
| constant invention and work to make the lives of developers
| easy.
|
| Hope this helps!
| edude03 wrote:
| Envoy is legendary in (dev)ops circles, but I don't understand
| what it lends to the AI space. I feel like building a separate
| backend service that runs behind envoy would make more sense but
| that's just me.
| crb wrote:
| Tetrate and Bloomberg want to contribute their code to Envoy to
| create "Envoy AI Gateway", similarly to how there is an "Envoy
| Gateway" spec. Do you see this as being complementary or
| competitive with your work?
|
| https://tetrate.io/press/tetrate-and-bloomberg-collaborate-o...
___________________________________________________________________
(page generated 2024-10-15 23:01 UTC)