feat(llm-observability): add langchain integration

[skoob13]

Problem

Implements a callback handler for LangChain, which can be used as a global or local instance.

Global instance:

callback_handler = PosthogCallbackHandler(posthog_client)
def call_model():
    res = ChatOpenAI().invoke(["Foo"], callbacks=[callback_handler])

Local instance:

def call_model():
    callback_handler = PosthogCallbackHandler(posthog_client)
    res = ChatOpenAI().invoke(["Foo"], callbacks=[callback_handler])

Changes

• Add a handler.
• Reorganize imports so the OpenAI wrapper is now imported as from posthog.ai.openai import OpenAI and the handler as from posthog.ai.langchain import PosthogCallbackHandler.
• Added tests for the integration: the handler supports LangChain>=0.2.0, including new 0.3.0.
• Bumped the Python version on CI to 3.9 because it's the minimum supported version by LangChain. It won't affect users who are not using the AI wrappers.
• Set up setup.py to install optional packages for the integration.

[Twixes]

A few comments, but overall looking solid. Great test coverage

[Twixes]

Why the Python version change? Just wanna be sure we aren't silently dropping older Python versions. Though 3.8 should be fine to drop as it's EoL – we should just be explicit about that event if it happens. (To be honest also surprised we don't use a matrix of Python versions for this Actions job)

[skoob13]

langchain-community requires Python >=3.9, so the CI was failing on 3.8. It is listed under test requirements, so no package will be installed for people not using the AI integration.

[Twixes]

Good catch. For maximum readability would be great to put both openai imports under that try

[Twixes]

Same as with the other openai imports

[Twixes]

The Posthog capitalization really bugs me 😅 But I also see it's what we're already using in the Python SDK. Maybe to avoid the PostHog vs. Posthog inconsistency, we can export just CallbackHandler – same as Langfuse (from langfuse.callback import CallbackHandler)?

[skoob13]

Good call. I followed the Client example, but let's rename it.

[Twixes]

This alias is not super useful, I think just Dict[str, Any] in function signatures might actually be a bit more obvious for SDK users

[Twixes]

Looks like this can be just at the top level of the file, given we're going to be reusing the same logger instance every time

[Twixes]

Idea for simplifying the data model @skoob13 @k11kirky:

Suggested change

	"$ai_output": {"choices": output},
	"$ai_output_choices": output,

this should be just as readable, but with less nesting!

[skoob13]

100% agree, @k11kirky any objections?

[Twixes]

Why not unpack instead?

Suggested change

	"$ai_posthog_properties": self._properties,
	**self._properties,

[skoob13]

I think it makes sense to unpack them since customers and we don't need to unpack nested JSON values. I've followed the data model. @k11kirky what do you think?

[Twixes]

We're missing $ai_request_url – is this metadata we have access to here?

[skoob13]

I haven't seen that one. Let me check; we should have this information.

[skoob13]

base_url is retrievable. However, an actual endpoint URL is tricky. I think the base API URL matters the most, so we can use it for the MVP. Otherwise, we should postpone it for Langchain.

[Twixes]

Looks like the wrong link

[Twixes]

So this will result in lots of persons, as we discussed. Does error tracking do something useful here that we can reuse?

[skoob13]

They explicitly mark the event as personless:

if self._distinct_id is None:
        event_properties["$process_person_profile"] = False

Working on that now.