课程导论与知识图谱基础
各位同学，欢迎来到《知识图谱驱动的金融问答系统实战》。我是这门课的主讲人，一个在金融科技领域摸爬滚打了十来年的老工程师。今天咱们先不急着敲代码，坐下来聊聊这门课到底要做什么，以及知识图谱这东西，在金融领域到底能玩出什么花来。
金融问答系统：为什么非它不可？
先问大家一个问题：你平时在银行App或者券商软件里问客服问题，体验怎么样？
说实话，我自己的体验是——挺糟心的。问个「我买的基金最近为什么跌了」，客服机器人给你甩一堆产品说明书链接。问个「科创板开户条件」，它给你念一遍证监会原文。你想想看，这哪是问答？这分明是「关键词检索」。
真正的金融问答系统，应该像一位资深客户经理坐在你对面。你问「我月薪两万，想攒钱买房，有什么理财建议？」它得知道你的收入、风险偏好、当前市场利率、房产政策……把这些信息串起来，给你一个靠谱的答案。
这就引出了核心问题：金融知识是高度关联的。一个实体（比如「茅台」）连着无数关系（「属于白酒行业」、「被张坤持有」、「2023年营收XX亿」）。传统数据库处理这种网状关系，就像用筷子喝汤——费劲。
核心观点：金融问答系统的本质，是把「散落的知识点」变成「一张互联的知识网」。知识图谱，就是这张网的最佳载体。
知识图谱核心概念：实体、关系、属性
好，咱们来拆解一下知识图谱的三大基石。说白了，就是三个词：实体、关系、属性。
实体（Entity）——就是「谁」或者「什么」。在金融领域，实体可以是「贵州茅台」、「张坤」、「2023年」、「白酒行业」。每个实体都有一个唯一的ID，就像人的身份证号。
关系（Relation）——就是「怎么连」。实体之间不是孤立的。「贵州茅台」和「白酒行业」之间是「属于」关系。「张坤」和「易方达基金」之间是「任职于」关系。关系是有方向的，而且可以带属性（比如「任职于」可以带「起始日期」）。
属性（Property）——就是「长什么样」。实体本身有属性，比如「贵州茅台」的「市值」、「市盈率」、「成立日期」。关系也可以有属性，比如「张坤任职于易方达基金」这个关系，可以带「职位：基金经理」这个属性。
我举个例子，大家感受一下：
实体：贵州茅台（ID: stock_600519）
属性：市值 = 2.1万亿
属性：市盈率 = 30.5
属性：行业 = 白酒
关系：贵州茅台 -[属于]-> 白酒行业
关系：张坤 -[持有]-> 贵州茅台（属性：持仓比例 = 9.8%）
关系：贵州茅台 -[发布]-> 2023年年报（属性：营收 = 1500亿）
你看，这一小段数据，就把「茅台是谁」、「它属于哪个行业」、「谁在买它」、「它最近表现如何」全串起来了。这就是知识图谱的威力。
个人经验：我在做第一个金融知识图谱项目时，犯过一个低级错误——把「实体」和「属性」搞混了。比如把「白酒行业」当成「贵州茅台」的一个属性，而不是一个独立的实体。结果后来要查「所有白酒股有哪些」时，代码写得痛不欲生。记住：凡是需要被独立查询、关联的东西，都应该是一个实体，而不是属性。
知识图谱 vs 传统数据库
很多同学会问：我用MySQL或者MongoDB也能存这些数据啊，为什么非要搞个知识图谱？
嗯，这个问题问得好。咱们来做个对比：
| 维度 | 传统关系型数据库 | 知识图谱 |
|---|---|---|
| 数据模型 | 表 + 行 + 列 | 节点 + 边 + 属性 |
| 查询方式 | SQL（JOIN 多表） | SPARQL / Cypher（图遍历） |
| 关联查询深度 | 3层JOIN以上性能急剧下降 | 10层以上依然高效 |
| 模式灵活性 | 需要预先定义Schema | Schema可动态扩展 |
| 典型场景 | 交易记录、用户信息 | 知识推理、关联分析 |
说白了，传统数据库擅长「查已知」，知识图谱擅长「找未知」。
举个例子：你想查「张坤管理的基金中，哪些重仓了白酒股？」在MySQL里，你得JOIN四张表（基金经理表、基金表、持仓表、股票表），写一个20行的SQL。在知识图谱里，一句Cypher就搞定：
MATCH (manager:Person {name:'张坤'})-[:管理]->(fund:Fund)
-[:持有]->(stock:Stock)-[:属于]->(industry:Industry {name:'白酒'})
RETURN fund.name, stock.name, stock.持仓比例
你看，这就像在脑子里画了一张关系图，顺着箭头走就行了。我曾经在项目中用知识图谱做「股权穿透分析」，查一个公司背后的实际控制人。传统数据库跑了5分钟没出结果，换成图数据库，0.3秒就出来了。
避坑指南：不要以为知识图谱能取代所有数据库。我见过有人非要用图数据库存交易流水，结果查询效率还不如MySQL。记住：知识图谱擅长的是「关系密集型」场景，不是「数据密集型」场景。金融问答系统正好是关系密集型的典型代表。
课程项目全景图
好，咱们来看看这门课到底要做什么。整个课程围绕一个完整的项目展开——「智能金融问答系统」。我把它拆成了四个阶段：
- 知识建模阶段：设计金融领域的本体（Ontology），定义实体类型、关系类型、属性约束。说白了，就是给知识图谱「画蓝图」。
- 知识抽取阶段：从非结构化数据（研报、公告、新闻）中抽取出实体和关系。这部分会用到NLP技术，比如命名实体识别、关系抽取。
- 知识存储与查询阶段：把抽取出来的知识存入图数据库（Neo4j），并编写高效的查询语句。
- 问答系统构建阶段：把自然语言问题转换成图查询，再把结果组织成自然语言答案。这里会用到意图识别、实体链接、答案生成等技术。
下面这张图，就是整个项目的核心架构。我建议你多看几遍，后面每个章节都会对应到这张图的某个部分。
这张图里，我特意把「数据源」和「核心技术栈」也标出来了。你会发现，整个项目其实是一个数据流水线：从原始文本出发，经过建模、抽取、存储，最终变成可交互的问答系统。
我的建议：学这门课的时候，别急着跳到自己感兴趣的部分。先把这个全景图刻在脑子里。每学完一章，回来看看这张图，问自己：「我学的东西，在图里的哪个位置？」这样学下来，知识才不会散。
好了，第一章的内容就到这里。咱们把基础打牢，后面才能跑得快。记住：知识图谱不是银弹，但在金融问答这个场景里，它确实是最趁手的工具。
公众号:蓝海资料掘金营，微信deep3321