I really don't like that word for some reason. It's abstracting away something simple. Logs? Graphs? Debug data? Telemetry data? There is way better words for "this".
Show HN: OpenLLMetry – OpenTelemetry-based observability for LLMs
11–20 of 35 posts
Re: Show HN: OpenLLMetry – OpenTelemetry-based observability for LLMs
#12> observability I really don't like that word for some reason. It's abstracting away something simple. Logs? Graphs? Debug data? Telemetry data? There is way better words for "this".
Re: Show HN: OpenLLMetry – OpenTelemetry-based observability for LLMs
#13Re: Show HN: OpenLLMetry – OpenTelemetry-based observability for LLMs
#14Pretty neat! I assume it's just measuring traces right now? Any plans to add some top level metrics like build times, prompt length, etc?
Re: Show HN: OpenLLMetry – OpenTelemetry-based observability for LLMs
#15Re: Show HN: OpenLLMetry – OpenTelemetry-based observability for LLMs
#16Cool! It looks like you effectively do auto instrumentation. Have you found there to be interesting nuances between LLM providers? Tracing is great and trace aggrgegates (with context!) cross-vendor would be even more awesome.
Here are all the semantic conventions we've defined so far - https://github.com/traceloop/openllmetry/tree/main/packages/...
Re: Show HN: OpenLLMetry – OpenTelemetry-based observability for LLMs
#17Observability (AKA, debug/proxy/statistics/logging/visualization layer) -- for LLM's (AKA Chat AI's)...
Hmmm, you know, I would love something for ChatGPT (and other AI chatbots) -- where you could open a second tab or window -- and see (and potentially interact with) debug info and statistics from prompts given to that AI in its main input window, in realtime...
Sort of like what Unix's STDERR is for programs running on Unix -- but an "AI STDERR" AKA debug channel, for AI's...
I'm guessing (but not knowing) that in the future, there will be standards defined for debug interfaces to AI's, standards defined for the data formats and protocols traversing those interfaces, and standards defined for such things as error, warning, hint, and informational messages...
Oh sure, a given AI company could pick a series of their own interfaces, data protocols and how to interpret that data.
But if so, that "AI debug interface" -- wouldn't be universal.
Of course, on the flip side, if a universal "AI debug interface" were ever established, perhaps such a thing would eventually suffer from the complexities, over-engineering and bloatedness that plague many "designed-by-committee" standards in today's world.
So, it will be interesting to see what the future holds...
To take an Elon Musk quote and twist it around (basically abuse it! ):
"Proper engineering of future designed-by-committee standards with respect to AI interfaces and protocols is NOT guaranteed -- but excitement is!"
:-) :-)
Anyway, with respect to the main subject/article/authors, it's a very interesting and future-thinking idea what you're doing, you're breaking new ground, and I wish you all of the future success with your company, business, product and product ideas!
Re: Show HN: OpenLLMetry – OpenTelemetry-based observability for LLMs
#18What do you think is the key differentiator between you and everyone else? Is vendor lock-in really that huge of an issue?
[0] https://hegel-ai.com, https://www.vellum.ai/, https://www.parea.ai, http://baserun.ai, https://www.trychatter.ai, https://talc.ai, https://github.com/BerriAI/bettertest, https://langfuse.com
Re: Show HN: OpenLLMetry – OpenTelemetry-based observability for LLMs
#19Great idea! Observability (AKA, debug/proxy/statistics/logging/visualization layer) -- for LLM's (AKA Chat AI's)... Hmmm, you know, I would love something for ChatGPT (and other AI chatbots) -- where you could open a second tab or window -- and see (and potentially interact with) debug info and statistics from prompts given to that AI in its main input window, in realtime... Sort of like what Unix's STDERR is for pro…
And for that my answer would be that I think having a separate repo would allow this to evolve in a more natural way, and faster (whereas OpenTelemetry, given it's massive adoption already, evolves much slower, with committees etc.).
Then, at some point when this is stabilized and useful - we can merge.
Kind of like Tesla's NACS vs. CCS
Re: Show HN: OpenLLMetry – OpenTelemetry-based observability for LLMs
#20LLM observability strikes me as an extremely, extremely crowded space. And YC has funded an enormous number of them. What do you think is the key differentiator between you and everyone else? Is vendor lock-in really that huge of an issue? [0] https://hegel-ai.com , https://www.vellum.ai/ , https://www.parea.ai , http://baserun.ai , https://www.trychatter.ai , https://talc.ai , https://github.com/BerriAI/bettertest ,…
I do think vendor locking is a key differentiator, which some of the reasons why OpenTelemetry succeeded in the first place. I know that my previous company switched to OpenTelemetry for exactly this reason. You get the flexibility of using any platform you'd want (since we're compatible with OpenTelemetry), so it's not vendor-locking you to a specific platform with specific capabilities. Why use any of the ones you mention - maybe Datadog is enough if your use case is simple?
But there are more advantages - you get much more than just observability to the LLM itself - you can see calls to vector DBs, network calls, DB queries, etc. - this can be extremely useful IMO for RAG and autonomous agents for example