1️⃣需求解析&辅助研发

这个功能其实很有意思，我们迭代了两期。

第一期，其实这个功能一开始设计的比较天马行空，就是直接给一个需求进来，然后直接给你开发好。但是研发了半个月叫停了，发现模型根本理解不了整个需求，我们尝试过使用claude，准确率确实好一点，但是对于上线直接用，还是不行。所以最后我们退而求其次，还是做辅助吧，就是你一个需求来了，先帮你设计个大概，或者你自己描述清楚点，一步步做引导式的进行开发，就像现在的cursor，不过这里做了rag检索，就是用把2️⃣里面的表和描述都放进去了。你每描述一句，就帮你把对应的表，相应的sql写出来，但是用不用还是你自己定，不保证正确性，只是纯辅助。发现这个功能数据同学用起来还挺爽，因为你不会干掉他们，但是能减轻他们的工作量。

第二期，跟数据一起做了很多的对焦后，发现他们很多需求其实有些相似和重复，甚至很多代码跟线上的某些片段式类似的。所以我们做了一个事情就是，把他们线上的代码都解析一下，这个解析真的花了很大的工作，就这一句话我们花了一个同学两周的时间。最后保证了很高的准确率的。就是每个代码片段，从局部到整体，都让大模型做描述，最后得到很多描述和代码pair。然后我们把这个也落库，当他们在写需求的时候，我们就纯检索，然大模型参考写。这个真的是大大提高了代码的准确性。他们用起来贼爽。

2️⃣表查询&答疑

这个功能应该是所有企业都做了的，对于一个大的公司，一个大部门常用表都得上万张，老方法都是直接找到对应部门问tl，然后层层传导找到具体的人，看有没有相应的数据和表。而找到人大概率就是甩给你一个文档，你先通读一遍。稍微先进点的都有对应的搜索系统，但是纯模糊匹配，再自己挨个看，再找对应人答疑看文档。所以大模型第一个提效的就是这个活，把所有表落库，且有对应的说明，对应的字段都有解释。我们给该场景做了很多智能化能力，首先是落库，落库前大模型会仔细check描述和解释是否符合标准，不符合标准从来。然后是答疑faq，有标准的格式。然后是表和faq落库建立索引。最后是建立一个大模型的数据表查询和答疑库，进行rag答疑。

3️⃣报表查数

首先这个一开始想的是给运营和老板做的，因为他们不会写代码，但是就是会有各种奇奇怪怪的查数需求，之前都是提需求给数据研发，所以想说能不能用大模型做这事，这个功能我觉得做的不是很好，虽然老板和业务买单了，因为这个功能要求非常精准的结果，我们做到最后单表查询是很准的，多表查询不行。为什么单表查询老板和运营就买单了呢，因为我们的场景有上千个字段，老板只是会统计一些组合数据，看一下，指导自己的决策。但是单表就注定他不是很灵活，所以我是觉得做的失败的。

4️⃣运维&治理

很多人不理解数据开发为啥要治理，其实你自己想想，你很有可能开发了某个功能，每天例行在跑数据，但是突然哪天这个业务停了，这个数据没用了，但是你很可能并没有把数据停下，就会造成浪费，在真实的工作中大部分人不会自己去审核自己的代码是否还有用，这种费力不讨好的活，基本上不会有人干。所以之前有很多检测机制，最简单的就是检测这个表有没有读取，但是这个方法也有很多应对的策略。所以为了能够更好的治理，就让大模型解读代码，帮你把上下游梳理出来，然后看哪些表根本没有业务在使用。迫使你去干掉。这个活其实很有意思，但是其实准确率不高，不过还是在持续迭代中。

2026年，大模型已经无处不在，但"幻觉"（hallucination）仍是企业落地的最大杀手：金融风控、医疗问诊、客服机器人动辄编造事实，直接导致合规风险和信任崩盘。

知识图谱（Knowledge Graph） 的核心价值正是结构化知识：把碎片化数据变成"实体-关系-属性"的三元组网络，让大模型"先查图谱再回答"。

• 行业价值：支持复杂多跳推理、知识溯源、实时更新，广泛用于推荐系统、智能搜索、企业大脑。
• 大模型痛点：纯向量RAG召回率低、无法处理逻辑关系；知识图谱+大模型（GraphRAG）可将准确率提升40%以上。
• 图谱赋能意义：把大模型从"概率生成器"变成"可信知识引擎"，真正实现企业级私有化落地。

核心知识点：知识图谱不是"又一个数据库"，而是大模型的长期记忆和推理大脑。

为方便大家学习 这里给大家整理了一份学习资料包 需要的同学 根据下图自取即可