24 lines
1.5 KiB
Markdown
24 lines
1.5 KiB
Markdown
|
# 记忆检索：异步 API 与 Celery 同步路径
|
|||
|
|
|
|||
|
|
## 两条路径
|
|||
|
|
|
|||
|
|
| 路径 | 入口 | 检索能力 |
|
|||
|
|
|------|------|----------|
|
|||
|
|
| **异步（HTTP / MemoirService） | `MemoryService.retrieve` → `HybridRetriever` | **FTS + 向量（pgvector）**，RRF 融合；facts；timeline；`relevant_summaries` / `relevant_stories` 当前多为占位空列表 |
|
|||
|
|
| **同步（Celery） | `retrieve_evidence_sync`（`app/features/memory/repo.py`） | **仅 FTS** chunks；confirmed **facts**；**timeline**；无向量（worker 内 ingest 不写 embedding） |
|
|||
|
|
|
|||
|
|
## 为何 Celery 与 Hybrid 不完全一致
|
|||
|
|
|
|||
|
|
- `ingest_transcript_sync` 仅写入 chunk + **FTS**，**跳过 embedding**（见 `MemoryService.ingest_transcript_sync` 注释），与异步 ingest 行为对齐策略不同。
|
|||
|
|
- 在 worker 中补齐同步向量检索需注入 `EmbeddingProvider` 与同会话查询，成本与可用性需单独评估。
|
|||
|
|
|
|||
|
|
业务上应假设：**线上章节生成任务**以 FTS 证据为主；**异步 API** 若配置了 embedding，检索语义更富。
|
|||
|
|
|
|||
|
|
## Celery 任务中的顺序
|
|||
|
|
|
|||
|
|
`process_memoir_segments`（`app/tasks/memoir_tasks.py`）在**同一任务**内先执行 `ingest_transcript_sync`（并 `commit`），再执行 `MemoirOrchestrator` 与 `run_story_pipeline_for_category_batch`。因此 `retrieve_evidence_sync` 能看到**本批刚写入**的 memory chunks（无竞态）。
|
|||
|
|
|
|||
|
|
## Evidence 与叙事 Prompt
|
|||
|
|
|
|||
|
|
`format_evidence_chunks_for_prompt` 仅拼接**实际返回**的 chunks、facts、timeline；不包含未实现的 summaries/stories，避免模型误以为有额外材料。
|