名词解释

按业务域 → 证据与数据 → 模型与算法 → 技术体系分组。术语对应的字段与表结构见数据模型。

一、业务域

脱水研报（Report） 选股宝编辑对券商研报做摘编改写后的产物，即本项目的"Report"实体。分两源：live 研报（live_tuoshui_news，单篇完整版，4342 篇）与每日汇总（tuoshui_msgs，6 个栏目，3425 篇）。脱水研报中的观点通常转述自券商，所以券商在本系统中是"被引用方"而非"发布者"。

栏目（column） 研报的所属频道（report.column_name，由源表 tag_id 经映射表 src/config.py 的 LIVE_TAG_COLUMNS / DIGEST_TAG_COLUMNS 翻译）。

digest 每日汇总侧 6 栏目（每栏目约每日 1 篇）：1 脱水研报（主刊，正文按小节拆出观点单元，每日简报数据源）/ 2 评级慧选 / 3 直击一线 / 4 每日强股（"N、个股：X 大涨题材：Y"结构段 = isCore=True 强证据来源）/ 7 每日谈 / 99 周回顾（每周 1 篇）
live 实时研报侧 9 个 tag（盘中滚动、每天多篇，单篇完整版、标题即观点）：43 热点（量最大）/ 44 深度 / 42 消费 / 41 医药 / 36 行业精选 / 1 精选 / 11 业绩前瞻 / 46 政策 / 40 未分类（tag_id 缺省也归未分类）

⚠️ 勿与催化类型（reasonType）混淆：栏目是研报的频道归属；催化类型是观点语义的归类（业绩/订单/政策/技术进展/供需价格/产能/事件催化/资金动向，data/reason_types.json）。两者都含"政策"，但语义完全不同。

题材（Theme / plate） A股市场对一类炒作概念的称呼，如"磷化铟""AI算力""机器人"。数据库来源是板块体系（plate_rank_infos，606 个板块，分概念/行业/风格三值分类）。一个题材在系统中有出现次数、衰减热度、最近提及等统计量。

每日强股 / 大涨题材行 "每日强股"栏目正文的固定结构：1、鼎捷数智：物理AI （1）大涨题材：人工智能大模型（2）研报深度复盘（东吴证券…）。这一行直接给出个股 ↔ 题材 ↔ 券商的配对，是全库最强的关联证据（isCore=True 的来源）。历史上该格式带多余空格，提取前需归一化。

观点单元（report_section / 每日简报） 每日简报的浏览基本单位：digest 正文的一个编号小节（≈一篇原始研报的观点），或 live 研报的整条内容（单卡，标题即观点）。由 src/daily.py 从正文分节解析（详细块优先、摘要目录块兜底、文末引用块截断），个股/题材以小节内文本匹配为主源——report_stock/report_theme 是编辑打标口径，覆盖不全（"关注"清单入库率仅 20%）。券商归属为可选增强（券商名出现在节内才标注）。

研报来源块 digest 正文末尾的规整引用格式：券商，分析师姓名，执业编号(S开头)，原始研报标题，日期。是券商引用、评级事件、分析师信息的唯一可靠来源。

产业链（Chain） 人工审校确认的产业上下游骨架，如"AI算力""新能源"。数据库本身没有产业链结构，全部由证据驱动生成（data/chain_map.json，当前 19 条链、300 题材映射）。

环节（Segment）与 segmentType 链上的功能节点。设计上环节 ≠ 上中下游，用"角色类型 + 自由命名 + 顺序"表达：六类角色为 material 材料资源 / process 工艺制造 / component 核心部件 / infrastructure 配套设施 / service 服务 / application 下游应用；stageTag（上游/中游/下游/配套）只是由角色派生的粗分组标签。

卡脖子环节（isBottleneck） 正文出现"瓶颈/卡脖子/咽喉/供给紧缺/自主可控"等用语时标记的环节，页面上红标突出。

