本文记录自己在 D 产品和 C 产品里做过的数据分析，原本在2025年10月22日记录了 D 服务的分析笔记，随着我的数据分析经验被老板发现，又分析了 C 服务，以此留念一下。

旨在回答：什么样的用户，在什么场景下，想用我们的产品完成什么复杂度的任务，以及他们的行为有什么特征，使用感受如何。

当然，我没有办法把公司数据拿出来，这里只是记录一下分析方法。

D 服务

N-gram、高频内容和请求略读

首先，我做了一些简单 N-gram 分析，这一步主要是为了画一个词云，呈现一个酷炫的汇报画面。剩下的词频可以给我们一个初印象。

在这个初印象里，代码相关问题（出现大量行号代码片段）、以及检视意见、分析出现的频率相对很高，同时还发现了偷偷接我们 D 服务的人（或者内部团队）有很多视图绕过我们自己的 system prompt 的请求。 对 D 服务 web 端用户，高频词大多能确认与研发相关，但单一定位具体任务，而且领域相关知识查询很多、领域也很杂。 不过没有出现因为是 API 的调用就被几个特定领域主导的情况。

Top k Query and Query Bigrams

不过这种短语很难推断完整、具体场景的。因此我截取了定长前缀中最高频的请求（通常是接入服务的定式 user prompt 中的一部分）， 确实能看到大量设计工单内容分析、产品翻译、事务组织、代码审计等具体业务问题，并且很多研发部分都会有代码、MR相关的请求。

• 对 Web 端用户来说，则是有很多测试、翻译、格式转换等大量偏非研发业务的请求。不过前缀带公司coptright的请求也很多，应该有很多人是开头粘贴代码然后问点什么的。同时也发现很多人发”你好”，很神奇。
• 对 API 部分，去重后的前缀计算频率得到的结果有较大区别，代码问答、检视、错误修复相关依然是较高使用场景； 不过粘贴完整日志、代码、DSL的请求开始明显出现。特定领域的信息提取与问答占比也开始提升。

主题建模

当然我做了一下老本行 LDA 进行主题聚类。这个主题分类模型把原本我们有的不完全分类标签（一般问答、服务调用）或问答、作业下的耳机标签进一步以具体语义无监督地分为五类。 这个分类不是我直接手动分的，而是依然使用了 D 服务的实际请求进行聚类。

考虑到我们关系模型结果的可用性，也就是模型生成的主题是否可以被看懂、是否有意义的同时考虑模型的泛化能力， 即对未见语料困惑度最低的模型。对 perplexity(372.53) 和 coherence(0.78) 网格搜索后选择可解释性和质量更好的主题数 k = 5。

主题相对正交。$lambda=1$（主题内关键词分布普遍与主题唯一管理）时，主题分布的内容没有较大重叠。

大概自己解释了一下：

• #1 - 检视意见
• #2 - 文本分析或者信息提取
• #3 - 代码审计和问答
• #4 - 翻译、校对
• #5 - 业务管理类任务

标签分布

还做了一些关于 domain_id 等用户 metadata 标签的分布分析。

问题复杂度

对轮数、query token数量也做了一些分析，发现请求长度 < 300 的用户占 绝大多数（60.2%）。 轮次上，66.7% 的 Web 端用户会在 10 轮内完成对话。不过有一个长尾现象非常有趣，就是有一部分用户请求始终 >50 轮，说明他们习惯于只使用一个对话窗口。 这种超长对话的混淆/压缩对部分人来说应该完全不影响使用意思是。

Web 端有 58.2% 的用户只习惯于单轮回答（算上 API 是 83.8%）。

情感分析

原本还想根据用户反馈（点赞点踩数据）和请求的情感倾向做进一步的分析，但是有用户标签的数据太少了。 而且我发现 D 服务不太适合传统情感分析框架。 原因是：

1. 对话系统的对话主要以指令性内容，此类内容主题包含大量专有名词，同时语气也较为中性
2. 现有情感分析预训练模型的语料于 LLM 对话系统请求几乎无关（如商品评价数据集里，用户直抒胸臆）难以在长文本中捕捉这些细微的用户偏好

C 服务

C 服务也做了词云，即使对请求去重、将代码保留字过滤，常用研发用于依然能占到 n-gram 的主要部分。 C 服务的请求天然包含大量代码、工具的格式内容，统计指标被大量高频背景词（e.g. “代码”、“数据”）

请求结构分析

如果去掉代码附件、system prompt，90% 用户手动输入的内容在 386 token 以内。

对这种情况，如果需要分析用户手动输入的 query 短文本中的主题，有趣 LDA 依赖词与词在同一篇文档中共同出现的频率， 短文本的稀疏性会导致主题分类模糊。因此后文的聚类分析考虑使用语义向量聚类。

快速语义聚类

思路是：使用 Sentence Embedding 把句子转为语义向量，把大量代码、代码与中文请求混杂、中文为主 的三种模式分开。 在意图分析阶段进一步过滤出名词与名动词避免无关信息干扰。考虑到语料数量，使用轮廓系数法搜索合适类别数，最后再 K-means 进行聚类。

C 产品在本阶段不使用 TF-IDF 等高频内容敏感的指标。

分成了 10 类：

• 代码解释与问题分析
• 需求开发
• 生成测试
• 项目理解
• 项目级检查与优化
• 代码优化
• 闲聊
• 研发知识问答
• 攻击内容
• 疑似反向代理

感觉大量用户还把 C 产品作为和 D 产品一样的普通问答，一定程度上体现当时这个产品用户只希望模型给出建议而非直接修改的倾向。