标签：RAG · 开源项目 · 知识库 · 向量检索 · 私有化部署 · 数字人
摘要：Khoj 是 GitHub 上最受关注的开源「第二大脑」项目之一------3.7 万 Star、YC S23 出身、七个客户端。2026 年 4 月它关掉了云服务，主仓库也在 8 月停止提交。本文基于仓库源码、GitHub API 实测数据和官方公告，拆解它做对了什么、卡在了哪里，并对比我们在私有化实时语音知识库上的另一套取舍。
数据采集日期：2026-10-12。文中所有数字按来源分档标注，来源说明见文末附录。
一、三件先要说清楚的事
如果只看 Khoj 的 GitHub 首页，你会得到这样的印象：3.7 万 Star、支持 Obsidian / Emacs / 桌面 / 手机等七个客户端、可以完全自托管，README 里还写着「use Khoj right away at app.khoj.dev --- no setup required」。
但这些是过期信息。截至 2026 年 10 月 12 日，实际情况是：
- 云服务已经关停。 2026 年 4 月 15 日，Khoj 官方在 app.khoj.dev 挂出日落公告（sunset notice），停止托管服务。现在访问该域名，看到的只有这份公告。
- 主仓库已经停止提交。 默认分支最后一次 push 是 2026-08-02（commit
ae229ca），两个多月没有动静。GitHub 上最后一个 Release 是2.0.0-beta.28（2026-03-26）------2.0 从来没出过稳定版 ；PyPI 上pip install khoj拿到的仍然是 2025-07-15 发布的 1.42.10。 - 团队已经转向。 公告原文：「We're focusing our efforts on Open Paper ，a research assistant ... and Pipali，an AI coworker」。这两个新仓库在 2026-10-05 和 2026-09-26 还有提交，是活的；Khoj 本身不是。
仓库没有归档，维护者 Debanjum 在 issue #1334（2026-06-12）里也回复过「Khoj development has slowed down but it is not in maintenance mode」。但把所有可观测信号摆在一起------Release、PyPI、Docker latest、博客（最后更新 2025-01-14）、提交------它们指向同一个方向。
所以这篇文章不打算写成产品说明书。更值得回答的是：一个技术上并不差、社区认可度很高的项目，为什么走到了这一步？ 这对正在做知识库选型的人，比一堆功能罗列有用得多。
二、来龙去脉
2.1 起点是一个实验工具
Khoj 不是 2023 年那波大模型热潮的产物。官方公告里写着：
The Khoj project started out in April 2021 as an experimental tool to improve document search.
2021 年 4 月，比 ChatGPT 发布早了整整一年半，GitHub 仓库建于 2021-08-16。它最初的形态是一个「文档搜索」工具------用语义检索帮你从自己的笔记里找东西，这个内核从第一天到现在基本没变过。
2.2 YC S23，和一波「第二大脑」热
2023 年，Khoj 进入 Y Combinator 夏季批次。这里要纠正一个流传较广的错误：不少第三方页面写它是 W23 或 W24，而 YC 官方页面写的是 Summer 2023（S23）。
YC 页面把创始人背景写得很清楚：Debanjum Singh Solanky 和 Saba Imran，两人都出自微软的个人 AI 方向（Cortana / Viva Insights），原文是「scaled ... from 0 to 20M daily active users」。这个背景解释了 Khoj 后来的产品直觉------它从一开始就按「面向个人的助手」来做，而不是面向组织的知识管理。
同一时期，Khoj 在 HN 上发了《Chat Offline with your Second Brain using Llama 2》（2023-07-30）。「第二大脑」和「本地离线」这两个标签，就是那时候立住的。
（有第三方资料称 Khoj 在 2023 年拿到约 50 万美元种子轮、投资方是 YC 和 Pioneer Fund。这个数字只出现在 Crunchbase / PitchBook 一类付费聚合站，我没有在首方页面上核实到，不作为事实使用。）
2.3 商业化选择：订阅制 + 云优先
2023 年 11 月，Khoj 从「自托管工具」变成「云服务」。商业模式是双轨：开源版自托管（AGPL-3.0），加上托管订阅版 app.khoj.dev（免费额度 + 付费档）。
这个选择在当时看是标准答案。但四年后，它被团队自己列进了失败原因。
2.4 关停：团队自己的复盘
公告里最值得逐字读的一段，是团队列出的「initial bets」：
...a subscription, cloud-first service, complex document syncs, custom data integrations, multiple (6!) clients --- made it very difficult to scale in utility.
以及关于护城河的那句：
...challenges in defensibility with all the big labs coming out with similar products.
翻译成大白话：他们同时压了五个重资产方向，每一个都要持续投人，而没有一个是能建立壁垒的。 模型能力被大厂快速拉平，「检索你自己的笔记」这件事本身的差异化，不足以支撑一门订阅生意。
这句话和 Khoj 技术做得好不好无关。是商业模型的问题。
时间线
| 时间 | 事件 |
|---|---|
| 2021-04 | 项目作为文档搜索实验工具起步 |
| 2021-08-16 | GitHub 仓库建立 |
| 2023-07-30 | HN 发布「用 Llama 2 离线对话你的第二大脑」 |
| 2023（S23） | 进入 Y Combinator 夏季批次 |
| 2023-11 | 转型为云服务 |
| 2024-08-07 | 前端迁移到 Next.js |
| 2024-10 ~ 11 | 密集推出 agent 能力与 AI 安全评测博客 |
| 2025-01-14 | 博客最后一次更新 |
| 2025-07-15 | 最后一个稳定版 PyPI 包 1.42.10 |
| 2026-03-26 | 最后一个 GitHub Release 2.0.0-beta.28 |
| 2026-04-15 | 云服务关停 |
| 2026-08-02 | 主仓库最后一次提交 |
三、它到底是怎么做的
这一节的依据是仓库源码（快照 commit ae229ca，即 2026-08-02 的 master）。我核对过：今天 master 上 pyproject.toml 的依赖列表与快照完全一致，所以这份快照可以当作当前状态的一手证据。
3.1 技术栈：两个 Web 框架并存
- Python ≥3.10, <3.13（3.13 装不上，这点文档没写，issue #1224 里用户自己踩出来的）；
- FastAPI 做 API 层，Django 5.1 做 ORM、模型和管理后台，两套框架共存；
- ASGI 用 uvicorn / gunicorn，定时任务用 apscheduler。
3.2 检索链路：纯稠密向量，没有关键词通路
这是最容易被误解的一点。Khoj 的检索是单一的稠密向量检索，实现是 PostgreSQL + pgvector：
python
CosineDistance("embeddings", query_vec) → order_by("distance") → distance <= max_distance两个源码层面的事实：
- 没有混合检索。 全仓库 grep
tsvector|SearchVector|tsquery|bm25|trigram|full text|lexical，除一条无关注释外零命中。它没有 BM25 / 关键词这一路。对「第十六条」「RFC 编号」「函数名」这类精确匹配需求，这条链路天然是短板。 - 没有 ANN 索引。 在 migrations 目录里 grep
hnsw|ivfflat|CREATE INDEX|vector_cosine_ops，同样零命中 。配合VectorField(dimensions=None)（pgvector 的 HNSW / IVFFlat 要求固定维度），可以判断检索走的是全表精确扫描。这一点是推断，但 grep 零命中是事实。
模型和参数的默认值：
| 环节 | 默认配置 |
|---|---|
| 向量模型（bi-encoder） | thenlper/gte-small（可换成任意 sentence-transformers 模型或远程 API） |
| 重排（cross-encoder） | mixedbread-ai/mxbai-rerank-xsmall-v1，默认不开启 |
| 相似度阈值 | 0.18 |
| 召回量 / 返回量 | top_k = 10 / 返回 5 条 |
| 分块 | 256 token，overlap = 0，切分顺序「段落 > 句子 > 词 > 字符」 |
| 分块 tokenizer | text.split() |
重排默认关闭这件事值得单独说：/api/search 的签名是 r: bool = False，只有请求显式带上 r=true，或者另外配了一个 cross-encoder 推理服务，才会重排。
3.3 数据源：覆盖面广，但都是手搓
src/khoj/processor/content/ 下的目录就是全部支持的来源：markdown、org_mode、plaintext、pdf、docx、images、notion、github。
几个需要点破的细节：
- 图片不是多模态。 走的是
rapidocr_onnxruntime做 OCR 抽文字，抽不到就整个文件不索引。只支持 png / jpg / jpeg / webp。 - GitHub 集成官方自己标了「Unmaintained」，文档原话「We are considering deprecating it」。
- DOCX 用
docx2txt，有处理器，但文档里几乎不提。 - 扫描版 PDF 依赖 OCR，能力上限取决于此。
官方关停公告里那句「hand-building data integrations was going to be a long tail of effort」，和这里的目录结构是对得上的：每接一个源，就是一份独立维护成本，五年下来攒了八个。
3.4 隔离与权限：只有「用户」和「Agent」，没有文档级 ACL
Khoj 里没有「知识库」这个实体 。隔离只有两个维度：按 user（Entry.user），按 agent（Entry.agent，agent 可以挂自己的知识，也就是 README 说的「custom knowledge」）。检索时的过滤条件是：
python
Q(user=user) | Q(agent=agent)没有文档级权限。 整个 docs 目录 grep acl|rbac|role.based|permission|multi-tenant，只命中一条无关的 GCP 排错文本。实际存在的只有服务级认证开关（默认 --anonymous-mode，可开 magic link 或 Google OAuth），以及 agent 上的一个三档 PrivacyLevel（PUBLIC / PRIVATE / PROTECTED）。
所以 Khoj 的权限模型是为个人设计的------「这份笔记是我的，不是你的」。这在个人场景下完全够用，甚至是对的选择。但如果你的场景是「同一批合同，法务能看全部、销售只能看自己负责的」，Khoj 没有对应机制。
3.5 部署：五个容器起步，镜像 1 GB+
官方给两条路：Docker Compose，或 pip install 'khoj[local]' + USE_EMBEDDED_DB=true。
但 docker-compose.yml 默认拉起 5 个服务 ：database(pgvector)、sandbox(代码沙箱)、search(searxng)、computer(带 VNC 的桌面容器，暴露 5900 端口)、server。哪怕你只想问一句「我上周写的那个方案叫什么」，searxng 和沙箱也会一起起来。
镜像体积实测（GHCR manifest，2026-10-12）：amd64 压缩后合计约 1087 MB。
GPU 方面：不是必须的，官方镜像用的是 CPU 版 torch。想跑本地大模型要自己在宿主机另起 Ollama / vLLM。官方给的离线模式建议配置是「最少 8 GB 内存，推荐 16 GB 显存，至少 5 GB 磁盘」。
四、优势：3.7 万 Star 不是白来的
先把话说清楚------Khoj 拿到的社区认可，绝大部分名副其实。它有几个别人真没做到的地方。
4.1 客户端广度
Emacs、Obsidian、桌面应用、Web、手机、WhatsApp、Discord------这个矩阵在开源知识库里几乎没有对手。尤其是 Emacs 和 Org-mode 这条线：人数不多，但极其忠诚，而且几乎被所有商业产品忽略。Khoj 认真服务了这批人，也因此拿到了最早期、最硬核的一批用户。
代价同样清楚：六个客户端意味着六份持续维护成本。团队在关停公告里把「multiple (6!) clients」明确列为压垮项目的原因之一。优势和包袱，在这里是同一件事。
4.2 数据源覆盖的长尾
Markdown、Org-mode、PDF、Notion、GitHub、纯文本------覆盖面比大多数开源同类宽。Notion 和 GitHub 这类需要 OAuth 和 API 集成的源，开源项目里很少有人愿意做。虽然 GitHub 那条现在标了 Unmaintained，整体广度仍是实打实的。
4.3 模型自由度
自托管模式下 Khoj 不锁模型。向量模型可以是任意 sentence-transformers 模型，也可以走远程 API；对话模型除了原生的 OpenAI / Anthropic / Google 三家，还能通过「任意 OpenAI 兼容 endpoint」接上 Ollama、LM Studio、vLLM、LiteLLM、OpenRouter、Vertex AI。
这里有个和直觉相反的点：在 Khoj 里，是云版更受限（文档原话「If you're using Khoj Cloud, you're limited to our first-party models」），自托管反而更自由。
4.4 Agent 与自动化
2024 年下半年起，Khoj 把重心往 agent 方向推：自定义 agent、代码执行、定时自动化（Automate）。这今天是它的重要加分项，也是团队最后的技术兴奋点。
4.5 完全自托管，数据不出机器
跑在本地时，索引、向量、模型调用都在你机器上。对隐私敏感的个人用户，这是决定性的。
五、缺点：有代码和 issue 支撑的那些问题
这一节的每一条，要么能在源码里指到行，要么能在 issue 里找到原始讨论。
5.1 内存：跨三年的头号问题
这是 Khoj 从 2023 年到 2024 年最反复出现的抱怨主题，而且至今没有解决。
-
issue #301 （2023-07-11）：用户有 18 年的笔记、11.3 GB。维护者
sabaimran的回复很坦诚：I...don't think 11.3 GB is going to be feasible by our application as it stands
并承认「we have a lot of room for improvement in memory consumption」。
-
issue #634 （2024-02-02，至今 open）：用户在 16.6 GB 内存的机器上索引 PDF------「CPU is in constant use ... sometimes it hogs all available CPU and my machine becomes unresponsive for a minute or two ... the process ends with the message 'Killed'」，原话是「Khoj has never managed to index all the PDFs」。
同主题的还有 #195（首次索引 MemoryError）、#303（有人专门开 issue 要求「分析内存占用」）、#1105（上传被 OOM kill，用户自己改脚本分批）。
一个「帮你管理笔记」的工具，在别人的真实笔记面前撑不住。这基本决定了它的用户上限。
5.2 检索质量：三个能指到代码的缺陷
（1）中文 / 日文 / 韩文分块基本失效。 issue #1354（2026-06-28，open）：
Markdown chunking fails for CJK languages due to text.split() tokenizer undercounting tokens
根因是分块的 tokenizer 就是 text.split()（按空格切）。中文没有空格，所以整篇中文文档会被当成一条 entry，不切分。后果不是「切得不好」，而是：
the bi-encoder averages the semantics of the entire document, and search hits land on the YAML frontmatter/first heading instead of relevant sections
整篇文档被平均成一个向量，检索命中会落在 YAML frontmatter 或者第一个标题上。我核对了源码，TextToEntries.tokenizer = text.split() 属实。对中文用户来说，这条是硬伤。
（2）多轮对话里的引用会静默消失。 issue #1270（2026-03-08，open）：因为一个 isinstance(item, dict) 类型判断写错，历史轮次的 references 永远为空。表现是答案里的「来源」无声无息地不见，界面上看不出任何异常。
（3）一个空标题能让索引永远跑不完。 issue #1437（2026-09-26，open）：笔记里出现空的 # 时，索引永不结束 ，一个 CPU 核 100% 空转。报告者用的正是 master 上的 ae229ca894，也就是我手上这份快照。
5.3 部署成本被低估
- issue #1224（2025-09-27）：pip 依赖冲突，社区结论「Python 3.13 不行、3.12 可以」，用户指出文档没写这一点。
- issue #1194：Windows 用户的原话------「the toml compiling need 30min MAYBE you can write a hint that its need time」（16 核 + RTX 4060 Ti）。
- issue #1100 （2025-02-02，25 条评论，是仓库里讨论最多的 issue 之一）：「Unable to connect to local Ollama using self-hosted Docker」。有人试了几天，Mac 上 Docker 跑得通，换到 Ubuntu + GPU 就不行，根因是 Docker 网络和
OLLAMA_HOST配置，而 UI 不给任何提示。 - 一批管理后台登录失败的 issue（#1152、#1187 等），用户根本不知道用户名密码是什么。
有中文深度测评给出的估计是「第一次装 Khoj 不是『5 分钟搞定』，要预留 1--3 小时」。对照它「开箱即用」的宣传，这个落差是客观存在的。
5.4 权限模型的缺失，对企业是硬伤
如 3.4 所述，Khoj 只有 user / agent 两级隔离，没有文档级 ACL、没有团队或共享空间、没有多租户权限模型。
个人用没问题。但只要场景里出现「不同角色的员工看不同的文档」------这在企业里几乎是必然的------Khoj 就得先补这一层，而这不是改配置能解决的。
5.5 官方评测数字不能用来论证「文档检索质量」
Khoj 在 2024-11-22 发过一篇评测博客《Evaluating Khoj for Helpfulness》，数字确实好看：
| Benchmark | General | Default | Research |
|---|---|---|---|
| FRAMES | 27.1 | 42.0 | 63.5 |
| SimpleQA | 10.0 | 84.0 | 86.0 |
但这篇博客自己写明了关键限制，引用时必须带上：
Our current eval only measures retrieval from the internet, not from your documents.
也就是说，这份成绩完全不衡量「跟你自己的笔记对话」的检索质量------而后者才是 Khoj 的主场景。博文作者自己对 SimpleQA 那个跳变也存疑：「suggests either remarkable effectiveness of Khoj's approach or potential brittleness in the benchmark itself. Or maybe our eval is broken?」样本量是 200 题随机子集，误差约 6%。
另外，官方性能文档里那条「Semantic search < 100 ms」，自述数据是 2022 年的，测试机型 Mac M1。
所以：看到有人把 Khoj 的 FRAMES / SimpleQA 分数拿来证明「它检索比谁强」，可以直接跳过。
5.6 AGPL-3.0 的实际约束
Khoj 用的是 AGPL-3.0 。LICENSE 是逐字的 AGPLv3 全文，pyproject.toml 写的是 AGPL-3.0-or-later，GitHub 的协议识别也是 AGPL-3.0。
关键在于第 13 条的网络服务条款：如果你把修改过的 Khoj 作为网络服务提供给用户，你有义务向这些用户提供源码。
对个人自用完全无影响。但如果你打算「基于 Khoj 改一改，做成私有化产品卖给客户」------这条路在 AGPL 下走不通，除非你开源自己的修改。这个坑值得在选型早期就想清楚，而不是立项三个月后才被法务发现。
（一个有意思的对照：团队的新项目里，Pipali 换成了 Apache-2.0，Open Paper 仍是 AGPL-3.0。协议选择上他们自己也在动。）
5.7 文档和代码脱节
几个具体表现：
- README 的 FAQ 还在写「use Khoj right away at app.khoj.dev --- no setup required」，而云服务 4 月就关了；
- README 里指向企业版的
khoj.dev/teams现在 404； - 下载页
khoj.dev/downloads404； - 文档和 credits 仍宣称「natively supports local LLMs available on HuggingFace in GGUF format」「Llama.cpp to chat with local LLM」，但
llama-cpp-python既不在pyproject.toml里也不在uv.lock里------离线聊天现在实际是通过外部 OpenAI 兼容服务器实现的。
（补一个私人博客的实测体验，注意这是第三方主观评价、非受控实测：darkedge.world 上一位 Org-roam 用户记录了跑题的 query 扩展和捏造来源，「Khoj somehow finds it appropriate to mix in blockchain technologies into the query」，并抱怨「Running the context search locally on my laptop takes about half a minute at full throttle」。HN 上也有用户 kkfx 说，在他的 org-mode 笔记上「a mere rg (ripgrep) succeed」，而 Khoj 找不到。个体体验不能当结论，但方向一致。）
5.8 安全公告
GitHub Security Advisories 上共 6 条，其中两条值得一提：未认证的路径穿越可读服务器文件系统（GHSA-62mm-xwmv-crhg，2026-06-24）；Notion OAuth 的 IDOR 可导致索引投毒（CVE-2025-69207）。另有遥测争议：2026-07-13 的 issue #1374 指出遥测在发送客户端 IP，与隐私文档「we do not log your IP address」矛盾，维护者承认并停止发送。
六、横向看：Khoj 在同类里站在哪
社区实际拿来和 Khoj 比的，主要是这几个。Star 与活跃度数据均为 2026-10-12 用 GitHub API 实测。
| 项目 | 定位 | 许可 | Star | 文档级权限 | 最近 push |
|---|---|---|---|---|---|
| khoj | 个人第二大脑 / PKM | AGPL-3.0 | 37.6k | 无（仅 user / agent） | 2026-08-02 |
| AnythingLLM | 团队工作区 | MIT | 67.0k | workspace 级 | 2026-10-09 |
| Dify | LLM 应用平台 | Apache-2.0（含附加条款） | 158.2k | 应用级 | 2026-10-12 |
| RAGFlow | 文档解析型 RAG 平台 | Apache-2.0 | 92.0k | --- | 2026-10-12 |
| PrivateGPT | 离线文档问答 | Apache-2.0 | 57.6k | --- | 2026-10-09 |
| Reor | 本地 AI 笔记 | AGPL-3.0 | 8.5k | --- | 2025-05-13 |
几条社区共识（来源等级一并标出）：
- Khoj 被普遍归为「个人 / PKM」，其余大多被归为「团队 / 组织级」。 这几乎是所有对比文章的一致结论。
- Khoj 的差异化被反复归因于「客户端广度」和「agents + 定时自动化」，而不是检索深度。 这和我们对源码的观察吻合------它的检索链路确实是最朴素的那一种。
- AnythingLLM 是最常见的正面对比对象，第三方评述点出的 Khoj 短板是「single-backend architecture is designed for personal and team scale, not enterprise-scale distributed retrieval」。（注：这类对比站大多是模板化甚至 AI 生成内容，我只把它当作「社区怎么归类」的旁证，不作事实依据。）
- NotebookLM 被当作「打磨得更好但封闭」的对照：引用做得漂亮，但是个围墙花园；Khoj 赢在集成和隐私。也有评述把「retrieval accuracy can trail more polished closed products like NotebookLM」列为 Khoj 的缺点。
- 许可被反复当作决策轴。 有第三方原文说得直白：「It is also AGPL 3.0 licensed, a copyleft license people frequently confuse with the permissive Apache 2.0 or MIT licenses used by most of the tools it competes with.」
最后补一个诚实的信息缺口：没有找到任何第三方 benchmark 把 Khoj 和这些项目放在一起做量化对比（LoCoMo / LongMemEval 之类）。目前唯一可引用的量化数字就是 Khoj 自己那篇，而它测的是联网检索。所以任何声称「A 比 B 检索准 X%」的说法，基本都没有可靠出处。
七、我们走的是另一条路
到这里该讲讲我们自己（蔓藤AI）的选择了。但不是「我们比 Khoj 强」------那种比较没有意义，因为我们做的是另一件事。
7.1 问题本身就不一样
Khoj 要回答的是：「帮我找回我自己写过的东西。」
我们要回答的是：「用户正在说话，我该不该去查资料，查到之后要把它讲出来。」
这个差别看起来只是「加了个语音」，但它把整条链路的约束全换掉了：
| 约束 | Khoj（找回笔记） | 实时语音数字人 |
|---|---|---|
| 用户耐心 | 可以等两秒看结果 | 说话时有停顿，几百毫秒内就得决定 |
| 检索不到的代价 | 失望，重搜一次 | 当场答错或卡壳，对话就断了 |
| 输出形态 | 显示一段文字，可以慢慢读 | 合成语音 + 唇形同步，说不清就是说不清 |
| 文档性质 | 个人笔记、Markdown | 合同、制度、法规、扫描件 |
| 使用场景 | 坐在电脑前 | 前台、展厅、车间，经常没有屏幕 |
最后一行是关键。没有屏幕意味着用户只能听，不能回看、不能滚动、不能点开来源。Khoj 里那种「返回 5 条结果让你自己挑」的交互模式，在这个场景下根本不存在------我们必须一次就说对。
7.2 于是检索层要做的事情完全不同
多路召回是必须的，不是加分项。 Khoj 是纯向量检索（3.2）。但在中文专业文档里，纯向量的盲区是明确的：「违约金」和「违约赔偿」靠向量能找到，「第十五条」和「第 15 条」就必须靠关键词。所以我们做的是向量 + FTS5 关键词 + 实体图谱三路并行召回，再用 RRF（Reciprocal Rank Fusion）融合：
python
def rrf_fuse(ranked_lists, k=60):
"""多路召回融合：分数 = Σ weight / (k + rank)"""
scores = {}
for weight, ranking in ranked_lists:
for rank, item in enumerate(ranking, start=1):
scores[item] = scores.get(item, 0) + weight / (k + rank)
return sorted(scores.items(), key=lambda x: -x[1])三路权重是向量 1.0 / 关键词 1.0 / 图谱 0.4------图谱作为增强，权重刻意压低，避免它把精确匹配的结果挤掉。
重排必须是默认开启的。 Khoj 的 cross-encoder 重排默认关（r: bool = False）。但在一次说对的场景里，我们没法接受「先给 10 条宽的，用户自己挑」------所以候选集放宽到 20 条，用 BGE-reranker-v2-m3 交叉编码器重新打分，只留 5 条进上下文。
中文分块不能靠空格。 前面 5.2 讲了 Khoj 的 text.split() 在 CJK 上的问题。我们用的是 jieba 分词，并且针对中文法律 / 合同类文档做了条款级分块------识别「编、章、节、条、款、项」的编号模式映射成标题层级，让「条款号即结构」。索引时用小块做向量匹配（精确），返回时扩到父块给大模型看完整上下文，也就是常说的「小到大」父子块。这是「检索要准」和「生成要有料」之间最直接的一个折中。
闲聊要能跳过检索。 用户说「你好」的时候不该去查合同库。我们有一个查询分析器做意图判断，置信度到 0.9 以上直接走闲聊路径；FAQ 问答对命中（阈值 0.75）也直接返回，不走大模型------这在实时场景里省下的是实打实的延迟。
7.3 权限：企业场景下没法省的一层
Khoj 没有文档级 ACL（3.4）。我们的做法是给每个文档块打 ACL 标签，空标签表示公开，检索时按调用方权限过滤。
这里有个容易做错的细节值得单独说：权限过滤必须下推到检索层，不能在应用层后置过滤。 如果先取 top-k 再剔掉无权结果，实际有效召回会低于 k，用户会莫名其妙地「少看到了一些内容」。我们把过滤条件直接下推到向量检索的查询里。
7.4 存储：能离线运行的单文件
私有化交付的第一条红线是数据不能出内网。所以我们的默认存储形态是 SQLite + sqlite-vec + FTS5，全部落在单个文件里：部署时不需要额外搭向量数据库，单文件即可备份迁移；模型侧（向量化、重排、文档解析）全部本地推理，模型下载完之后，拔网线也能用。
这不是「不愿意上向量数据库」，而是在企业内网的现实条件下，多一个外部组件就多一份部署和运维成本。存储层我们做了抽象，需要时可以换成 Postgres / pgvector，业务代码不变。
顺带说一个我们自己在存储层做过的基准测试（两种实现的结果逐位一致）：
| 语料规模（chunk） | 全表扫描 | 分区 KNN |
|---|---|---|
| 200 | 0.3 ms | 2.3 ms |
| 1,200 | 3.4 ms | 3.0 ms |
| 3,600 | 169 ms | 3.7 ms |
| 12,400 | 953 ms | 11.4 ms |
| 62,400 | 6,141 ms | 45.3 ms |
有两点值得说明，因为它们是这份表里最有信息量的部分。
第一，KNN 在千级 chunk 以下反而更慢------它有一个约 2 ms 的固定开销。所以「用了 ANN 就一定快」是错的认识，交叉点在千级左右。
第二，也是最该记的一条：我们在这个优化里一度拿到过 46 倍加速的错误结果。 原因是我们在过滤条件里加了一个防御性的 OR kb_id IS NULL，而 sqlite-vec 的分区表会因为这个 OR 放弃分区剪枝，退化成「先取全局前 k 再过滤」------k=20 时只剩 4 行，是静默的大规模少召回，不报任何错。是「KNN 结果必须与暴力检索逐位一致」这条断言把它抓出来的。这件事后来被写成了契约测试。
讲这个是想说明一类事：检索系统的性能优化，如果不配一个「优化前后结果必须一致」的验证网，你很可能拿到一个又快又错的系统，而且不会收到任何报警。
7.5 交付形态
- 生成式大模型走 OpenAI 兼容接口，可对接 Qwen / DeepSeek 等，也可换成本地 LLM；
- 推理侧做了统一加速器抽象，自动识别并择优调度 NPU（昇腾）→ CUDA（NVIDIA）→ CPU，覆盖 GPU 工作站、国产 NPU 一体机和纯 CPU 环境；
- 多服务可编排：主服务、检索服务、语音 / ASR 服务、前端静态服务，单机即可跑通。
7.6 说实话，我们不占优的地方
对称才可信，所以这几条也写在这里：
- 客户端广度：我们没有 Emacs、Obsidian 插件这类个人笔记客户端。七个客户端的矩阵是 Khoj 的长处，我们没有对等物。
- 个人笔记数据源：Notion、GitHub 这类个人 SaaS 源的直连，我们覆盖得不如它宽。
- 社区规模：37.6k Star 对任何项目都是一笔真实资产，短时间补不上。
- 模型完全自由：我们走 OpenAI 兼容接口 + 本地 LLM，自由度够用，但没有 Khoj 那种「任意 sentence-transformers 模型随插随用」的灵活度。
八、所以该怎么选
不用绕弯子。
选 Khoj，如果------你是个人用户，笔记以 Markdown / Org-mode 为主，主要用 Emacs 或 Obsidian，在意数据完全本地，且不介意自己花一两个小时折腾部署。它的客户端矩阵和数据源广度，在这个场景里没有对手。
别选 Khoj，如果------你要做的是企业交付：需要文档级权限、需要处理扫描件和中文法律 / 合同文档、需要多知识库隔离、需要「开口讲出来」的交互形态。这些不是配置问题，是架构层面的缺口。另外，如果你打算基于开源项目做成商业产品卖出去，AGPL-3.0 这条得先过法务。
另外有个现实提醒：不管选不选 Khoj，都要注意它的维护状态。云服务已关停、主仓库自 2026-08 无提交、最新版仍是 beta。选一个活跃度在下降的项目，本质是在赌社区会接手。
九、回到那个问题
Khoj 团队在关停公告里写的那句话，我认为是整件事里最有价值的一段：
...a subscription, cloud-first service, complex document syncs, custom data integrations, multiple (6!) clients --- made it very difficult to scale in utility.
五个重资产方向同时推进，每一个都需要持续投人，每一个都不是壁垒。这不是技术失败，是在一个已经被大厂快速拉平的赛道上，用个人工具的方式去撑一门订阅生意。
对我们的启示很直接：与其在「通用检索」这个正被模型能力抹平的维度上竞争，不如去做那些模型能力无法替代的工程约束------实时性、权限、专业文档的结构化理解、私有化交付、语音输出。这些事做起来苦，但不容易被一个大模型版本更新抹掉。
附录：数据来源与核实说明
本文所有事实按来源分三档。
一档｜一手可核实（GitHub / PyPI 官方 API 实测，或仓库源码）
- 仓库规模、Star / Fork、提交与 Release 时间、协议：GitHub API，2026-10-12 实测
pip稳定版版本与日期：PyPI JSON API- 云服务关停公告及其原文引用：app.khoj.dev（2026-10-12 仍返回该页）
- 技术栈、检索实现、数据源目录、模型默认值、docker-compose 服务列表、镜像体积：本地仓库快照（commit
ae229ca，2026-08-02），并已核对今日 master 的依赖列表与快照一致 - 各 issue 的标题、日期、状态与原话：GitHub Issues API 逐条拉取
- 安全公告：GitHub Security Advisories API
- 对比项目的 Star 与活跃度：GitHub API，2026-10-12 实测
二档｜官方但需注意时效
- 评测数字（FRAMES / SimpleQA）：官方博客 2024-11-22，且只衡量联网检索，不衡量个人文档检索
- 性能数字（语义检索 < 100 ms）：官方文档，自述数据为 2022 年
- YC 批次与创始人背景：YC 官方公司页
三档｜第三方，仅作旁证，不单独作为结论依据
- HN 讨论帖与用户评论
- 个人博客实测（darkedge.world 等），主观体验，未经受控复现
- 各类「对比站」评述，多为模板化或 AI 生成内容，仅用于说明「社区如何归类」
明确未核实、故未采用的
- Khoj 云服务的历史定价档位与免费额度（首方页面已失效，archive.org 在本环境不可达）
- 种子轮的确切金额与投资人名单（仅见于付费聚合站）
- 创始人详细履历（学位、历任雇主与年份，仅见于二手聚合资料）
- Reddit 上的相关讨论（未检索到可验证的原始帖链接，故不引用任何「Reddit 用户抱怨」）
- 任何第三方量化 benchmark 对比（不存在，故本文不含此类数字）
说明：本文涉及的开源组件均为公开发布，模型与参数默认值来自公开源码；我们自己的性能数据来自仓库内基准脚本，可复现。工程参数以实际交付为准。