PostHog实战教程：5分钟给你的AI应用接入可观测性分析

为什么你的AI应用需要可观测性

你花了几百美元的API费用，但你真的知道这些调用都去哪了吗？哪些提示词在浪费token？哪些用户遇到了糟糕的AI回复？

PostHog的AI可观测性模块可以回答这些问题。本教程将带你用Docker在本地部署PostHog，接入一个简单的AI应用，并在5分钟内看到第一条可观测数据。

第一步：用Docker部署PostHog

最简单的启动方式是使用官方提供的Docker Compose配置：

# 克隆仓库
git clone https://github.com/PostHog/posthog.git
cd posthog

# 启动所有服务（PostgreSQL、Redis、ClickHouse等）
docker compose -f docker-compose.dev.yml up -d

# 等待服务就绪（约30秒）
docker compose ps

启动成功后，访问 `http://localhost:8010` 完成初始化设置。注册一个管理员账号，创建你的第一个项目——记下 Project API Key，后面会用到。

生产环境建议使用PostHog Cloud（免费额度够小团队用），本教程使用本地部署方便测试。

第二步：安装PostHog SDK

在你的AI应用项目中安装PostHog的Python SDK：

pip install posthog

如果你的应用使用Node.js：

npm install posthog-js

第三步：接入AI可观测性

PostHog的AI可观测性基于LLM调用追踪。每次你的应用调用OpenAI（或其他LLM API）时，PostHog自动记录输入、输出、token消耗和延迟。

from posthog import PostHog
from posthog.ai.openai import OpenAI

# 初始化PostHog
posthog = PostHog(
    project_api_key='你的Project API Key',
    host='http://localhost:8010'
)

# 使用PostHog封装的OpenAI客户端（替代原生openai）
client = OpenAI(
    api_key='你的OpenAI API Key',
    posthog_client=posthog
)

# 正常调用——PostHog自动追踪！
response = client.chat.completions.create(
    model="gpt-4",
    messages=[
        {"role": "system", "content": "你是一个乐于助人的AI助手。"},
        {"role": "user", "content": "解释一下什么是强化学习？"}
    ]
)

print(response.choices[0].message.content)

如果使用其他LLM提供商（如Anthropic），导入对应的封装：

from posthog.ai.anthropic import Anthropic

client = Anthropic(
    api_key='你的Anthropic API Key',
    posthog_client=posthog
)

第四步：查看可观测数据

回到PostHog Dashboard（`http://localhost:8010`），你会在左侧菜单看到 AI Observability 模块。点击进入后可以看到：

– 总调用次数和token消耗：今天烧了多少钱一目了然

– 延迟分布图：哪些调用慢得离谱？

– 单次调用详情：完整的prompt/response内容、每一步的token数

– 错误率追踪：API返回429（限流）或500（服务器错误）的频率

第五步：设置告警

可观测性的价值在于主动发现问题。在PostHog中配置一个简单的告警：

# 当单次LLM调用延迟超过10秒时触发事件
posthog.capture(
    distinct_id='system',
    event='llm_slow_call',
    properties={
        'latency_seconds': response.usage.total_tokens / 10,  # 模拟逻辑
        'model': 'gpt-4',
        'threshold_exceeded': True
    }
)

然后在PostHog的 Actions 中基于这个事件创建Webhook通知，发送到Slack或钉钉。

进阶玩法

熟悉基础操作后，可以尝试这些进阶技巧：

按用户分组分析：通过 `posthog.identify()` 关联用户ID，分析不同用户群体的AI使用模式——谁在用你的AI功能？用得最多的用户有什么特征？

A/B测试你的prompt：使用PostHog的Feature Flags为不同用户组推送不同的系统提示词，用真实数据判断哪个版本效果更好。

# Feature Flag：控制prompt版本
prompt_variant = posthog.feature_enabled('new-system-prompt', user_id)

if prompt_variant:
    system_msg = "你是一个热情且富有创造力的AI助手。"
else:
    system_msg = "你是一个乐于助人的AI助手。"

成本归因分析：如果你的产品有多个AI功能，给每个功能打上标签，月末一眼看出哪个功能最”烧钱”。

常见踩坑与解决方案

在实际使用中，几个常见的坑需要注意：

坑1：忘记关闭PostHog客户端导致内存泄漏

如果你的应用是长期运行的服务（如FastAPI），确保在应用关闭时调用 `posthog.shutdown()`：

import atexit

posthog = PostHog(project_api_key='...', host='...')
atexit.register(posthog.shutdown)

坑2：生产环境中自托管的维护成本

虽然Docker部署很方便，但生产环境中PostHog依赖多个服务（PostgreSQL、Redis、ClickHouse、Kafka），维护成本不低。对于小团队，建议先用PostHog Cloud的免费额度（每月100万事件免费），验证需求后再决定是否自托管。

坑3：AI可观测性数据量的控制

每次LLM调用都会记录完整的prompt和response。如果你的prompt很长（比如包含大量上下文），事件体积会很大。建议在PostHog的SDK配置中设置采样率：

posthog = PostHog(
    project_api_key='...',
    host='...',
    # 只捕获10%的详细调用数据
    feature_flags_request_timeout_ms=3000,
)

PostHog的强大之处在于它模糊了”产品分析”和”AI可观测性”的界限。你不需要两套工具、两个Dashboard——用户行为和AI调用在同一个平台上关联分析，这才是AI时代产品迭代的正确姿势。

— END —
LC 智趣厅 · 科技与生活的交点
ihygg.cn