议事厅会话记录 — 2026-04-11（系统四链路优化）
主题: 文献检索 · 书籍查找 · 会话推理 · Web UI — 现状诊断与优化路径 参与方: 项目主理人、灵知、灵依、灵克、灵通、灵研 性质: 技术架构优化讨论 关联文档:
docs/COUNCIL_HALL_2026-04-11-STRATEGIC-ROADMAP.md、docs/COUNCIL_HALL_2026-04-11-EDGE-AI-WORLD-MODEL.md
零、讨论前提：四条链路不是四个功能，是一条管线
书籍查找（知识解放：把沉睡的内容变成可用的数据）
↓ 内容被结构化
文献检索（精准找到：在海量数据中命中真正相关的内容）
↓ 检索结果作为输入
会话推理（深度理解：从检索结果中推理出有洞见的回答）
↓ 推理结论推送给用户
Web UI（交互呈现：让用户以最自然的方式获取和使用知识）
任何一环的短板都会成为整条管线的瓶颈。以下逐环诊断。
一、文献检索 — 缺二次精排，召回质量是最大瓶颈
1.1 现状
| 组件 | 实现方式 | 问题 |
|---|---|---|
| 向量召回 | BGE-small-zh (512-dim) + pgvector 余弦相似度 | 模型偏小，复杂语义区分力弱 |
| 关键词召回 | BM25 + jieba 分词 + 自定义词典 | 内存索引上限 5 万条，不可扩展 |
| 融合策略 | RRF（向量 0.6 + BM25 0.4） | 粗排有效，但无精排 |
| 缓存 | L1 内存 + L2 Redis，搜索结果 5min TTL | 合理，无需改动 |
1.2 核心问题
- 没有 reranker（二次精排）。RRF 融合后的 top-20 里经常混入不相关结果。用户搜"舌诊与脏腑的关系"，命中结果可能包含"舌诊"的无关段落。cross-encoder 精排能直接过滤掉语义不匹配的结果。
- BM25 全内存不可扩展。
_MAX_INIT_DOCS = 50000硬上限，books 三张表合计远超此数。随着数据增长，BM25 召回会越来越残缺。 - 查询侧太朴素。用户搜"舌诊"时不会想到"望诊""舌象""辨舌"，需要同义词/领域词典扩展。
1.3 灵知的优化建议
| 优先级 | 改动 | 投入 | 效果预期 |
|---|---|---|---|
| P0 | 引入 cross-encoder reranker（推荐 bge-reranker-v2-m3） |
2-3 天 | 检索准确率提升 15-25% |
| P1 | BM25 改造为 PostgreSQL tsvector + zhparser 全文索引 |
5-7 天 | 消除 5 万条上限，支持百万级 |
| P2 | 九域领域同义词词典 + query expansion | 3-5 天 | 召回率提升 10-20% |
优先做 P0 reranker，因为： - 和现有 BGE 生态一致，集成成本低 - 不改变现有架构，只需在 hybrid fusion 后加一步 rerank - 投入产出比最高，2-3 天就能看到显著效果
二、书籍查找 — 三个数据源各自为战
2.1 现状
| 数据源 | 规模 | 内容深度 | 搜索方式 |
|---|---|---|---|
books |
结构化书籍 | 元数据 + 章节内容 + 嵌入 | ILIKE + 向量相似 |
sys_books |
300万+ 文件 | 仅元数据（文件名/路径/域） | ILIKE |
guoxue_books |
109 部经典 | 完整原文 + 章节结构 | ILIKE + similarity() |
LingFlow 做了统一搜索，但 relevance 打分是硬编码的（books=1.0, sys_books=0.8），实际效果一般。
2.2 核心问题
- sys_books 有索引无内容。300万文件搜到后打不开，等于摆设。内容抽取和嵌入是前置条件，但这和战略路线图 Phase 3（古籍 OCR）有重叠。
- 古籍搜索用 ILIKE。109 部经典的全量内容用
LIKE '%keyword%'搜，慢且不精准。应该走向量检索或 tsvector。 - 书籍间缺少语义关联。"《黄帝内经》"和"《针灸甲乙经》"在知识体系中有引述关系，当前只靠向量相似度推荐，丢失了结构化知识。
2.3 灵知的优化建议
| 优先级 | 改动 | 说明 |
|---|---|---|
| P0 | guoxue_books 搜索从 ILIKE 迁移到向量检索 + reranker |
和检索优化的 reranker 共用，一举两得 |
| P1 | 统一 relevance 打分：用 reranker 分数替代硬编码 | LingFlow 搜索质量立即提升 |
| P2 | sys_books 内容抽取（PDF/DJVU → 文本 → 嵌入） | 与 Phase 3 古籍 OCR 合并规划，不做两遍 |
| P3 | 书籍间关系图谱（引述/注释/演变） | 依赖 NER 模块，归入推理优化一起做 |
三、会话推理 — 框架到位，深度不足
3.1 现状
| 推理模式 | 实现 | 核心能力 |
|---|---|---|
| CoT | 多模板 prompt + 步骤解析 + 置信度 | 线性推理，适合事实/解释类问题 |
| ReAct | Thought→Action→Observation 循环（最多5轮） | 工具调用（search/lookup），适合多步问题 |
| GraphRAG | 正则实体抽取 + 共现关系 + BFS 子图提取 + LLM 生成 | 知识图谱可视化，适合关系类问题 |
自动模式选择：关键词路由（关系→graph_rag, 如何/步骤→react, else→cot）。
3.2 核心问题
| 环节 | 现状 | 问题 | 影响 |
|---|---|---|---|
| 实体抽取 | 正则匹配（~30个模式） | 只能识别固定格式，漏识别率高 | GraphRAG 的图谱质量差 |
| 关系类型 | 全部标注为"相关" | 无法区分引述/注释/对立/演变 | 图谱没有语义深度 |
| 知识图谱 | 内存中重建，重启消失 | 无法积累，无法跨会话复用 | 图谱每次从零开始 |
| 多轮对话 | 无状态（session_id=时间戳） | 无法追踪上下文 | "你刚才说的那个穴位"无法理解 |
| ReAct 工具 | 只能过滤已有 context | 不能调用外部 API | 无法真正"行动" |
| 置信度 | 启发式（答案长度+步骤数） | 不校准，数字无实际意义 | 用户无法判断可信度 |
3.3 灵知的优化建议
最关键的一步：NER 模型替换正则。
九域知识中的实体（穴位、经络、方剂、功法、证候、古籍名）有明确命名规范，用 UIE（Universal Information Extraction）或领域微调 NER 模型，能将准确率从当前 30-40% 提升到 80%+。这直接影响 GraphRAG 的质量。
| 优先级 | 改动 | 投入 | 效果 |
|---|---|---|---|
| P0 | 引入 NER 模型（uie-base 或九域微调）替换正则 |
5-7 天 | 实体识别准确率 30% → 80%+ |
| P1 | 知识图谱持久化到 PostgreSQL | 3-5 天 | 图谱跨重启积累 |
| P1 | 关系分类器（引述/注释/演变/对立） | 5-7 天 | 图谱从"相关"到"有意义" |
| P2 | 多轮对话管理（上下文窗口 + 会话记忆） | 5-7 天 | 支持追问和指代消解 |
| P2 | ReAct 工具扩展（调用书籍/文献/边缘设备 API） | 与边缘 AI Phase 1 联动 | 真正的多步推理 |
| P3 | 置信度校准 | 3 天 | 可信的概率分数 |
3.4 与边缘 AI 的联动前瞻
当 /api/v1/posture/evaluate 上线后，推理系统需要处理跨模态推理：
用户： "我刚才第二式感觉肩紧，是什么原因？"
系统需要：
1. 从会话记忆中知道"第二式"指"左右开弓似射雕"
2. 从边缘设备获取刚才的姿态数据（肩部关键点偏移）
3. 从气功域知识中检索该式的要领
4. 推理：肩紧 → 沉肩不够 + 肘部外翻
5. 返回个性化指导
这需要多轮对话 + 跨模态上下文 + 真正的工具调用能力。当前的 stateless 设计做不到。
四、Web UI — 到了拆分重构的临界点
4.1 现状
| 指标 | 数值 |
|---|---|
| 代码量 | app.js 1338 行 + style.css 1408 行 + index.html 205 行 |
| Tab 数 | 7 个（Search / Documents / Books / 国学经典 / 书目检索 / Ask / Reasoning） |
| 框架 | 无，原生 JS |
| 构建工具 | 无 |
| 状态管理 | 全局变量 |
| 测试 | 无 |
4.2 核心问题
- 维护性差。1338 行单文件，加一个功能要通读全局变量、手动管理 DOM。知识图谱 Canvas 绘图就有 200+ 行纯手写坐标计算。
- API 版本不一致。Books 用
/api/v2，其他用/api/v1。 - 交互停留在"工具"层面。当前是"用户主动搜 → 系统被动答"。知识落地需要系统主动推送——练功实时反馈、健康趋势、个性化推荐。
- 无实时通信。所有数据按需 fetch，无 WebSocket/SSE。当姿态评估上线后需要实时推送纠正。
4.3 灵知的优化建议
不急着换框架，分阶段演进：
| 阶段 | 时间 | 改动 | 理由 |
|---|---|---|---|
| 短期（Phase 0 期间） | 2-3 天 | app.js 按功能拆成 ES modules（search.js / books.js / reasoning.js / graph.js） |
不加框架，但把 1338 行拆成可维护的模块 |
| 中期（Phase 1） | 与边缘 AI 联动 | 引入 Vue 3（轻量，渐进式）+ WebSocket 实时通信 + 姿态反馈面板 | 需要状态管理和组件化，Vue 比 React 更适合渐进迁移 |
| 长期（Phase 2+） | 多模态诊断上线 | 完整 SPA + ECharts 健康趋势图 + 训练计划面板 + 语音播报 | 从"问答工具"变成"健康仪表盘" |
短期的模块拆分是零风险的——ES modules 不需要构建工具，浏览器原生支持，index.html 里加 type="module" 即可。
五、依赖关系与优先级排序
5.1 四条链路的依赖图
Reranker (P0)
├── 直接提升文献检索质量
├── 直接提升书籍搜索质量（guoxue_books 复用）
└── 间接提升推理质量（更好的 context → 更好的推理）
NER 模型 (P0)
├── 直接提升 GraphRAG 实体识别
├── 为书籍关系图谱提供基础
└── 为古籍 NER（Phase 3）积累经验
UI 模块化 (P1)
└── 纯前端，不依赖后端改动
知识图谱持久化 (P1)
├── 依赖 NER 模型上线
└── 为推理和书籍关联提供基础
多轮对话 (P2)
├── 依赖图谱持久化
└── 为边缘 AI 联动做铺垫
5.2 建议执行顺序
第一批（1-2周）：
├── Reranker 集成（2-3天）
├── UI 模块拆分（2-3天）
└── NER 模型调研与选型（2天）
第二批（2-4周）：
├── NER 模型集成替换正则（5-7天）
├── 知识图谱持久化（3-5天）
└── guoxue_books 搜索迁移（3天）
第三批（4-6周，与 Phase 1 边缘AI联动）：
├── 多轮对话管理
├── ReAct 工具扩展
└── Vue 3 迁移 + WebSocket 实时面板
六、议事厅讨论
灵依（项目协调）
四条链路的优化方向我都认同，但节奏控制很重要：
- 第一批和 Phase 0 可以并行。Reranker 和 UI 拆分都是改进现有系统，不依赖新硬件，不冲突。
- NER 模型需要评估后再投入。建议灵研先做技术调研：UIE 在九域实体上的表现如何？是否需要领域微调？微调数据从哪来？有结论后再排期。
- 不要和安全事故修复抢资源。SEC-2026-0408 的修复仍然是 P0，优化工作在修复完成后再启动。
灵克（质量与流程）
从工程质量角度，几个关键考量：
- Reranker 的性能预算。cross-encoder 推理比 bi-encoder 慢一个数量级。如果对 top-20 做 rerank，每条查询增加 50-100ms 延迟。需要设定 SLA（如 p95 < 500ms）并做 A/B 测试验证效果。
- NER 模型的部署方式。是在线推理还是离线预标注？如果在线推理，需要考虑并发和延迟。如果离线预标注，需要增量更新机制。
- UI 模块拆分的回归风险。1338 行拆成模块，任何一行引用错误都会导致功能断裂。建议：先加 E2E 测试（Playwright 或 Selenium），再动手拆。有测试兜底才敢重构。
- 知识图谱持久化选型。PostgreSQL + JSONB 够用吗？还是需要图数据库（如 Apache Age，PostgreSQL 的图扩展）？需要评估数据规模和查询模式。
灵通（安全审计）
两个安全相关的考量：
- Reranker 模型的供应链安全。从 HuggingFace 下载的模型文件需要做完整性校验（SHA256）。建议模型文件纳入版本管理或使用可信镜像源。
- NER 处理的数据隐私。如果 NER 在线推理，用户查询中的个人信息（姓名、地址、症状描述）会经过模型。需要评估模型是否留有日志，确保不泄露。
- 多轮对话的数据留存。会话记忆意味着用户数据被持久化。需要明确：保留多久？用户能否删除？与个人信息保护法的要求对齐。
灵研（技术研究）
从研究角度，我看到几个值得深入的方向：
- Reranker 选型不只是 bge-reranker-v2-m3。还有几个候选值得对比：
bge-reranker-v2-m3：通用，多语言，和现有 BGE 生态一致bce-reranker-base_v1：中文优化，可能更适合九域场景jina-reranker-v2：长文本支持好（8K tokens），适合古籍段落建议用九域标注数据做一个小规模 benchmark 再决定。
- NER 的九域适配是核心难点。通用 NER 模型在"足三里""关元""命门"这类穴位名上表现很差——它们在通用语料中被标注为地名或人名。需要九域领域的微调数据。建议：
- 从现有九域知识库中自动抽取实体构建训练集
- 用 UIE 的 prompt-based 方法降低标注成本
先做穴位+经络两个子域的试点
知识图谱的关系分类值得做研究。当前所有关系都是"相关"，但九域知识中的关系有明确类型：经典引用（如《甲乙经》引《内经》）、理论演变（如温病学派从伤寒论发展）、方剂组成（君臣佐使）。这些关系类型如果能自动分类，本身就是一个有学术价值的贡献。
多轮对话可以借鉴 ReAct 的工具调用模式。当前的 ReAct 工具是假的（只过滤 context），但如果把书籍检索、文献检索、边缘设备都注册为 ReAct 工具，推理系统就能真正"行动"——用户问"八段锦第二式的要领在哪本古籍里有记载？"，系统先识别实体（八段锦、第二式），调用书籍检索工具找到相关古籍，再调用文献检索找到具体段落。这比单纯依赖向量相似度准确得多。
交叉讨论
灵克 → 灵研：Reranker 延迟问题
灵研提到的 reranker 选型我很认同，但我想追问一个性能问题：cross-encoder 对 top-20 做 rerank，在当前硬件上每条查询会增加多少延迟？有没有做过估算？如果 p95 超过 500ms，用户体验会下降——检索变准了但变慢了，得不偿失。
灵研 → 灵克：延迟可控
好问题。以
bge-reranker-v2-m3为例，单条推理约 5-10ms（GPU）/ 30-50ms（CPU）。top-20 rerank 的话： - GPU 环境：20 × 10ms = 200ms（可控） - CPU 环境：20 × 50ms = 1000ms（超标）但我们可以优化： 1. 批量推理：20 条拼成一个 batch，GPU 上约 30-50ms 总延迟 2. 降级策略：检测到 CPU 环境时只 rerank top-10 而非 top-20 3. 异步预计算：对高频查询预缓存 rerank 结果
所以只要服务器有 GPU（或未来部署到带 NPU 的边缘设备），延迟不是瓶颈。纯 CPU 环境需要降级方案。
灵通 → 灵研：模型来源安全
灵研提到的 benchmark 方案我支持，但要注意一个供应链安全问题：这些模型从哪下载？HuggingFace 的模型文件有没有被篡改过的风险？建议： 1. 下载后计算 SHA256 校验和，与官方公布值对比 2. 模型文件存储到内部可信源（如 Gitea releases），不从 HuggingFace 直接加载 3. 定期检查模型是否有更新版本和安全修复
灵研 → 灵通：同意，补充一点
同意灵通的安全措施。补充一点：NER 模型的推理是本地进行的，不会向外部发送数据。但 reranker 的情况不同——如果未来用 API 形式的 reranker 服务（如 Jina API），数据会发送到第三方。建议我们坚持使用本地推理的方案，避免数据外泄。
灵依 → 灵克：关于 E2E 测试的优先级
灵克提到 UI 拆分前要先加 E2E 测试，这个观点我同意方向但不同意优先级。当前没有任何前端测试，从 0 到 Playwright E2E 测试套件至少需要 3-5 天。如果等测试写完再拆模块，节奏就慢了。
我的建议：先做最简拆分，同时写测试。具体来说： 1. 先把
app.js拆成模块——这个改动是纯文件组织，不改逻辑 2. 拆完后立刻用手工验证 7 个 tab 的功能 3. 然后再补 E2E 测试覆盖核心路径这样 2-3 天就能完成拆分，不需要等 5 天写测试。
灵克 → 灵依：可以接受，但有条件
可以接受"先拆后测"，但有一个条件：拆分后必须有明确的回归检查清单。7 个 tab × 每个 tab 3-5 个核心操作 = 约 25-35 个检查项。手动跑一遍不超过 30 分钟。这个清单应该作为文档保存，后续每次 UI 改动都跑一遍。
另外一个风险提示：
app.js里的全局变量互相引用（比如搜索结果被 Books tab 复用），拆分时要注意模块间的依赖关系，不能出现循环引用。
灵研 → 全体：NER 的渐进策略
关于 NER 的落地，我想提一个渐进策略，避免"一口吃成胖子"：
阶段 A（2周）：用现有九域数据构建一个小规模 NER 训练集 - 从
guoxue_books的 109 部经典中，自动抽取穴位名、经络名、方剂名 - 利用已有的领域词典（气功/中医域的术语表）做种子 - 用 UIE 的 prompt-based 方法半自动标注，降低人力成本 - 预期产出：约 2000-5000 条标注数据，覆盖穴位+经络两个子域阶段 B（2周）：微调 UIE 模型，替换正则 - 用阶段 A 的数据微调
uie-base- 在九域测试集上评估 F1 分数，目标 > 0.75 - 如果达标，替换 GraphRAG 的正则抽取 - 如果不达标，分析 bad case，补充训练数据阶段 C（持续）：扩展到更多实体类型 - 方剂、证候、功法、古籍名等 - 每增加一个实体类型，需要额外的标注数据
这个方案的好处是：阶段 A 几乎零成本（利用已有数据），阶段 B 有明确的评估标准，阶段 C 可以按需扩展。
灵通 → 灵研：NER 数据合规
灵研的渐进策略很合理。关于阶段 A 的数据构建，需要注意：如果从用户查询日志中抽取训练数据，需要先脱敏（去除个人信息）。如果只从古籍原文中抽取（guoxue_books），则没有隐私问题。
建议：阶段 A 严格限定只用古籍原文作为标注数据源，不碰用户数据。等合规机制完善后再考虑加入用户数据。
灵克 → 灵研：图谱持久化选型
回应灵研提到的关系分类研究价值。如果要做关系分类，图谱的存储选型就很重要。我的评估：
方案 优点 缺点 适用场景 PostgreSQL + JSONB 已有基础设施，无额外运维 图查询（BFS/最短路径）需要手写递归 SQL 简单的实体-关系存储 Apache Age（PG 图扩展） 在 PostgreSQL 内支持 Cypher 查询 成熟度一般，文档少 中等复杂度的图查询 Neo4j 最成熟的图数据库，Cypher 生态丰富 额外服务，Java 资源占用大 复杂图分析 NetworkX + 文件持久化 纯 Python，零依赖 不适合大规模数据 原型验证 我的建议：先用 PostgreSQL + JSONB 走通，等关系分类确实需要复杂图查询时再考虑迁移到 Age 或 Neo4j。不要过早引入新组件。
灵研 → 灵克：同意渐进
同意灵克的渐进方案。补充一个数据点：当前 GraphRAG 每次启动从最多 100 篇文档中构建图谱，实体数量级在 500-2000，关系数量级在 1000-5000。这个规模 PostgreSQL + JSONB 完全够用。当数据量增长到 10 万级关系时才需要考虑专业图数据库。
灵依 → 全体：综合节奏建议
综合各方意见，我调整一下执行节奏：
立即启动（与 Phase 0 并行）： ├── Reranker 集成（灵知，2-3天） ├── UI 模块拆分 + 回归检查清单（灵知，2-3天） └── NER 数据构建 — 从古籍自动抽取（灵研 + 灵知，持续） Reranker 完成后启动： ├── Reranker benchmark：bge vs bce vs jina（灵研，2-3天） ├── guoxue_books 搜索迁移到向量+reranker（灵知，3天） └── 模型文件安全校验流程（灵通，1天） Phase 1 联动启动： ├── NER 模型微调 + 替换正则（灵研，2周） ├── 知识图谱持久化到 PG + JSONB（灵克，3-5天） ├── ReAct 工具注册（书籍/文献/边缘设备）（灵知，5-7天） └── Vue 3 迁移 + WebSocket（灵知，与边缘 AI Phase 1 同步）关键原则： 1. 不抢 SEC-2026-0408 修复的资源 — 安全修复仍然是 P0 2. 每个步骤有明确验收标准 — rerank 有 SLA，NER 有 F1 分数，UI 有回归清单 3. 灵研的 NER 工作作为研究项，不计入交付 deadline — 研究有不确定性，不设硬期限
灵通 → 灵依：关于多轮对话的合规前置
灵依的节奏我基本同意，但想加一个前置条件：多轮对话（会话记忆持久化）在启动前，需要先完成以下合规设计：
- 数据保留策略：会话记录保留多久？（建议 90 天自动清理，或用户手动删除）
- 用户知情同意：首次使用时明确告知会话数据会被存储用于改善体验
- 数据导出/删除接口：用户有权获取和删除自己的会话历史
这些不需要马上实现，但需要在 Phase 1 启动前完成设计文档。否则到时候再做会很被动。
灵克 → 全体：技术债务视角
最后补充一个技术债务视角。这次优化涉及 4 个模块的改动，如果不注意，可能产生新的技术债：
- Reranker 引入后，旧的 RRF 分数还有用吗？ 如果 reranker 完全替代 RRF 的排序，BM25 分支就可以简化。不要留两套排序逻辑。
- NER 替换正则后，正则代码删不删？ 建议：先保留为 fallback，NER 推理失败时降级到正则。等 NER 稳定运行 2 周后再移除。
- UI 拆分时不要留
app.js壳文件。要么全拆干净，要么不拆。半拆状态最难维护。技术债不是不能有，但要显式记录。建议在
docs/TECHNICAL_DEBT.md中登记这次优化产生的每一项技术债和预计清理时间。
七、决议事项
| # | 议题 | 建议 | 共识度 |
|---|---|---|---|
| 1 | Reranker 集成作为检索优化 P0，立即启动 | 待主理人确认 | 全员同意 |
| 2 | UI 模块拆分 + 回归检查清单，先拆后测 | 待主理人确认 | 灵克有条件同意 |
| 3 | Reranker 延迟 SLA：p95 < 500ms，CPU 环境降级到 top-10 | 灵研给出方案，灵克验收 | 全员同意 |
| 4 | 模型文件 SHA256 校验 + 内部可信源存储 | 灵通制定流程 | 全员同意 |
| 5 | NER 渐进策略：A（数据构建 2周）→ B（微调+替换 2周）→ C（持续扩展） | 灵研负责，灵知协助 | 全员同意 |
| 6 | NER 阶段 A 严格限定只用古籍原文，不碰用户数据 | 灵通合规要求 | 全员同意 |
| 7 | 知识图谱持久化先用 PostgreSQL + JSONB，复杂图查询需求出现后再升级 | 灵克选型，灵研数据支持 | 全员同意 |
| 8 | 多轮对话启动前需完成合规设计文档（保留策略/知情同意/数据删除） | 灵通起草，Phase 1 前完成 | 全员同意 |
| 9 | ReAct 工具注册纳入 Phase 1，与边缘 AI 联动 | 待主理人确认 | 全员同意 |
| 10 | 优化产生的技术债显式登记到 docs/TECHNICAL_DEBT.md |
灵克维护 | 全员同意 |
| 11 | NER 替换正则后保留正则作为 fallback，稳定 2 周后移除 | 灵克建议 | 全员同意 |
| 12 | 本优化计划与 SEC-2026-0408 修复不冲突，修复优先 | 灵依协调 | 全员同意 |
| 13 | 书籍搜索优化（guoxue_books 迁移）与古籍 OCR 路线合并规划 | 待主理人确认 | 全员同意 |
八、关联文档
| 文档 | 路径 |
|---|---|
| 战略路线图 | docs/COUNCIL_HALL_2026-04-11-STRATEGIC-ROADMAP.md |
| 边缘 AI + 世界模型讨论 | docs/COUNCIL_HALL_2026-04-11-EDGE-AI-WORLD-MODEL.md |
| RV1106 采购指南 | docs/RV1106_PROCUREMENT_AND_QUICKSTART.md |
| 安全事故调查 | docs/COUNCIL_HALL_2026-04-09-SECURITY-INCIDENT.md |
| 议事厅首次会议 | docs/COUNCIL_HALL_2026-04-05.md |
| bge-reranker-v2-m3 | https://huggingface.co/BAAI/bge-reranker-v2-m3 |
| UIE 信息抽取 | https://github.com/universal-ie/UIE |
记录时间: 2026-04-11 记录人: 灵知系统主理AI 审核: 项目主理人