从「会算」到「会想」：一个 AI 量化驾驶舱的知识库设计与实战

从「会算」到「会想」一个 AI 量化驾驶舱的知识库设计与实战本文是《RAG 知识库构建让智能体越用越聪明》0. 背景为什么一个量化驾驶舱需要知识库先说业务再谈技术——这是面试官和读者最买账的切入点。我们的产品是面向A 股散户的 AI 量化交易分析系统核心模块是一个叫「智能驾驶舱」的 Dashboard。它的使命很朴素用一块屏、10 秒把 10 数据源指数、涨跌停、北向资金、估值分位、板块轮动压缩成一句今天该进攻还是防守的判读再叠加风险预警。但早期的驾驶舱有个致命特征它是一个「无状态实时计算器」。每次刷新Agent 都从零开始分析实时行情今天的分析和昨天的分析零传承投资人看完仍然看不懂市场、管不住情绪、看不准因子、找不准关注点。换言之它只是个更好的东方财富没有体现出 AI 的智能二字。这就引出了知识库设计的根本动机我们早已沉淀了投资纪律、历史决策、因子库但它们在系统中睡觉。设计的全部努力就是让驾驶舱从看清行情升级为有记忆、守纪律、能自省的随身投资教练。1. 家底盘点现有 4 类知识载体动手设计前先摸清已有什么。项目里backend/app/knowledge/下其实已经搭好了知识底座(1) 向量库VectorStoreChromaDB6 个集合— 知识底座。COLLECTION_CONFIGS { market_analysis: 每日市场分析报告DashboardAgent 输出, scan_decisions: 扫描决策记录ScannerAgent 操作建议, daily_reports: 交易日报ReporterAgent 输出, investment_rules: 投资规则与经验教训, factor_history: 每日因子列表, memory_docs: ai-memory 结构化记忆文件精确检索优先语义兜底, }下面三类都是它的语义包装。(2) 投资规则库RuleStore→investment_rules—唯一已预置真实内容的知识库7 条经典纪律DEFAULT_RULES [ {rule: 止损纪律个股亏损达到止损线时必须执行减仓或止损, category: risk_management, priority: 1}, {rule: 趋势为王大盘偏空时降低仓位偏多时正常持仓, category: trend_following, priority: 1}, {rule: 量价配合上涨放量看多上涨缩量谨慎下跌放量恐慌下跌缩量企稳, category: technical, priority: 2}, {rule: 板块联动持仓所属板块大涨时持有板块转弱时减仓, category: sector, priority: 2}, {rule: 不追涨停涨停板不追等回调确认后介入, category: risk_management, priority: 2}, {rule: MACD金叉参考日线MACD金叉可作为加仓信号死叉作为减仓信号, category: technical, priority: 3}, {rule: 北向资金参考北向大幅净流出时整体谨慎大幅流入时关注机会, category: macro, priority: 3}, ](3) 因子库FactorStore→factor_history— 影响股价的关键驱动因素政策利好、量价背离、板块轮动。结构 ready内容靠 Agent 跑起来后写入。(4) 决策日志DecisionLog收编进local_storeSQLite— 记录 ScannerAgent 每次操作建议并支持回填结果验证reconcile_decisions是越用越聪明的关键。def log_decision(self, stock_code, action, reason, stock_name, price0, confidence0, agent_nameScannerAgent, date) - int: 记录一条决策返回记录 ID。 ... record DecisionLogRecord(datedate, stock_codestock_code, stock_namestock_name, actionaction, reasonreason, price_at_decisionprice, confidenceconfidence, agent_nameagent_name) db.add(record); db.commit(); db.refresh(record) return record.id2. 知识库子系统架构盘点完有什么要回答怎么组织。知识库不是一个单点而是一个分层子系统。2.1 知识库子系统内部架构知识库自己是一个访问层 存储层的两层结构┌──────────────────────────────────────────────────────────┐ │ 访问层语义化接口 │ ├──────────┬───────────┬────────────┬───────────────────────┤ │ RuleStore│ FactorStore│ DecisionLog│ VectorStore │ ← 上层只关心取规则/取因子/取决策/检索相似 ├──────────┴─────┬─────┴─────┬──────┴───────────┬───────────┤ │ ChromaDB │ │ SQLite │ ChromaDB │ ← 存储层向量 关系型 混合 │ (向量·语义) │ │ (结构化·事实) │ (向量·语义) │ └────────────────┴───────────┴──────────────────┴───────────┘存储层向量库ChromaDB负责语义相似检索关系库SQLite负责结构化事实与聚合。访问层四个 Store 把底层存储细节屏蔽对上层提供统一的语义接口。注意上图只是知识库自己的结构。它如何被使用——谁来读、谁来写、何时进 Agent——是下一节§2.4三方协作要回答的。2.2 架构关键决策向量 关系型「混合存储」一个常被问到的问题决策日志为什么不用 ChromaDB 存而用 SQLite因为二者职责不同数据类型典型操作该用投资规则 / 历史情境 / 因子语义相似检索、找最像今天的向量库ChromaDB决策记录按 id 回填结果、按日期/结果聚合统计、算准确率关系库SQLite向量库擅长近似匹配但极不擅长结构化聚合近 30 天验证了多少、证伪了多少这种 GROUP BY 它做不了还得回查全部再在内存算。所以我们坚持混合存储语义检索用向量事实聚合用 SQL。这也是DecisionLog最终从独立 SQLite收编进统一local_store的原因——结构化数据统一管理。2.3 两个「记忆系统」的边界容易混淆项目里其实有两套记忆必须分清产品知识库backend/app/knowledge/——运行时给 Agent 和终端用户用的领域知识规则、因子、决策、市场分析。开发记忆体ai-memory/——开发期给 AI 自身回忆用的工程记忆文件即记忆 L1/L2/L3 ChromaDBmemory_docs集合。二者通过VectorStore的memory_docs集合桥接ai-memory的 Markdown 被索引进产品 KB 的 ChromaDB供语义兜底检索。但业务上它们是两条平行线——别把AI 的开发笔记当成给散户看的投资知识混为一谈。2.4 Service、Agent 与知识库的三方协作这是整个架构最关键的视角也是后面死库问题的根源。先给一张端到端协作图┌──────────────────────────────────────────────┐ │ DashboardService编排者 │ │ ① 取实时数据 ② 预取知识 ③ 组装 prompt │ │ ⑤ 解析输出 ⑥ 写回知识库 ⑦ 返回前端 │ └───┬───────────────┬───────────────┬──────────┘ │ │ │ ① 实时数据 │ ② 检索 / 写回 │ ③ 组装好的 prompt ▼ ▼ │ ┌──────────────┐ ┌──────────────┐ │ │ DataAggregator│ │ 知识库(4 Store)│ │ │ (Sina / CLS) │ │ ChromaDBSQLite│ │ └──────────────┘ └──────┬───────┘ │ │ ④ 注入的知识只在 prompt 里 │ ▼ │ ┌──────────────────┐ │ │ DashboardAgent │ │ │ (tools[] 直调) │ │ │ 纯推理单元 │ │ └────────┬─────────┘ │ ⑤ 结构化输出(JSON) └───────────────┘(1) Service ↔ Agent编排者 与 被调用的推理函数DashboardAgent是tools[]的直调模式——它不持工具、不持状态、不主动检索本质是一个给定 prompt → 产出结构化 JSON 分析的纯推理函数。真正的主控是DashboardService它负责数据获取调DataAggregator、知识预取、prompt 组装、调用 Agent、解析输出、持久化落库。一句话Service 是大脑决定用什么知识、怎么问Agent 是嘴巴只负责按 prompt 作答。(2) Agent ↔ 知识库零直接耦合全靠 Service 中介Agent从不直接访问知识库。知识库的两条通路都由 Service 代理读取通路KB → Service(检索/预取) → prompt → Agent。Agent 看到的知识是 Service 喂进 prompt 的那一段上下文它自己无从主动查询。写入通路Agent 输出 → Service(解析) → KB(store_agent_output)。Agent 产出的分析由 Service 落库到market_analysis。所以对 Agent 而言知识库只是prompt 里的一段文本——它既不知道知识来自哪个集合也不知道背后有向量检索。这种解耦带来两个好处Agent 可替换换模型不影响知识逻辑、知识逻辑可单测检索在 Service 里不依赖 LLM。(3) 为什么这正好是死库的根源回头看 §3 的痛点就清楚了项目早就有了写入通路Service 把 Agent 结果store_agent_output进market_analysis但始终缺了读取通路Service 调用 Agent 前从未先去 KB 检索并注入。于是知识只进不出。我们这次设计的核心动作就是在 ② 处补上调用 Agent 前先检索知识并注入 prompt——把断开的环闭合。3. 核心问题知识库成了「写而不读」的死库盘点完家底真正的痛点浮出水面——整条 Dashboard 链路没有任何一处读取知识库。看DashboardAgent的 prompt 构造def _build_dashboard_prompt(sd: DataBundle) - str: 将 DataBundle 格式化为 Agent 分析 prompt。 parts [请基于以下实时市场数据进行五步分析法宏观策略分析输出JSON。\n] # 指数 / 涨跌停 / 北向 / 板块 / CLS热点 / PE —— 只注入实时行情 ... return \n.join(parts) if parts else 市场数据暂不可用请降低置信度输出。prompt 里只有实时数据没有一条规则、一段历史、一条决策。而分析完的结果却被写进了库# RAG 闭环将 Agent 分析结果存入 market_analysis if agent_result.get(output): store_agent_output(collectionmarket_analysis, contentagent_result[output][:1500], metadata{date: ..., agent: DashboardAgent, ...})写进去了但再没人读它。RuleStore、FactorStore、DecisionLog三者与 Dashboard 完全断开。一句话痛点知识库躺在 ChromaDB 里睡觉驾驶舱每次刷新从零算今天的智慧和昨天零传承。4. 设计目标与价值主张投资者视角设计不是多一个功能而是把四个业务诉求一一落地投资者诉求知识库如何回应对应知识类型认识市场此刻是牛市中段还是熊市反弹用「当前市场画像」检索历史上最像今天的日子给出后续演变参照② 相似市场情境把控情绪恐慌割不割、狂热追不追7 条投资纪律作硬约束注入用规则替投资者踩刹车① 投资纪律规则看准因子什么在驱动行情真利好还是噪音沉淀每日因子 自省近期判断准不准看清驱动逻辑③ 决策经验回流找准关注点今天盯北向、板块还是估值前端「知识洞察」卡把注意力收敛到关键信号④ 前端知识洞察卡一句话价值把个人的、临场的、易情绪化的判断升级为有历史记忆、守纪律、能自省的系统能力。5. 总体架构4 类知识的「注入 呈现」闭环实时行情(sd) │ ├─① 投资纪律规则 ──► RuleStore.get_all_rules() ──┐ ├─② 相似市场情境 ──► market_regime 检索(向量) ├─► 拼入 DashboardAgent prompt ├─③ 决策经验回流 ──► DecisionLog.stats() 近期成败 ──┘ │ └─④ 前端知识洞察卡 ◄── 新增 /api/dashboard/knowledge-context①②③ 是注入型知识进入 LLM 推理上下文。④ 是呈现型知识前端显式展示不进 prompt避免 token 浪费。关键设计原则与现有架构一致知识检索在Service 层预取后注入 prompt不碰 Agent 的tools[]尊重已有的直调模式决策。6. 详细设计四类知识逐一落地6.1 投资纪律规则Knowledge ①硬约束来源RuleStore→investment_rules已预置 7 条止损/趋势/量价/板块/不追涨停/MACD/北向。检索策略全量注入规则少约 7–30 条。进阶按当前 regime 过滤 category偏空时优先risk_management。注入位置直接进DASHBOARD_SYSTEM_PROMPT的必须遵守以下投资纪律段作为硬性约束。效果分析天然遵守纪律而非每次靠 LLM 随机发挥。即使检索到的历史案例建议进攻只要与偏空减仓纪律冲突纪律压住参考。6.2 相似市场情境Knowledge ②核心价值 · 软参考这是让驾驶舱有记忆的灵魂。用当前市场画像检索历史上最像今天的日子把当时之后 3–5 天的演变喂给 Agent。市场画像Market Regime Signature——可向量化的每日特征字段来源上证/深证/创业板 涨跌幅sd.indices涨跌家数比breadth_ratiosd.advancing/(advancingdeclining)涨停/跌停比sd.limit_up/limit_down北向净流入归一化sd.north_amount领涨板块sd.sectors[:3]上证 PE 分位sd.sh_pe[pct]存储集合新增market_regime每条文档带outcome 标签document: 市场画像: 上证1.2%, 涨跌比62%, 涨停80/跌停20, 北向45亿, 领涨AI/半导体... metadata: { date: 2026-07-29, signature: {sh_chg, breadth_ratio, limit_up_ratio, north_norm, pe_pct, top_sector}, outcome_3d: null, # T3 后回填上证 3 日累计涨跌幅 outcome_label: null # 验证偏多 / 证伪 / null }写入与回填流水线时机动作每日首次/market刷新后DashboardService构建当日market_regime文档upsert by date夜间定时任务T3用温层指数 K 线算 T3 收益率按 date 更新outcome_3d/outcome_label检索算法用当前 sd 构建今日画像文本 → 同一 EF embedding →query(top_k3~5, 仅返回已带 outcome 的历史日)。最小数据护栏重要若历史带 outcome 的文档 20 条优雅跳过注入。小样本检索无统计意义反而污染分析。早期靠护栏过渡样本足了自动生效。6.3 决策经验回流Knowledge ③自省来源DecisionLog.stats()返回{verified, falsified, pending, accuracy}query_recent(limit, outcome)取近期验证/证伪样本。注入内容近期决策准确率 X%对[北向/小盘]类判断偏[准/不准]请相应调整该类信号权重。效果Agent 知道自己的近期偏差动态调节信号权重——自省闭环呼应已落地的reconcile_decisions。6.4 前端「知识洞察」卡Knowledge ④呈现新增KnowledgeInsight.vue 端点/api/dashboard/knowledge-context三块展示遵守的纪律规则条数 关键几条历史相似情境3 例绿/红标 outcome决策准确率近 30 天与AccuracyPanel同源7. 技术选型为什么是这套组合技术选型不是追新而是贴合单机、中文、A 股、结构化语义混合这四个约束。维度选型为什么选它否决的替代向量库ChromaDB嵌入式单机部署免服务器内置 onnxruntime default embedding免下载集合模型简单Milvus / Qdrant集群级过重EmbeddingBGE-small-zh-v1.5中文优化降级 ChromaDB defaultA 股文本以中文为主通用英文模型召回差本地缓存模型可切换纯英文 embedding中文语义坍塌结构化存储SQLitelocal_store决策需按 id 回填 聚合统计SQL 擅长全塞进 ChromaDB聚合灾难检索实现直接query调用非 LangChain RAG chain保持显式、可单测、检索逻辑可控黑箱 RAG 框架难调试、难评审注入实现Service 层字符串模板拼接不引入框架prompt 结构可评审、可 diff自动拼接链不可控几个选型背后的权衡为什么不直接上 pgvector / Milvus温层数据宏观时序、K 线后续规划入 PG但知识库先用轻量 ChromaDB——知识检索是低频、小数据量场景没必要为一棵树引入一片森林。为什么 embedding 要中文模型投资规则、因子描述、市场分析全是中文。我们用 BGE-small-zh 并在本地缓存没下载到时自动降级 ChromaDB 默认 embedding——可用性优先质量次之可平滑升级。为什么不用 RAG 框架框架的自动检索-拼接会把检索逻辑变黑箱。我们宁可手写query 模板拼接换取每一行注入都可测试、可评审。8. 知识库与提示词的关系RAG 的两半这是整个设计里最容易被忽视、却最决定成败的一点。8.1 一句话关系知识库决定往 prompt 里塞什么提示词工程决定怎么塞、塞在哪个位置、怎么让模型用起来。二者合起来才是完整的 RAG。很多 RAG 项目只优化检索向量、chunk、rerank却忽略检索到的内容放错位置等于没检索。8.2 知识类型 → prompt 位置的映射这张表是整个 KB↔Prompt 设计的核心知识类型注入位置为什么是这个位置① 硬规则System Prompt常驻要对所有对话生效、不被长上下文挤出注意力是不可违背的人设/纪律② 软情境User Context动态随市场状态变化、可灵活增删放进 user 才能今天像 2024-09明天像 2025-03③ 自省经验User Context 的反思段属于对当前分析的补充约束动态生成④ 前端卡不进 prompt纯呈现进 prompt 纯浪费 token我们的硬约束 / 软参考分离本质就是一条提示词工程决策硬规则进 system压舱石、永不被覆盖软情境进 user风向标、灵活可变。这一分法同时解决了知识放哪和冲突时谁优先两个问题。8.3 张力注入多少才合适塞太多token 浪费 注意力稀释——上下文越长模型越容易忽略中段内容lost-in-the-middle。塞太少知识库形同虚设回到无状态计算器。我们的平衡策略① 全量量小、必填② 仅 top-k3~5 且带 outcome③ 仅近期 2–3 条④ 直接剥离到前端不进 prompt。分层 最小护栏 呈现分离正是为这个张力服务的。8.4 与提示词课程的呼应本项目另有提示词工程课程prompt/SYSTEM_PROMPT_DESIGN.md、prompt/COURSEWARE.md。知识库可以理解为提示词工程的外挂记忆system prompt 定义你是谁、守什么纪律知识库在运行时动态补充此刻该参考哪段历史。二者正交、互补缺一不可。9. 工程落地关键点踩坑与权衡9.1 为什么是「Service 层注入」而非「Agent 挂 tools」DashboardAgent是tools[]直调模式。两个选择方案优点缺点给 Agent 挂toolsRAG 工具灵活Agent 自主决定查不查不可控、难单测、检索逻辑随对话漂移Service 层预取后注入 prompt✅低侵入、好单测、检索可复用、不破坏直调架构需 Service 自己编排检索逻辑我们选后者知识检索是确定性编排不该交给 LLM 自由发挥。这也让注入什么知识成为可测试、可评审的工程决策而非 LLM 的黑箱行为。9.2 embedding 一致性护栏检索与写入必须共用同一个embedding_functionBGE-small-zh 或 ChromaDB 内置 default。否则写进去和查出来不在同一向量空间相似度全失效——这是 RAG 隐性 bug排查极难。9.3 最小数据护栏RAG 上线初期样本极少硬检索等于用 3 个样本下结论。护栏N20 跳过是工程上最务实的处理也让系统诚实地说我不知道。10. 工程鲁棒性当知识库「说谎」或「自相矛盾」知识库不是信仰而是带置信度、可溯源、能被市场证伪的参考系。10.1 知识之间矛盾如历史说进攻纪律说减仓优先级仲裁硬规则人工审核、可信度高 软情境检索、带相似度置信度。冲突时规则压参考并让 LLM显式输出裁决依据我注意到历史 X 与纪律 Y 冲突按纪律取舍。置信度加权聚合top-k 检索先做一致性投票相似度低于阈值的直接丢弃若 k 条多数指向相反宁可降级为无强信号也不强行给结论。强制引用溯源prompt 要求每条结论必须标注来自哪条知识 / 哪个 date把黑箱变可复核。10.2 知识本身不准确过时、噪声、证伪样本衰减机制outcome_label证伪的样本在后续检索中降权验证过的加权——错误记忆被市场自我修正。事实 vs 解读分层关键数字涨跌停、北向永远以实时 API 为准知识库只做解读不做事实源从根上避免数值错误污染决策。闭环自净用reconcile_decisions把预测与真实结果回填错误自动暴露、准确率面板量化——一套持续校准机制。护栏兜底样本不足不检索写入/检索 embedding 一致chunk 策略固定。收尾话术所有优化都围绕一条——降低错误记忆进入决策的概率。11. 实战效果与验证Done 定义/market返回的分析里能观察到 Agent 引用了投资纪律①历史样本 ≥ 20 时prompt 注入相似历史情境段样本不足时优雅跳过② 护栏KnowledgeInsight卡展示纪律/相似情境/准确率三块④决策经验段出现在 prompt③前端vue-tsc零错误后端导入冒烟通过全程不破坏直调模式 / Service 层注入架构约定如何评估知识库真的有用不靠感觉更聪明而靠两个可量化信号①AccuracyPanel决策准确率随回填样本累积是否趋势上升自省闭环生效② 相似情境注入后Agent 输出是否出现当前类似 X 日彼时后续 Y这类可验证的参照表述记忆生效。没有度量知识库只是心理安慰。12. 总结与可迁移经验一句话收获知识库的价值不在存了多少而在有没有被用对地方、用对方式、用对位置。可迁移的五条经验先盘家底再谈设计我们不是从零造知识库而是发现已有知识在睡觉设计的核心是唤醒而非新建。混合存储语义检索用向量结构化事实与聚合用 SQL——别让向量库做它不擅长的事。硬约束 / 软参考分离规则是纪律压舱石进 system检索是参考风向标进 user二者必须分优先级与位置。知识库 提示词的外挂记忆RAG 效果 检索质量 × prompt 编排质量两者缺一不可。知识库必须可证伪带 outcome 标签、带置信度、能回填、能衰减——只有能被市场打分的记忆才配叫智能。这套方法论不止适用于量化驾驶舱任何AI 领域知识的产品客服、法务、医疗问诊都能套用「盘点既有知识 → 分层硬规则/软案例/自省经验→ 混合存储 → Service 层确定性注入 → 与提示词协同 → 鲁棒性与证伪闭环」这条主线。附面试如何讲这个项目速记版业务背景A 股散户驾驶舱早期是无状态计算器知识库写而不读。架构向量(ChromaDB)关系(SQLite)混合访问层四个 StoreService 层确定性注入。技术选型ChromaDB 嵌入式 BGE 中文 embeddingSQLite 管决策不引 RAG 框架。设计亮点① 硬约束/软参考分离system vs user② Service 层注入不碰 tools ③ 最小数据护栏 ④ outcome 标签闭环。KB↔Prompt知识库定塞什么提示词定怎么塞/塞哪RAG 两半缺一不可。矛盾处理优先级仲裁规则检索 置信度加权 强制溯源。不准确处理衰减机制 事实/解读分层 回填自净 embedding 一致性。设计稿权威版本见ai-memory/iterations/iter-012-cockpit-kb/design.md本文为其可发布实战版。