券商（Broker） 被脱水研报引用的研报出处（live 标题前缀"国金证券：…"或研报来源块），语义是"被转述方"。一篇脱水研报可引多家券商（多对多）；评级事件才是券商"发出"的（多对一）。

评级事件（RatingEvent） 券商对个股的评级行动：首次覆盖 / 上调 / 下调 / 目标价 / 增持 / 维持。从研报来源块的原始标题识别（如"绿发电力-首次覆盖报告"）。全库低频高价值（"首次覆盖"尤其稀缺）。

分析师（analyst） 研报来源块中的持牌分析师姓名 + 执业编号（S 开头）。不设独立实体，作为引用关系与评级事件的属性保留。

二、证据与数据

强证据 / 弱证据（isCore） 同一对"题材×个股"关联的证据分两档：大涨题材行、研报来源块直接配对 = 强证据（isCore=True，参与推荐时间线与热度加权，权重 1.0）；plates 字段与个股共现 = 弱证据（isCore=False，只计次数，权重 0.3）。关联表以 evidence / evidence_quote 字段记录出处原文。

证据句（evidenceQuote） 规则定位的原文关键句，零成本获得，供人工核对 LLM/规则摘要是否失真。

推荐观点（提及即推荐记录） report_mentions_stock / report_mentions_theme 关系实例携带的观点属性集合：viewDate（时间点）、reason（≤50 字原因摘要）、reasonType（催化类型）、evidenceQuote（原文）、isCore（强度）。脱水研报的核心价值就是"某时间点、以某理由推荐某标的"。

催化类型（reasonType） 推荐原因的归类，开放字典八类：业绩 / 订单 / 政策 / 技术进展 / 供需价格 / 产能 / 事件催化 / 资金动向。当前由关键词字典分类（src/viewpoint.py）。

图片上下文（contextText） 图片在正文 <img> 标签前后各 100 字的文本，登记时零成本保存；是"是否值得花 LAS 解析"的判断依据（含"产业链/格局/架构"则优先）。

三、模型与算法

衰减热度（decayScore） Σᵢ exp(-ln2 × 距今天数ᵢ / 60) × 权重ᵢ——每次提及按 60 天半衰期指数衰减后加权求和。表达"最近还被反复提及"的程度，与原始出现次数互补。参数（半衰期、核心/共现权重）在 src/config.py 可调。

出现次数（occurrenceCount） 题材（或题材×个股对）在全部研报中被提及的原始计数，不随时间衰减。

时间窗（cnt_5d/10d/20d/30d） 截至最新研报日的滚动窗口内被提及的研报篇数（自然日口径）。配合 theme_daily 表可现算任意窗口。题材页以徽标展示，每日题材页以页面级周期选择器（3/5/10/20日）驱动。

数据日 有研报发布的日子（自然日历中周末/停市日无数据）。窗口类指标以自然日截断，"活跃天数"以数据日计数。

活跃天数 所选时间窗口内题材（或产业链）出现过的数据日数。仅选定时间周期后统计与展示（未选定默认隐藏）；"连续 N 天出现"的查询语义 = 窗口内活跃天数 ≥ N。产业链活跃天数 = 链上任一题材当日被提及即计 1 天。

活跃个股 窗口内被研报推荐的个股；其关联题材 = theme_stock 关联 ∩ 窗口内活跃题材（历史题材窗口内未出现不展示）。每日题材页以题材↔个股关联图呈现（题材节点唯一，连线=关联，个股越红/越大=被推荐越多）。

最近提及（lastSeenAt） 最后一次出现的时间，页面显示为"X 天前"。

推荐时间线 个股页/题材页的核心视图：按时间倒序排列历次推荐记录（日期 + 催化类型 + 原因 + 原文链接），顶部聚合催化类型分布。

信号句 观点规则引擎的判定单位：包含"涨停/大涨/催化/受益/利好/预期…"等信号词之一的句子才算"推荐原因"（src/viewpoint.py 的 _SIGNAL_WORDS）。

四、技术体系

