利用生成式AI从无序数据中获取洞见
使用生成式AI分析混乱数据的最佳实践检查表
本文分享了一些我们公司使用生成式AI分析数据以更有效地进行运营的一些最佳实践。虽然花了一些时间，但我终于获得了Salesforce的市场、法律、安全和公关团队的批准，得以发表这篇文章。希望这能帮助你加速数据分析。
本文中的所有图表都是方向性和准确的，用于传达概念，但数据已匿名化处理。
- 使用LLM进行数据过滤： 无需在源头清理数据；可以在数据中途使用LLM进行净化。
- 使用GPT自动化Python： 虽然通常需要中级Python技能进行数据提取、修改和可视化，但GPT可以自动化并加速这些任务。
- 领域特定的工单过滤： 当元数据不可靠时，可以根据支持工程师进行工单过滤。
- 可靠的数据提取： 重点提取描述和时间戳等可靠字段，因为这些字段更不容易出错。
- 使用GPT进行数据匿名化： 结合开源匿名化库使用GPT，在将数据发送到公共API之前进行匿名化处理。
- 仔细选择分隔符： 慎重选择输出分隔符，确保它们不会干扰语言模型的处理，同时通过去除选择的分隔符来净化输入数据。
- 为准确性调整GPT的提示： 在全面分析之前，评估和调整提示在已知工单描述上的表现。
- 上下文数据限制： 了解GPT在处理上下文无关数据块上的上限；保持在识别上限以下10%，以避免数据丢失。
- 与GPT一起头脑风暴KPI： 提取元数据后，使用GPT头脑风暴并创建有意义的KPI进行可视化。
- 简化的数据可视化： 利用GPT编写Python代码来创建图表，将分析简化并在一个环境中进行版本控制，而不是使用单独的可视化工具。
你是否曾面对大量由人类输入的杂乱无章的自由格式数据并试图理解它？这是一项极其繁琐且耗时的工作，除非你有专门的时间去细细研究，否则你可能只是抽样查看数据，最终只能得到表面见解，这些见解可能基于不可靠的元数据。通常，这样的做法效果并不好。
显然，大型语言模型擅长理解混乱的数据，因此可以在这里发挥很大作用。本文讨论了从这样的实施中汲取的最佳实践，涵盖了如何使用GPT最有效地帮助你清理数据、进行分析并创建有用图表的方法，管理个人可识别信息（PII）的方式、经过生产硬化的提示设计、解决GPT的“前额皮层”瓶颈等多个方面！
但在开始之前，我想先分享一下这个经验是如何完全改变我对于数据质量的强烈看法的：
我曾经相信，为了提高数据质量，必须从源头上修复，也就是从交互系统（System of Engagement）开始。例如，我曾认为，对于销售CRM，我们必须确保销售和市场团队在一开始输入优质的数据和元数据。同样地，对于客户支持，我们必须确保客户支持工程师在工单的创建、处理和关闭时选择所有正确的元数据（如工单原因代码、客户影响等）。
在我最近的经历中，这些信念已经被打破了。你完全可以在源头上拥有未整理的数据，并在正确的指导下，大型语言模型（LLM）仍然可以理解它，并得出有意义的洞察！
无需在源头清理数据：就像一个净水器，你只需在数据流中插入一个LLM，它就能净化数据！
GPT可以像净水器一样，接收带有脏元数据的信息并进行净化，从而提取出有用的洞察。
从长远来看，确实有必要在源头处建立准确元数据的流程，尽管要记住这些流程协调和审计都非常耗时。
为了进行这次分析，我有两个简单的原则：
- 避免中断团队当前的交付：虽然我可以让团队中的某人来做这个分析，但这会中断团队在正在进行项目上的工作进度。我需要在继续我的产品开发主管日常工作的同时，自己完成所有的分析。
- 全面使用生成式AI：大型语言模型在数据处理方面非常出色，特别是对于这种使用情况，可以从杂乱的数据中提取价值。它们在编程方面也比我优秀得多。让AI做事并检查结果，比自己投入其中要容易得多。这样，即使是兼职的努力也可以产生影响。
前提总结： 提取、修改和可视化数据需要中级水平的Python编程，但现在，GPT可以更快地为你完成所有这些工作，甚至质量更高。用它吧！
在下图中，我展示了所有需要编写代码的各个步骤（绿色字体）以将数据转换并调用GPT API以从工单详细信息中提取洞察。最棒的是，我不需要从头开始写这些代码。我用GPT实际上为我编写了这些代码！
所有涉及基于LLM的工单分析的步骤
虽然我的Python水平还算不错，但通过使用GPT编写代码，使我的水平至少提高了3倍。我使用了一种非常基础的方法来通过GPT编写代码：我没有用它来执行任何代码。我只是告诉GPT数据是什么样子，并让它为我编写代码。我还让GPT在代码的不同点插入print语句以打印变量。然后我把这些代码复制到我笔记本上的Jupyter Notebook中并在那里执行。例如，我的提示会是这样的：
我： 这是我在分析中将使用的所有文件。我会将它们编号并在提示中用它们的编号来称呼它们。
1. “All Interacted Tickets.xlsx”
2. “Copy of Ticket Dump — Received from Ops.xlsx”
3. “verifying_accurate_list_of_ops_people_supporting_my_space.xlsx”
它们都在 ../data/ 目录下。
编写Python代码，将文件1、2和3导入pandas数据框。忽略任何包含“pivot”字样的工作表，但导入其余部分的数据。使用每个Excel文件中每个工作表中的文本将数据框命名为蛇形命名法….
然后，GPT会生成代码，例如：
import pandas as pd
import os
files = {
1. “All Interacted Tickets.xlsx”,
2. “Copy of Ticket Dump - Received from Ops.xlsx”,
3. “Verifying_accurate_list_of_ops_people_supporting_my_space.xlsx”
}
def snake_case(s):
return s.lower().replace(” “, “_”)
def read_excel_sheets(file_path, ignore_pivot=True):
xl = pd.ExcelFile(file_path)
sheet_names = xl.sheet_names
….
然后，我会在本地运行这段代码。如果出现错误，我会将错误输出（包括打印语句的输出）粘贴到“同一个”对话中，因为这样可以保留记忆，尽管如此，这样的方法“大部分”时候能够解决问题。但是，有时GPT会陷入困境（可以从它反复推荐同一个解决方案时看出来），这时我会开始用更多的问题来询问它：
我： df \= df[1:] 这段代码在做什么？
GPT： 这行代码 df \= df[1:] 用于删除数据框的第一行，这通常是从Excel文件读取时的标题行……
我： df \= df[1:] 是错误的，我不想删除第一行。这实际上是你希望用作每个数据框标题的那一行。
因此，如果你像我一样在带外使用GPT开发代码，具备一定的Python知识是有用的，因为这样可以解决一些GPT由于对上下文不了解而产生的问题。
请注意，如果你使用多代理框架，这些代理可能会相互反馈代码并自动解决这些缺陷。在未来的一篇文章中，我将展示我的本地环境设置，用于数据工程和分析，并展示如何在笔记本电脑上设置这种多代理框架。如果你对此感兴趣，请在评论中告诉我。
经过几次迭代和‘误操作’，我总结出了以下步骤！换句话说，如果我重新进行这个分析，我会遵循以下结构来优化流程。所以，我将此呈现给你，希望你能从中受益。客气了！
简明结论： 如果元数据不可靠，那么根据处理过这些票据的支持工程师来筛选与你领域相关的票据是最好的选择。
筛选你团队的票据
（仅当你在一个中型或大型组织中工作，并且是利用共享运营团队的众多团队之一时，才需要这一步）
将工作票据集限定为与你部门或团队相关的是一个重要的筛选步骤，当你的公司有大量操作票据需要处理时，必须执行这一步。你将把这些票据发送到大型语言模型（LLM）中，如果你使用的是像GPT4这样的付费服务，那么你只想发送与自己相关的票据！
然而，当元数据不那么理想时，确定工作的票据集会成为一个问题。支持工程师可能没有被指示标记这些票据属于哪个团队，或者没有合适的票据分类可供选择，所以你只能使用一些自由形式的数据和自动收集到的一些基本“事实”。这些事实包括谁创建了票据，谁拥有它，票据创建的时间戳、状态变化（如果你运气好的话），以及票据关闭的时间等。还有一些可能存在的“主观”数据，例如票据的优先级。收集它们是可以的，但这些可能不准确，因为票据创建者往往会将他们创建的所有票据都标记为“紧急”或“高优先级”。在我的经验中，通过LLM来推导实际优先级通常会更中性，尽管这也仍然会出错，如后面所述。
所以，换句话说，坚持“事实”。
在通常情况下，可以帮助你减少工作集的“事实”之一是创建和/或处理工单的支持工程师的名字。由于支持工程师也专注于特定领域（数据技术，客户管理系统(CRM)，工作日系统等），第一步是与支持经理合作，确定在你领域内处理相关工单的所有支持工程师的名字。
然后，使用可以识别的关键，如他们的工作邮箱地址，你可以将大量工单筛选到与你的部门相关的子集，并提取与这些工单相关的“事实”元数据。
完成这一步后，你也得到了第一个统计数据：在一段时间内，我的领域内有多少工单被打开。
底线优先： 虽然工单创建者可能会把许多元数据弄错，但她不会搞错描述字段，因为这是她向支持团队传达问题及其业务影响的唯一方式。这很完美，因为理解自由流动的数据正是GPT的专长。因此，重点应放在提取描述字段和其他难以出错的实际数据，如工单开始和结束时间等。
用元数据充实已过滤的工单，特别是描述字段
大多数工单系统，如Jira服务管理，Zendesk，Service Now等，允许你下载工单元数据，包括长多行描述字段。（我在工作的自建系统中就没有这么幸运了）。然而，几乎所有这些系统一次最多只能下载一定数量的工单。更自动化的方法，也是我采取的路线，是使用API提取这些数据。在这种情况下，你需要从第1步得到支持你团队的支持工程师处理的精心挑选的工单集合，然后循环遍历每个工单，调用API提取其元数据。
一些其他系统允许你通过类似ODBC的接口发出SQL（或对于Salesforce产品发出SOQL）查询，这很酷，因为你可以使用WHERE子句在一次操作中结合步骤1和步骤2。以下是一个伪代码示例：
SELECT ticket_number, ticket_description, ticket_creation_date, blah blah
FROM ticket_table
WHERE ticket_owners include ", " ...
你明白了…
将这些数据保存为MS-Excel格式并存储在磁盘上。
为什么使用MS-Excel ? 我喜欢将表格数据“序列化”为MS-Excel格式，因为这消除了在将这些数据导入Python代码时可能出现的任何转义或重复定界符问题。Excel格式将每个数据点编码到其自己的“单元格”中，没有解析错误，也不会因为文本中隐藏的特殊字符/定界符导致列错位。此外，当将这些数据加载到Python中时，我可以使用Pandas（一个流行的表格数据操作库）通过其简单的Excel导入选项将Excel数据导入到一个数据框中。
底线优先： JSON是人类可读、机器可读的，错误安全，易于排错，GPT能以最小的错误轻松操作。此外，随着你丰富数据，你可以不断给同一个JSON结构添加新字段。这太棒了！