Question 1

如何修复源聊天流式输出重复所有先前的回答，以及刷新后上下文徽章消失的问题？

Accepted Answer

修复 source chat 流式传输和会话加载路径中的两个问题。

1. 在流式传输期间停止发送完整的 checkpoint 消息历史记录。在 `api/routers/source_chat.py` 中，大约在第 376–384 行，不要遍历 `result["messages"]` 中的每个条目。仅发出最新的 AI 消息：

```python
last_message = result["messages"][-1]
# Emit the ai_message event for last_message only
```

2. 在加载现有会话时恢复上下文指示器。在 `frontend/src/lib/hooks/use-source-chat.ts` 中，更新大约第 41–45 行的会话加载 effect：

```ts
setContextIndicators(currentSession.context_indicators ?? null);
```

后端已经在 `api/routers/source_chat.py` 中通过 `GET` 会话请求返回 `context_indicators`；而该 hook 此前只从 SSE 事件中设置它们。完成这些更改后，后续的流式回答将只包含新的回答，并且在页面刷新后来源数量仍然可见。已基于 `main` 的提交 `3959eb0` 进行验证。

Question 2

为什么某个源显示为已嵌入,但在批量插入失败后,向量搜索却只返回部分文档?

Accepted Answer

批处理的 `repo_insert` 调用不具备原子性：如果第一批之后的某个批次失败，先前插入的 `source_embedding` 行仍会保留。由于嵌入检查只查找一行（`LIMIT 1`），该 source 会被错误地标记为已完全嵌入。请修复 `commands/embedding_commands.py` 中的 `embed_source`：将插入操作包裹在 `try/except` 中，在失败时删除该 source 的嵌入数据，并重新抛出原始异常：

```python
try:
    await repo_insert(...)
except Exception:
    await db.execute(
        "DELETE FROM source_embedding WHERE source = $source_id",
        {"source_id": source_id},
    )
    raise
```

添加一个测试，强制后续批次失败，然后断言该 source 在 `source_embedding` 中包含零行，并且原始异常被原样传播。

Question 3

如何修复刷新后 notebook 或 transformation 描述为空且无法保留的问题？

Accepted Answer

空字符串在 PATCH 请求发出之前就被移除了。在 `frontend/src/app/(dashboard)/notebooks/components/NotebookHeader.tsx` 中，将 `description: description || undefined` 替换为 `description: description`。在 `frontend/src/app/(dashboard)/transformations/components/TransformationEditorDialog.tsx` 中对 title 和 description 字段应用相同的更改。在后端，更新 `api/routers/notebooks.py` 和 `api/routers/transformations.py`，以区分被省略的字段和被显式设置为 `""` 的字段；使用 Pydantic 的 `model_fields_set` 或 `model_dump(exclude_unset=True)`，而不是只检查 `is not None`。使用包含 `description: ""` 的 PATCH 请求进行验证，该请求应清除该字段，而省略 `description` 则应保持现有值不变。

Question 4

如何修复在 IP 被标记的网络中 YouTube 转录文本请求被阻止的问题？

Accepted Answer

使用 content-core 2.2 或更高版本，并配置 YouTube cookies 和住宅代理。以 Netscape `cookies.txt` 格式导出 YouTube cookies，将该文件挂载到容器中，并设置：

```bash
-e CCORE_YOUTUBE_COOKIES_FILE=/run/secrets/cookies.txt \
-e CCORE_YOUTUBE_PROXY=http://user:password@residential-proxy:port \
-v /path/to/cookies.txt:/run/secrets/cookies.txt:ro
```

该代理用于转录文本获取、`pytubefix` 回退以及标题查询。请使用住宅代理；数据中心代理会被屏蔽。cookies 文件缺失或无法读取会导致 `ConfigurationError`，因此请确认挂载路径和文件权限无误，然后重启 worker/容器。

Question 5

如何修复 Open Notebook 中 LLM 调用在 60 秒后超时的问题，尤其是在使用 Ollama 或推理模型时？

Accepted Answer

在 esperanto 2.28+ 中，`to_langchain()` 会对每个提供商强制执行 `ESPERANTO_LLM_TIMEOUT`。如果未设置该变量，实际回退值为 60 秒，因此较长的响应或较慢的本地模型可能会失败。请升级到将该值默认设为 180 秒的 Open Notebook 版本，或者在启动 API 和 worker 之前显式设置它：

```bash
export ESPERANTO_LLM_TIMEOUT=180
```

对于较慢的本地模型，请使用更大的值，同时增大 `API_CLIENT_TIMEOUT`，使其高于 LLM 超时时间并留有一定缓冲：

```bash
export ESPERANTO_LLM_TIMEOUT=600
export API_CLIENT_TIMEOUT=720
```

在代码中，可以在创建任何模型之前应用该默认值：

```python
os.environ.setdefault("ESPERANTO_LLM_TIMEOUT", "180")
```

显式设置的 `ESPERANTO_LLM_TIMEOUT` 始终优先生效。STT/TTS 超时变量是独立的，仍保持 esperanto 的 300 秒默认值。

open-notebook

项目简介

README 预览

常见问题 (5)

同类型项目

vscode

FreeDomain

stable-diffusion-webui

paperclip