本体（Ontology） 对某领域"存在什么实体、实体间什么关系"的形式化定义。本项目 = 8 实体 / 11 关系（见数据模型），单一事实源在 src/ontology.py 的 build_schema()。

Ontology-Playground 开源的本体 schema 可视化工具（本项目使用作者 fork：https://github.com/seuzxh/Ontology-Playground ）。只渲染实体/关系类型层，不渲染实例数据。本项目与之有三种结合：本地镜像内嵌（/Ontology-Playground/，已汉化）、embed widget（/ontology 页）、fork catalogue 推 GitHub Pages。

开放字典（注册表机制） data/segment_types.json / reason_types.json / event_types.json 三个 JSON 注册表，管理所有类型字段的合法值 + 展示元数据。遇到字典外的新类型不报错、不丢数据，先写入 _pending 待审区，人工转正后下次 ETL 生效。加类型零数据库迁移。

待审核（_pending） 开放字典中等待人工审核的新类型隔离区。

RDF/XML 导出 src/rdf_export.py 产出的 Ontology-Playground 兼容格式（owl:Class / DatatypeProperty / ObjectProperty + ont: 扩展属性），加 metadata.json 构成一个 catalogue 条目。

catalogue Playground 的本体目录机制：仓库内每个目录（.rdf + metadata.json）构建为一个可在线浏览的条目，本项目条目 slug 为 xgb-a-chain。

ETL Extract-Transform-Load：内网 MySQL（只读 SELECT）→ 正则/规则提取 → SQLite 本体实例。全流程幂等，可反复全量重建。

增量同步（水位） 默认同步模式：etl_meta.wm_live_id / wm_digest_id 记录上次同步时源表主键最大 id（含已删除行），下次只拉 id 更大的新研报。旧库无水位时按本地 MAX(src_id) 自动引导。流程与规则详见数据同步指南。

环境检查 / 数据校验（同步五阶段） 同步的固定防护链：环境检查（目录/磁盘/MySQL/源表/本地库，失败即停不碰数据）→ 备份 → 写临时库 → 数据校验（E0~E5/X1 错误级即回退，W1~W3 警告级只记录）→ 原子替换正式库。

回退（rollback） 校验失败时回到同步前状态的机制：所有写入只落 *.tmp-sync 临时库，正式库全程只读，删临时库即完成回退，不存在半回退状态。

同步日志（sync_log） 每次同步（成功/环境失败/校验回退）一条记录，双写库内 sync_log 表与 data/xgb_wiki.sync.log 文件；sync_data.py --log N 查看。

自然语言查询（nlq） src/nlq.py 规则式解析器（无 LLM）：识别时间窗/活跃天数/链名/题材名/日期意图。GET /api/nlq、静态站时间轴页前端、MCP/CLI 三端同口径；与 LLM 问答（/api/ask）互补。

MCP / skill（对外查询与同步） scripts/mcp_server.py 提供 MCP server（stdio，工具：search_themes / theme_detail / daily_themes / hot_streaks）与 --cli 命令行；skills/ 下两个 skill（install_skill.py 装到 ~/.zcode/skills/）：xgb-wiki 题材查询（语法/口径/红线）、xgb-sync 数据同步（用法/退出码/回退语义/红线）。均无需 LLM key。

静态研报站 scripts/build_static_site.py 生成的纯静态镜像（Flask 页面的公网子集 + 前端规则式查询），部署于 Cloudflare Pages（xgb-wiki-site.pages.dev），push master 由 GitHub Actions 自动测试+构建+发布。

LAS 图片解析 经全局 skill las-document-parse 调用的图片理解服务，限流 1 QPM、按页计费（normal 0.02 元/页）。策略：全量登记、选择性解析（评级事件配图 / 产业链上下文图 / 用户点击），批量队列按 65 秒/张节流。

幂等重复执行结果一致：ETL 全量重建覆盖旧库；链映射重跑不覆盖 manual: true 条目；汉化脚本重跑跳过已替换文本；图片解析按 imageId 缓存不重复计费。