Show HN: Using LLMs and Embeddings to classify application errors (github.com)
Given that there’s a lot of founders/engineers using LLMs in their products, we figured we’d share how we built the new functionality, their impact on our workflows, and how you can try it out.
Our goal was to build two features: (1) tagging errors (e.g. deeming an error as “authentication error” or a “database error”); and (2) grouping similar errors together (e.g. two errors that have a different stacktrace and body, but are semantically not very different).
Each of these rely heavily on comparing text across our application. After some experimentation with the OpenAI embeddings API [3], we went ahead and hosted a private model instance of thenlper/gte-large (an open-source MIT licensed model), which is a 1024-dimension model running on an Intel Ice Lake 2 vCPU machine on Hugging face [4].
Our general approach for classifying/comparing text is as follows. As each set of tokens (i.e a string) comes in, our backend makes a request to an inference endpoint and receives a 1024-dimension float vector as a response (see the code here [5]). We then store that vector using pgvector [6]. To compare any two sets for similarity, we simply look at the Euclidian distance between their respective embeddings using the ivfflat index implemented by pgvector (example code here [7]).
To tag errors, we assign an error its most relevant tag from a predetermined set decided by us. For example, if we tag an error as an "authentication error" or a "database error", we can allow developers to have a starting point before inspecting an issue.(see the logic here [8]).
Anecdotally, this approach seems to work very well. For example, here are two authentication errors that got tagged as “Authentication Error”:
* Firebase: A network AuthError has occurred
* Error retrieving user from firebase api for email verification: cannot find user from uid.
* github.com/highlight-run/highlight/backend/worker.(*Worker).ReportStripeUsage
* github.com/highlight-run/highlight/backend/private-graph/graph.(*Resolver).GetSlackChannelsFromSlack.func1
We have rolled out a first version of the error grouping logic to our cloud product [9], and there’s a demo of all the functionality at [2]. Long-term, if the HN community has other ideas of what we could build with LLM tooling in observability, we’re all ears. Let us know what you think!
Links
[1] https://news.ycombinator.com/item?id=36774611
[2] https://app.highlight.io/error-tags
[3] https://platform.openai.com/docs/guides/embeddings
[4] https://huggingface.co/thenlper/gte-large
[5] some questions: 1. Have you looked into finetuning the embedding model to your use case? 2. Have you considered faster foundation models? 3. How far could you go with this idea? Could this be the basis of a new monitoring platform? Not yet, though this is definitely one of the next steps for us. The `gte-large` model we use is trained on a variety of text, but a hypothesis is one trained or fine-tuned on technical / code-related content may work better. > Have you considered faster foundation models? Any in particular that you would suggest? We're still pretty new to this so would love to learn about other recommendations. Would a foundation model perform as well at this task? > How far could you go with this idea? Could this be the basis of a new monitoring platform? Certainly; there are traditional ML approaches that could be applied to monitoring as well and we're heavily exploring this (ie. for metric anomaly detection). Another area we're exploring embeddings grouping is for filtering ingest to help folks only ingest / retain data that they actually want, but without the overhead of strict filter rules. Tons more to explore in this space, and you will certainly be hearing more from us here. How do you handle the scenario where errors may exhibit evolving characteristics over time, which might potentially impact the effectiveness of the current embedding model? Is there a mechanism for ongoing model adaptation to ensure sustained accuracy and relevance? Lastly, could you envision a scenario where this technology is extended to not only classify, but also to predict potential errors based on historical and real-time data? As for predicting potential errors, this will particularly make sense as an anomaly detection mechanism across metrics and logs. A class of 'important' errors based on the LLM's understand of the error, as well as historical comparison to normal error rates, is something we're exploring with an 'interesting errors' concept - stay tuned for more there! does this get expensive? and these are our customers errors - i was wondering if doing this didn't hurt your units costs too much that said i played with cloudflare's new service since i asked the question and it seems viable10 comments
[ 3.4 ms ] story [ 257 ms ] thread