Langchain Output Parsers
hello! I'm experimenting a bit the integration with langchain and I saw that it does not generate traces for output parsers. Do you have plans to implement that?
19 Replies
Hi Marcos, output parsers should work as expected
See example trace: https://cloud.langfuse.com/project/cloramnkj0002jz088vzn1ja4/traces/d4f5cceb-70a9-4998-9fe3-8c710e7dc1a9?observation=cc983278-cb95-4510-bde4-3221878d4c1d
Example
thx Marc! the callback handler works well with the LLMChain class? that's how I'm creating the chain:
And that's how I'm invoking it:
The tracing looks like this
I'm guessing i have to use LCEL?
yep, that was it...
solved! ๐
thx @Marc ! btw, Is it possible to customize the high level trace name and metadata using the callback handler?
Nice, great that it works when using LCEL
Not sure about the core issue with the previous implementation
Callbacks are not always well-implemented across Langchain depending on how you combine the different abstractions
We're currently simplifying the Langchain callback handler, will include this as well
For the time being, you can createa trace using the Langfuse Python SDK to change name/metadata and then get a langchain handler for this trace
See details here: https://langfuse.com/docs/langchain/python#adding-trace-as-context-to-a-langchain-handler
Langchain integration (Python) - Langfuse
Langchain users can integrated with Langfuse in seconds using the integration
great! thx again @Marc
sure, np
this worked like a charm! ๐
Perfect, thanks for confirming
Hi, I have a quick question regarding this flow of creating
CallbackHandler
(from trace
). I faced with an issue, that no "input" and "output" are produced. Could, you, please, clarify whether this intended behaviour? Because using direct CallbackHandler
creation flow works good. But what I need is to use user_id
and custom trace
is the only way.Do you only want to add the user_id or do you customize the trace also in any other way?
๐ we could just add user_id as an additional constructor argument to CallbackHandler, wdyt @Max
Forgot to answer your questions, This is the intended behavior as this implementation is often used to track multiple chains + custom observations on the same trace. If each chain would update the traces IO, it would not make sense
Alternatively, you can manually set the trace input/output with the users input and the chain output
Not as elegant but also not overly verbose
Hi @Marc , thank you for your answer. Having
user_id
as an extra argument for CallbackHandler
would be a great. In my case it will greatly simplify code without a need of manually update input/output on multiple chains calls within a single session_id
.Makes sense. Do you run a single chain on each user interaction?
No, I'm running two chains one after another during a single user interaction, some kind of
ConversationalRetrievalChain
, but with custom logic, which requires splitting ConversationalRetrievalChain
into two separate chains and independent invokations as well.