How we built our knowledge base我们是如何构建知识库的
Authors: , ,
note: the interactive version of full technical blog available: 作者：@hi_im_isaac_, @learnwdaniel, @gaozenghao
注：完整技术博客的交互式版本请见：https://www.cerebras.ai/blog/how-we-built-our-knowledge-base
Employees ask our internal knowledge base more than 15,000 questions every day. It's become one of the most widely adopted internal tools at the company since launching 3 months ago. Used by humans, automations and agents.Cerebras 的员工每天向内部知识库提问超过 15,000 次。自 3 个月前推出以来，它已成为公司内部采用率最高的工具之一，供员工、自动化程序和智能体使用。
At Cerebras, our teams work across data center operations, chip design, hardware, training, inference, cloud platform, and more. With hundreds of new employees joining every year, our communication channels were filling up with the same questions:在 Cerebras，我们的团队涵盖数据中心运营、芯片设计、硬件、训练、推理、云平台等多个领域。随着每年数百名新员工加入，我们的沟通渠道充斥着重复的问题：
- “Where can I find X?”
- “Who is the expert in Y?”
- “What is Z?”- “在哪里可以找到 X？”
- “谁是 Y 方面的专家？”
- “Z 是什么？”
We built Cerebras Knowledge to help people connect people and systems to useful information.我们构建了 Cerebras Knowledge，旨在帮助人们将人员与系统连接到有用的信息。
Meeting data where it lives让数据留在原处
Finding information inside an organization is hard. The data is scattered across tools, and every quarter or so someone proposes the same brilliant fix: let’s record everything in one platform so that all information is in a single place. The dream of a single source of truth, of course, rarely works in practice.在组织内部查找信息非常困难。数据散落在各种工具中，每隔一个季度左右，就会有人提出同样的绝妙方案：把所有东西都记录在一个平台上，这样所有信息就汇集到一处了。当然，这种“单一事实来源”的梦想在实践中很少能实现。
Information is generated wherever it is convenient and ergonomic: suggested edits in a document, threads in Slack, code references in GitHub, and status metadata in Jira. These platforms are tailor-made for their specific domains, optimized through years of product engineering and analytics. Discussing a pull request in Google Docs would be a terrible experience.信息是在最方便、最符合使用习惯的地方产生的：文档中的建议编辑、Slack 中的讨论串、GitHub 中的代码引用以及 Jira 中的状态元数据。这些平台是为各自的特定领域量身定制的，并经过多年的产品工程和分析优化。在 Google Docs 中讨论合并请求（Pull Request）体验会非常糟糕。
So we set out to design a system that required minimal change to existing behavior. On the data collection side, this meant extracting data from each platform directly.因此，我们着手设计一个对现有行为几乎无需改变的系统。在数据采集方面，这意味着直接从每个平台提取数据。
Anatomy of a knowledge base知识库的剖析
Our knowledge base provides three things:我们的知识库提供三项功能：
- A platform for collecting and storing internal data.
- A platform for querying that data.
- A layer that enforces authentication and authorization, with auditing and analytics.- 一个用于收集和存储内部数据的平台。
- 一个用于查询这些数据的平台。
- 一个强制执行身份验证和授权，并具备审计与分析功能的层级。
At the core is a single Postgres table that holds embeddings, raw summaries, and metadata from many sources. The system continually ingests data from across the company and maintains a query-ready datastore.核心是一个单一的 Postgres 表，它存储了来自多个来源的向量嵌入（embeddings）、原始摘要和元数据。系统持续从公司各处摄取数据，并维护一个可随时查询的数据存储库。
We wanted a data interface that was simple but could work with most forms of data. We also wanted other developers at Cerebras to be able to build custom connectors. The result is deliberately simple: every source, from Slack threads to netlists, lands in the same embeddings table, and anything in that table is immediately queryable through the same interface:我们想要一个既简单又能处理大多数数据形式的数据接口。我们还希望 Cerebras 的其他开发者能够构建自定义连接器。其结果是刻意保持简单：每一个来源，从 Slack 讨论串到网表（netlists），都进入同一个嵌入表，并且表中的任何内容都可以通过同一个接口立即进行查询：
Each data source defines what the data is, how to connect to it, and how often it should be fetched. Each resulting embedding row follows the same interface regardless of whether it came from Slack, a code repository, a document system, or a custom database.每个数据源都定义了数据的内容、连接方式以及抓取频率。无论数据来自 Slack、代码仓库、文档系统还是自定义数据库，生成的每一行嵌入数据都遵循相同的接口。
How we process unstructured Slack conversations我们如何处理非结构化的 Slack 对话
Slack was the most important data source we needed to design for. It is where the most up-to-date engineering discussions happen across the company.Slack 是我们需要设计的最重要的数据源。公司内最新的工程讨论都在这里进行。
We initially tested whether simple embeddings over raw text performed well enough. We quickly realized that vector search alone was insufficient for matching all relevant data.我们最初测试了对原始文本进行简单的嵌入是否效果足够好。很快我们意识到，仅靠向量搜索不足以匹配所有相关数据。
Slack messages present several challenges:Slack 消息带来了几个挑战：
- Information density varies enormously: “hey yeah sure mike” and a detailed kernel explanation are both messages.
- Message lengths vary, and shorter messages frequently beat longer, more detailed messages in cosine similarity.
- The meaning of a message often depends on the surrounding conversation.- 信息密度差异巨大：“嘿，好的，没问题，迈克”和详细的内核解释都是消息。
- 消息长度不一，在余弦相似度中，较短的消息往往会胜过较长、较详细的消息。
- 消息的含义通常取决于上下文对话。
We needed a hybrid approach. We built Slack ingestion so every thread is retrievable through several search techniques at once, where each technique makes up for the weaknesses of the others:我们需要一种混合方法。我们构建了 Slack 摄取功能，使每个讨论串都能通过多种搜索技术同时被检索到，每种技术都能弥补其他技术的弱点：
- Full-text search catches the exact tokens that embeddings blur together: error strings, flag names, host names. When an engineer pastes a literal error message, an exact lexical match is almost always the best evidence, and no amount of semantic similarity should outrank it.- 全文搜索可以捕捉到嵌入模型模糊处理的精确标记：错误字符串、标志名称、主机名。当工程师粘贴一段字面上的错误消息时，精确的词汇匹配几乎总是最好的证据，任何语义相似度都不应凌驾于其上。
- Embedding search catches paraphrase. The person asking “restore hangs after manifest load” and the person who answered “checkpoint stalls on the NFS mount” may never share vocabulary. Vector similarity is what connects a question to an answer written in different words.(1)- 嵌入搜索可以捕捉释义。问“恢复在清单加载后挂起”的人和回答“检查点在 NFS 挂载上停滞”的人可能永远不会共享相同的词汇。向量相似度是将问题与用不同措辞写出的答案联系起来的关键。(1)
- Inverse document frequency separates signal from filler. A short message built around rare tokens, such as an obscure config flag, deserves to rank. “sounds good, thanks!” sits close to many queries in embedding space but scores near zero once term rarity is taken into account.- 逆文档频率（IDF）将信号与填充内容区分开来。围绕罕见标记（如晦涩的配置标志）构建的短消息值得被排名。“听起来不错，谢谢！”在嵌入空间中离许多查询很近，但一旦考虑到词汇稀有度，其得分就接近于零。
- Age decay encodes that Slack answers expire. Two threads can answer the same question, and the one from six months ago may describe infrastructure that no longer exists. When relevance is otherwise equal, the newer thread wins.- 时间衰减编码了 Slack 答案会过期的事实。两个讨论串可以回答同一个问题，但六个月前的那个可能描述的是已不存在的基础设施。当相关性相当时，较新的讨论串胜出。
No single scorer is trusted on its own. Each technique produces its own ranked view of the same corpus, and those views are fused at query time (see Reranking).没有单一的评分器是完全可信的。每种技术都会生成自己对同一语料库的排名视图，这些视图在查询时进行融合（参见“重排序”）。
Socket ModeSocket 模式
To collect data in real time, we installed a Slack bot into our workspace and ran it in Socket Mode. Slack pushes every message event to us over a persistent WebSocket, so we get real-time updates without polling the Web API and burning through its rate limits.为了实时收集数据，我们在工作区安装了一个 Slack 机器人，并以 Socket 模式运行。Slack 通过持久的 WebSocket 将每个消息事件推送给我们，因此我们无需轮询 Web API 并耗尽其速率限制，即可获得实时更新。
When an event arrives, we immediately acknowledge it, deduplicate it using the stable event ID, and mark the message for the ingest consumer.当事件到达时，我们会立即确认，使用稳定的事件 ID 进行去重，并将该消息标记为待摄取。
The ingest consumer does not save a new message in isolation. It resolves the thread that the message belongs to and re-fetches the entire conversation, including the parent and every reply, from the Slack API. It then writes the whole thread back as one row. A reply to an existing thread therefore re-pulls the parent and all siblings, so the stored content, participant list, and last-activity timestamp always reflect the complete conversation.摄取消费者不会孤立地保存新消息。它会解析该消息所属的讨论串，并从 Slack API 重新获取整个对话，包括父消息和所有回复。然后，它将整个讨论串作为一行重新写入。因此，对现有讨论串的回复会重新拉取父消息和所有同级消息，从而使存储的内容、参与者列表和最后活动时间戳始终反映完整的对话。
Every Slack channel in our system has its own data source. This provides fine-grained tuning for data freshness. A team may choose to ingest a busy incident channel more frequently, for example.系统中每个 Slack 频道都有自己的数据源。这为数据新鲜度提供了细粒度的调整。例如，团队可以选择更频繁地摄取繁忙的事故处理频道。
Threads and messages讨论串与消息
Raw Slack text is keyword-searchable as soon as it lands because we maintain a Postgres full-text (GIN) index over the raw content. To enable useful vector search, however, we do some additional processing.(8)原始 Slack 文本一旦落地即可通过关键词搜索，因为我们在原始内容上维护了一个 Postgres 全文（GIN）索引。然而，为了实现有效的向量搜索，我们进行了一些额外的处理。(8)
During distillation, an LLM extracts structured data from the full thread:在蒸馏过程中，大语言模型（LLM）从完整的讨论串中提取结构化数据：
- A one-line question that an engineer would actually search for.
- A short summary.
- The resolution.
- The systems and code references mentioned.- 工程师实际会搜索的一行问题。
- 简短摘要。
- 解决方案。
- 提及的系统和代码引用。
We embed these data points and write them into the shared embeddings table. The original transcript is not embedded directly. In our experiments, accuracy increased significantly when the thread was normalized into a consistent format.(7,9) The additional metadata also gives the semantic match more useful signal.我们对这些数据点进行嵌入并写入共享的嵌入表中。原始记录不会直接进行嵌入。根据我们的实验，当讨论串被规范化为一致的格式时，准确性显著提高。(7,9) 额外的元数据也为语义匹配提供了更有用的信号。
Bursting突发（Bursting）
At this point Slack search was good, but we kept encountering the same problem: important messages inside long threads were not always represented in the thread-level summary.此时 Slack 搜索效果不错，但我们不断遇到同一个问题：长讨论串中的重要消息并不总是能在讨论串级别的摘要中体现出来。
To boost the signal from individual messages, we use bursting. A burst is a run of consecutive messages from the same author. We embed individual bursts with the thread topic prepended as context(2) because sometimes the answer lives in one tangent message whose vocabulary never makes it into the thread summary. Burst embeddings make that message findable on its own.为了增强来自单条消息的信号，我们使用了“突发”处理。突发是指同一作者的一连串连续消息。我们对单个突发进行嵌入，并在前面加上讨论串主题作为上下文(2)，因为有时答案存在于某条切题的消息中，其词汇从未进入讨论串摘要。突发嵌入使得该消息可以被独立找到。
To prevent low-signal data from reaching the database, each burst is scored against a weighted combination of signals and must clear a threshold before it is embedded:为了防止低信号数据进入数据库，每个突发都会根据加权信号组合进行评分，并且必须在嵌入前达到阈值：
- It contains a relatively rare token across the corpus, with IDF of at least 4.0.
- The combined burst is at least 200 characters.
- One or more messages in the burst contain reactions, providing a social boost.- 它包含语料库中相对罕见的标记，IDF 至少为 4.0。
- 组合后的突发长度至少为 200 个字符。
- 突发中的一条或多条消息包含反应（reactions），提供社交加成。
After distillation, qualifying bursts are embedded and stored in the embeddings table alongside the thread-level record.蒸馏后，符合条件的突发会被嵌入并与讨论串级记录一起存储在嵌入表中。
Code repositories代码仓库
Initially we debated whether embedding code repositories was necessary. With the rise of Claude Code and other command-line tools, creating code embeddings felt counterintuitive when it seemed like “grep is all you need.” After talking with others in the industry and reading Cursor’s findings on semantic search in large codebases, we decided to try.起初，我们争论是否有必要对代码仓库进行嵌入。随着 Claude Code 和其他命令行工具的兴起，当看起来“grep 就足够了”的时候，创建代码嵌入感觉违反直觉。在与业内其他人交谈并阅读了 Cursor 关于大型代码库中语义搜索的研究结果后，我们决定尝试一下。
We have many internal repositories, some larger than 40 GB. Our main concern was how to keep them current efficiently.我们有许多内部仓库，有些超过 40 GB。我们主要担心的是如何高效地保持它们处于最新状态。
使用 @cocoindex_io 维护代码嵌入
After several experiments, we landed on CocoIndex, an open-source document embedding framework that specializes in vectorizing codebases.经过几次实验，我们选择了 CocoIndex，这是一个专门用于代码库向量化的开源文档嵌入框架。
For each repository, we split the code using language-specific regex boundaries ordered from coarse to fine. The splitter tries higher-level boundaries, such as classes, first. If a resulting chunk is still too large, it falls back to method boundaries and then smaller blocks. We embed the resulting chunks and write the vectors to Postgres. A single file may generate multiple embeddings at different levels of specificity, such as file-level and function-level records.对于每个仓库，我们使用从粗到细排序的特定语言正则表达式边界来分割代码。分割器首先尝试更高级别的边界，例如类。如果生成的块仍然太大，它会回退到方法边界，然后是更小的块。我们对生成的块进行嵌入并将向量写入 Postgres。单个文件可能会在不同的特异性级别生成多个嵌入，例如文件级和函数级记录。
CocoIndex tracks synchronization metadata in Postgres. On each commit, it re-embeds and re-exports only the changed code chunks instead of recomputing the whole repository. This worked especially well for us because the synchronization state and embedding store live in the same database.CocoIndex 在 Postgres 中跟踪同步元数据。每次提交时，它只重新嵌入和重新导出更改的代码块，而不是重新计算整个仓库。这对我们特别有效，因为同步状态和嵌入存储都在同一个数据库中。
As the number of codebases grew, we moved repository onboarding into configuration files that teams can submit themselves, including allowlists and denylists at the file-path level.随着代码库数量的增加，我们将仓库接入流程移至配置文件中，团队可以自行提交，包括文件路径级别的允许列表和拒绝列表。
Custom data sources自定义数据源
Some teams already had their own databases and did not want to move data into Slack or a document system just to participate in the knowledge base. They wanted the same query surface over their existing tables.一些团队已经拥有自己的数据库，不想仅仅为了参与知识库而将数据移动到 Slack 或文档系统中。他们希望在现有的表上使用相同的查询界面。
To support this, we treat custom sources as plugin scripts. A team opens a pull request with a small Python module that knows how to read from its system and emit rows shaped like our embeddings table, plus a matching data source entry.为了支持这一点，我们将自定义源视为插件脚本。团队通过合并请求（Pull Request）提交一个小的 Python 模块，该模块知道如何从其系统中读取数据，并输出形状类似于我们嵌入表的行，以及匹配的数据源条目。
As long as the script writes into the shared database using the same schema as every other embedding row, the rest of the stack works unchanged. The data becomes queryable alongside Slack, code, and documents, with no special handling elsewhere in the system.只要脚本使用与其他嵌入行相同的模式写入共享数据库，其余堆栈就可以保持不变。数据可以与 Slack、代码和文档一起查询，系统其他部分无需特殊处理。
Planning and tool fan-out规划与工具分发
For every query, we first run a short planning pass where an LLM decides which tools and data sources are likely to matter. The main tools:对于每个查询，我们首先运行一个简短的规划过程，由大语言模型决定哪些工具和数据源可能相关。主要工具包括：
- subsystem_index: per-file LLM summaries.
- search: the unified vector pipeline across Slack, wiki, code, and other indexed sources, merged and reranked internally.
- search_slack: direct Slack retrieval.
- search_code: ripgrep over source repositories.
- recent_prs: recent pull requests relevant to the question.
- who_knows: people with demonstrated expertise on a topic.- subsystem_index：每个文件的 LLM 摘要。
- search：跨 Slack、维基、代码和其他已索引源的统一向量管道，在内部进行合并和重排序。
- search_slack：直接 Slack 检索。
- search_code：对源代码仓库进行 ripgrep。
- recent_prs：与问题相关的近期合并请求。
- who_knows：在某个主题上有明确专业知识的人。
The planner works over a compact description of what we have indexed: which projects exist, which sources are available in each project, and what each source is good at answering. Given the user’s query and active scope, it emits tool selections that the executor fans out in parallel, normalizes into a common evidence format, and passes to a final synthesis LLM.(4)规划器根据我们已索引内容的简明描述进行工作：存在哪些项目，每个项目中可用哪些源，以及每个源擅长回答什么。根据用户的查询和活动范围，它会选出工具，执行器并行分发这些工具的选择，将其规范化为通用的证据格式，并传递给最终的合成大语言模型。(4)
Reranking重排序
A document can surface near the top simply because it shares vocabulary with the query while answering a different question. Before reranking, we combine the retrievers’ incompatible result lists with reciprocal rank fusion, or RRF. For every document, we add weight / (60 + rank) for each list in which it appears, with a default weight of 1.0 and a smoothing constant of 60.一个文档可能仅仅因为与查询共享词汇而出现在顶部，即使它回答的是另一个问题。在重排序之前，我们使用倒数排名融合（RRF）将检索器不兼容的结果列表合并。对于每个文档，我们为它出现的每个列表添加 weight / (60 + rank)，默认权重为 1.0，平滑常数为 60。
The smoothing constant makes consensus matter more than a single strong vote: a document that shows up near the top across several retrievers can beat one that ranks first in only one of them. We then merge duplicate chunks back to one source, cap how many results each file can contribute, and end up with a more diverse top twenty.平滑常数使得共识比单一的强投票更重要：一个在多个检索器中都排在顶部的文档，可以击败仅在一个检索器中排名第一的文档。然后，我们将重复的块合并回一个源，限制每个文件可以贡献的结果数量，最终得到一个更多样化的前二十名结果。
We send the original query and those candidates to a small reranker model. It gives each document a score from zero to ten, and we keep the top ten.(6)我们将原始查询和这些候选结果发送给一个小型的重排序模型。它为每个文档打分（0 到 10），我们保留前十名。(6)
Once the ranking is final, we add context back to the winners. For example, if we match a wiki section we pull in the two neighboring sections so the heading, preconditions, and caveats that chunking split apart aren’t lost. This gives readers a complete snippet instead of a lonely paragraph that’s missing important context.一旦排名最终确定，我们就会将上下文添加回获胜结果中。例如，如果我们匹配到一个维基部分，我们会拉入相邻的两个部分，这样分块时被拆散的标题、前提条件和注意事项就不会丢失。这为读者提供了一个完整的片段，而不是一个缺失重要上下文的孤立段落。
So the output of search is a rich packet of evidence: results fused from different retrievers, deduplicated at the source level, reranked against the actual question, and only then expanded with surrounding context.因此，搜索的输出是一个丰富的证据包：从不同检索器融合的结果，在源级别去重，针对实际问题重排序，最后才用周围的上下文进行扩展。
MCP
In the MCP integration, we expose retrieval building blocks as direct tools instead of hiding them behind one “answer this question” endpoint. These tools are intentionally simple and as LLM-free as possible so clients can query them quickly and cheaply.(5)在 MCP 集成中，我们将检索构建块作为直接工具公开，而不是将其隐藏在“回答这个问题”的端点后面。这些工具是有意设计的，尽可能简单且不依赖 LLM，以便客户端可以快速且低成本地查询它们。(5)
Each MCP tool corresponds to one underlying retrieval primitive, such as search_slack, search_code, search, or who_knows. Tool inputs and outputs are narrow, structured, and stable, making them easy to call from any client or agent without embedding additional orchestration logic inside the tool itself.每个 MCP 工具对应一个底层的检索原语，例如 search_slack、search_code、search 或 who_knows。工具的输入和输出是狭窄、结构化且稳定的，使得它们可以轻松地从任何客户端或智能体中调用，而无需在工具内部嵌入额外的编排逻辑。
Most tools run one query pipeline, such as vector search, lexical search, or ripgrep, apply lightweight scoring heuristics, and return raw evidence rows.大多数工具运行一个查询管道（如向量搜索、词汇搜索或 ripgrep），应用轻量级的评分启发式算法，并返回原始证据行。
Claude Code, or any MCP-compatible agent, becomes the orchestration engine. It decides which tools to call, in what order, and how to assemble the results into a final answer or code edit. The retrieval layer itself does not depend on those LLM decisions in order to serve requests.Claude Code 或任何兼容 MCP 的智能体成为编排引擎。它决定调用哪些工具、以什么顺序调用，以及如何将结果组装成最终答案或代码编辑。检索层本身不需要依赖这些 LLM 决策来处理请求。
Web UIWeb UI
In the web UI, the same tools exist, but they are connected to a complete query pipeline that runs end to end for every user question. The UI agent owns the planner and executor steps.在 Web UI 中，存在相同的工具，但它们连接到一个完整的查询管道，该管道为每个用户问题端到端运行。UI 智能体负责规划和执行步骤。
- Planner: A lightweight LLM pass inspects the query and active project, then chooses which retrieval tools to invoke, such as search, search_slack, and subsystem_index.- 规划器：轻量级 LLM 通路检查查询和活动项目，然后选择要调用的检索工具，如 search、search_slack 和 subsystem_index。
- Executor: The system fans those tool calls out in parallel, gathers the results, and normalizes them into a shared evidence schema with scores, recency, and source hints.- 执行器：系统并行分发这些工具调用，收集结果，并将其规范化为带有分数、近因和源提示的共享证据架构。
- Synthesis: A final LLM pass takes the typed evidence bundle and original question, then produces the answer shown in the UI, including citations, caveats, and cross-source synthesis.- 合成：最终的 LLM 通路获取类型化的证据包和原始问题，然后生成 UI 中显示的答案，包括引用、注意事项和跨源合成。
From the user’s perspective, the web UI is simply “ask a question and get an answer.” Under the hood, it runs the same planner → executor → synthesizer pattern that MCP clients can recreate explicitly.从用户的角度来看，Web UI 只是“提问并获得答案”。在后台，它运行着同样的“规划 → 执行 → 合成”模式，MCP 客户端可以显式地重现这种模式。
Organization 组织
As the corpus grew, “search everything everywhere” rapidly stopped being useful. Engineers on compiler teams did not want infrastructure runbooks in their results, and vice versa. Projects are how we make search relevant by default.随着语料库的增长，“搜索所有地方的一切”很快就变得不再有用。编译器团队的工程师不希望在结果中看到基础设施的操作手册，反之亦然。项目是我们默认使搜索具有相关性的方式。
Projects and scoped search项目与范围搜索
We introduced projects as the primary way to organize the workspace that a query runs over. A project is a named bundle of data sources: specific Slack channels, code repositories, internal databases, and document spaces relevant to a team or initiative.我们引入了项目，作为组织查询所运行工作区的主要方式。项目是数据源的命名集合：特定 Slack 频道、代码仓库、内部数据库和与团队或计划相关的文档空间。
Projects are intentionally lightweight. The same data source, such as a shared incidents channel or central platform repository, can be referenced by multiple projects instead of being duplicated.项目是刻意保持轻量级的。同一个数据源（例如共享的事故频道或中央平台仓库）可以被多个项目引用，而无需复制。
Onboarding and defaults入门与默认设置
During onboarding, users are prompted to select or create a default project that matches how they work, such as ML training infrastructure, Compiler, or Data Center Operations.在入职期间，系统会提示用户选择或创建一个符合其工作方式的默认项目，例如“机器学习训练基础设施”、“编译器”或“数据中心运营”。
That default project is stored on the user profile and scopes queries automatically. A new engineer gets high-signal answers without first having to learn which Slack channels, repositories, or document spaces matter.该默认项目存储在用户个人资料中，并自动限定查询范围。新工程师无需先了解哪些 Slack 频道、仓库或文档空间重要，即可获得高质量的答案。
Final Thoughts结语
In the end, the knowledge base works because it meets people where the information already lives, instead of forcing everything into one rigid system. By combining various search techniques, we can surface evidence quickly. The result is a search experience that stays flexible enough for real company data, but structured enough to remain useful as Cerebras keeps growing.归根结底，知识库之所以有效，是因为它在信息原本存在的地方满足了人们的需求，而不是强迫一切都进入一个僵化的系统。通过结合各种搜索技术，我们可以快速呈现证据。其结果是一种搜索体验，它既能保持足够的灵活性以应对真实的业务数据，又具备足够的结构性，从而在 Cerebras 不断发展的同时保持其实用性。
If you read this far and this is interesting to you, the ai/growth team is hiring reach out if you are interested 如果你读到了这里并且对此感兴趣，AI/增长团队正在招聘，如果你有兴趣，请联系 @learnwdaniel
References参考资料
- Malkov and Yashunin, , arXiv:1603.09320 / IEEE TPAMI 2018.
- Anthropic, , 2024.
- Cormack, Clarke, and Büttcher, , SIGIR 2009.
- Li et al., , arXiv:2501.05366, 2025.
- Anthropic, , 2025.
- Liu et al., , arXiv:2307.03172, 2023.
- Anthropic, .
- Salesforce/Slack Engineering, How Slack AI Processes Billions of Messages.
- Improving Agents, Best Nested Data Format.
- Cursor, , 2025.
想发布自己的文章？想发布自己的文章？
升级为 Premium升级为 Premium