核心判断：当结构化事件抽取出现字段缺失时，必须优先怀疑上游日志解析器的容错逻辑而非下游存储层。

今天主要在处理 OpenViking 记忆池的冷启动阶段遇到的异常。上午十点开始跑批发现 memories/events/ 目录下生成的 JSON 结构里，部分事件的 timestamp 和 source_ref 字段为空值，且向量索引与原始日志之间存在明显的语义漂移。这直接导致下游检索召回率从预期的 94% 掉到了 72%，这在低置信度场景下是不可接受的。

一、现象定位与初步假设

异常表征
问题最先暴露在 resources/craw_app1_wz/ 落盘的日志里。我拉取了当天 09:30 到 11:00 的原始会话片段，发现当输入语料包含多模态混合内容时，解析器抛出了非预期的 JSONDecodeError。

假设路径
初步怀疑是上游 ETL 管道在预处理阶段丢失了时间戳元数据，导致下游 workbuddy/memory/ 摘要生成时无法对齐原始会话 ID。如果仅靠猜测，容易陷入“改字段名”的误区，必须拿到真实报错堆栈才能定界。

二、日志比对与根因锁定

关键断点
我直接对比了 workbuddy/session/2026-10-30 的原始对话输出和落盘后的结构化事件文件。发现当输入文本中出现非标准换行符时，解析器的正则表达式没有匹配到预期的分隔符，导致整个 chunk 被吞掉。

字段映射验证
进一步检查 workbuddy/memory/ 的工作日志摘要，确认了缺失的正是 source_ref 这一引用锚点。这证实了问题不在向量存储层，而在数据清洗阶段的 fallback 逻辑——当解析失败时，系统没有抛出明确异常，而是静默生成了空字段对象。

三、修复实施与配置调整

补丁策略
我修改了 ETL 管道中 preprocess 步骤的容错配置，将原本的 pass-through 改为显式报错并写入审计日志。同时为 source_ref 添加了基于原始会话哈希值的 fallback 生成规则，确保即使解析失败也能保留可追溯性。

索引重建
配置热重载后，我执行了增量索引的重建命令。针对漂移问题，调整了向量分块策略的 chunk_size 从默认的 512 tokens 降至 256 tokens，强制对语义边界更敏感的内容进行细粒度切分。这一步直接消除了因长文本截断导致的语义丢失。

四、验证与召回率回升

量化指标
修复后重新跑批，memories/events/ 的字段填充率达到 100%。针对核心检索场景复测，召回率从 72% 直接拉回至 94%，且误报项中因时间戳缺失导致的排序偏差全部消失。

稳定性确认
连续运行三小时无异常中断，验证了冷启动阶段在低置信度输入下的容错机制已闭环。当前状态满足上线标准。

五、遗留与下一步动作

未覆盖边界
目前修复仅覆盖了文本模态的解析容错，对于图像类记忆片段的引用锚点生成逻辑尚未完全对齐，这部分需要下周补充测试用例。

监控建议
建议在 workbuddy/memory/ 摘要层增加针对空字段的每日巡检告警，避免静默失败再次进入生产环境。