P3.9 — guoxue_content 嵌入可行性评估

日期: 2026-04-03 状态: 评估完成，建议执行

现状

指标	值
表大小	4.95 GB
行数	263,767
embedding 列	不存在
平均行大小	~19KB (body 文本)
现有索引	PK(id), book_id, book_id+chapter_id, GIN(body前200字符 trigram)

表结构

CREATE TABLE guoxue_content (
    id SERIAL PRIMARY KEY,
    book_id INTEGER NOT NULL,
    chapter_id INTEGER DEFAULT 0,
    body TEXT,                          -- 正文内容
    body_length INTEGER GENERATED ALWAYS AS (length(body)) STORED,
    source_table VARCHAR(20),
    created_at TIMESTAMP DEFAULT NOW()
);

嵌入方案

方案 A：全文嵌入（推荐）

对 body 列生成嵌入向量，支持语义搜索。

步骤: 1. ALTER TABLE guoxue_content ADD COLUMN embedding vector(512); 2. 批量生成嵌入（复用 generate_guji_embeddings.py 脚本逻辑） 3. 创建 HNSW 索引 4. 接入检索 API

预估: - 嵌入生成时间：263k 行 × ~4.2行/秒 = ~17.3 小时（CPU），或 GPU 下 ~2 小时 - 嵌入列存储：263k × 512 × 4 bytes = ~512 MB - HNSW 索引：~400-500 MB - 总磁盘增量：~1 GB

风险: - body 列平均 19KB，部分行可能超过 BGE-M3 8192 token 限制 - 需对超长文本做截断或分段处理

方案 B：摘要嵌入

对 body 前 512/1024 字符生成嵌入。

优势: 速度快、存储小 劣势: 丢失正文细节语义

方案 C：分段嵌入（高精度）

将长文本按段落/句子分段，每段生成嵌入，存储到新表 guoxue_content_chunks。

优势: 最高检索精度 劣势: 存储膨胀（~5-10x），需新建表和关联逻辑

建议

采用方案 A（全文嵌入），对超长文本截断至前 8192 token。

理由： 1. 与 guji_documents 方案一致，维护成本低 2. 512 MB 额外存储可接受（数据库 13 GB → 14 GB） 3. HNSW 索引在 263k 规模下查询延迟 < 5ms 4. 与现有 hybrid retrieval 架构直接兼容

执行计划

步骤	命令	预估时间
1. 添加列	ALTER TABLE guoxue_content ADD COLUMN embedding vector(512)	即时
2. 批量生成	修改 generate_guji_embeddings.py 适配 guoxue_content	~17 小时
3. VACUUM	VACUUM ANALYZE guoxue_content	~10 分钟
4. 建 HNSW 索引	CREATE INDEX CONCURRENTLY ...	~30 分钟

前置条件: guji_documents 嵌入完成（当前 13.3%，约 15 小时后完成） 建议启动时间: guji_documents 完成后立即启动