怎样用NotebookLM做资料消化和可引用结论提取
2026-07-15 3400933
2026-07-15 0
在AI回答采集系统中,原始回答的存储是后续分析、指标计算和复查的基础。如果存储设计不合理,数据丢失、格式混乱、无法追溯原始结果,会导致分析结论不可信。本文聚焦于如何设计一个可追溯的原始数据存储方案。

推荐使用JSON格式存储原始回答,原因:
对于文本类回答,也可同时保存纯文本副本,便于快速检索。
每条记录必须包含以下元数据字段:
| 字段 | 类型 | 说明 |
|---|---|---|
request_id | UUID | 全局唯一请求ID,用于关联请求与响应 |
platform | string | 采集平台,如“openai” |
model | string | 模型名称,如“gpt-4” |
question | text | 输入的问题 |
request_time | datetime | 请求发起时间 |
response_time | datetime | 响应接收时间 |
latency_ms | int | 响应耗时(毫秒) |
status | string | 响应状态,如“success”、“error” |
error_info | json | 错误信息(可选) |
version | int | 数据版本号,用于追踪结构变更 |
以下为示例表结构(PostgreSQL):
CREATE TABLE raw_responses (
id BIGSERIAL PRIMARY KEY,
request_id UUID NOT NULL UNIQUE,
platform VARCHAR(64) NOT NULL,
model VARCHAR(128) NOT NULL,
question TEXT NOT NULL,
request_time TIMESTAMPTZ NOT NULL,
response_time TIMESTAMPTZ NOT NULL,
latency_ms INTEGER NOT NULL,
status VARCHAR(32) NOT NULL DEFAULT 'success',
error_info JSONB,
raw_response JSONB NOT NULL,
text_response TEXT,
version INTEGER NOT NULL DEFAULT 1,
created_at TIMESTAMPTZ NOT NULL DEFAULT NOW(),
updated_at TIMESTAMPTZ NOT NULL DEFAULT NOW()
);
CREATE INDEX idx_raw_responses_platform ON raw_responses(platform);
CREATE INDEX idx_raw_responses_model ON raw_responses(model);
CREATE INDEX idx_raw_responses_request_time ON raw_responses(request_time);
CREATE INDEX idx_raw_responses_status ON raw_responses(status);字段说明:
raw_response:存储完整的JSON响应体,保留所有原始字段。text_response:提取的纯文本回答,便于快速查询和全文检索。version:当存储结构变更时递增,用于兼容旧数据。raw_response。raw_response字段存储未经任何处理的响应,确保可复现。raw_response与模型实际返回是否一致。request_id从原始表反查到分析结果,确认链路完整。原因:重试机制导致同一问题多次请求。
解决:在写入前检查request_id是否已存在,使用ON CONFLICT或唯一约束避免重复。
原因:raw_response体积大,且数据量大。
解决:对raw_response进行压缩(如JSONB默认压缩),定期归档旧数据到冷存储。
原因:不同服务器时区设置不同。
解决:统一使用UTC时间存储,展示时再转换为本地时间。
原始数据存储是AI回答采集系统的基石。通过合理的表结构、元数据设计和版本管理,可以保证数据可追溯、可复查、可重算。本文提供的方案适用于中小规模采集系统,实际部署时需根据数据量和查询模式调整索引和分区策略。