想象你是一家公司新来的“AI 教授”——一个已经读了很多书的大模型。你知识渊博,但公司内部那几万份制度、技术文档、客户记录,你一本都没读过。这时有人为你建了一座私人图书馆:管理员把散落的资料编好目录,你问什么,就有人快速找到对应的章节递到你面前,还附上出处。这座图书馆就是 LlamaIndex。 LlamaIndex 是一套把大模型与私有数据连接起来的开源框架。它不只是“存数据”,而是完整地解决一个问题:数据怎么进来、怎么组织索引、怎么被检索、怎么交给大模型回答,甚至怎么让大模型自己规划步骤去调用多个工具。你可以把整个过程想成图书馆的四件事——收书、编目、找书、做研究。这篇文章就带你走一遍从索引到 Agent 的全流程,让你知道向量索引、关键词索引、树状索引分别在什么时候用,Agent 又是怎么把“找资料”升级成“解问题”的。

岗位关联

掌握 LlamaIndex 的全流程,你就能独立搭建企业知识库问答和自动化 Agent 应用,让大模型真正“读到”业务数据,而不是只会聊天。这是当前 RAG 应用工程师最核心的落地能力之一。

目录
  1. 可视化演示
  2. 框架概览:一座为AI建的图书馆
  3. 数据装载:把藏书整理进馆
  4. 索引体系:三套目录各显神通
  5. 检索机制:图书管理员怎么高效找书
  6. Agent编排:从找书到做研究
  7. 应用实践:企业知识库落地实战
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示LlamaIndex框架如何加载、索引、查询数据,构建LLM应用的核心工作流程。

本节配有交互动效(进入视口后自动加载,约 3KB)。

数据加载与解析 多格式文档加载器 PDF/HTML/代码解析 Document → Node → Index

框架概览:一座为AI建的图书馆

假设公司请来一位学识渊博的教授,也就是大模型。教授读过海量的公开书籍,但公司内部那几万份文档他一本没看过。你不能把整个仓库直接倒给他,那样他反而被淹没。于是你请来一位图书总管——LlamaIndex。它负责四件事:把散落的资料收集进馆、给每本书编好目录、安排管理员快速找书、再请一位研究助理帮忙做综合研究。这篇文章就是一次图书馆参观之旅。

在技术世界里,大模型从训练数据中学到的是“语言能力和常识”,学不到你的私有数据。LlamaIndex 的核心思想是“知识外置”:先把企业文档处理成可查询的结构,再在回答时检索相关内容,拼进提示词交给大模型。这个模式叫检索增强生成(RAG)。LlamaIndex 把 RAG 工程化,让你不用从零写数据管线。

从架构上看,它由几条明确的分工组成:Data Connectors 连接 PDF、网页、数据库等数据源;Documents/Nodes 是数据的基本单元;Index 组织节点;Retriever 负责查询;Agent 负责多步任务编排;Response Synthesizer 最后组装答案。整条链路可以用一句话概括:数据进得来、查得准、答得对。

就像图书馆把“找书”和“读书”分开一样,LlamaIndex 负责把知识管好,大模型专注推理生成。图书馆越完善,教授的回答就越有依据、越少胡编。

Answer=LLM(Query, Retrieve⁡(Query, I))\displaystyle \text{Answer} = \mathrm{LLM}\big(\text{Query},\ \operatorname{Retrieve}(\text{Query},\ \mathcal{I})\big)
这条公式说的是:最终的答案 = 大模型拿着用户的问题,加上检索系统从索引中捞出来的相关资料,综合生成。
  1. 检索动作 Retrieve根据用户问题,从索引中找回最相关的文档片段。
    Retrieve⁡(Query, I)={d1,d2,…,dk}\displaystyle \operatorname{Retrieve}(\text{Query},\ \mathcal{I}) = \{d_1, d_2, \dots, d_k\}
  2. 拼接上下文把用户问题和检索到的片段拼成一个大上下文。
    Context=[Query, d1, d2, …, dk]\displaystyle \text{Context} = [\text{Query},\ d_1,\ d_2,\ \dots,\ d_k]
  3. 生成答案大模型基于完整上下文输出最终回答。
    Answer=LLM(Context)\displaystyle \text{Answer} = \mathrm{LLM}(\text{Context})

数据装载:把藏书整理进馆

建图书馆的第一步是收书。书可能是 PDF、网页、数据库导出表,形态五花八门。图书总管需要一台“碎纸机”——把整本书拆成方便调阅的章节,也就是节点(Node)。拆得好不好,直接决定了后面目录能不能编、管理员能不能快速找到内容。

LlamaIndex 中,Document 是原始数据源的载体,由各类 Loader 读入。比如 SimpleDirectoryReader 扫一个文件夹,PdfReader 读 PDF,还能通过 DatabaseReader 连数据库。读进来的内容是长长的一整篇,必须切分。切分器会按 chunk_size(块大小)和 chunk_overlap(块重叠)把文档切成多个 Node。

为什么要重叠?设想一句话被从中间拦腰截断,语义就碎了。重叠就像让每个章节的最后一句话,在下一个章节开头再出现一次,保证上下文连贯。切分之后,每个节点还可以挂上元数据——文件名、页码、作者、部门标签。这些标签以后能用来做权限过滤,比如 HR 文档只允许 HR 部门的人检索到。

书拆得合不合理,索引就有多好用。切太碎会丢上下文,切太大又会让噪音淹没关键信息。给章节留一点“接缝重叠”,是成本最低的检索优化手段之一。

N=⌈L−OC−O⌉\displaystyle N = \left\lceil \frac{L - O}{C - O} \right\rceil
节点数 = 去掉重叠后文档的总长度,除以每个新节点真正新增的长度,最后向上取整。
  1. 分子 L−O去掉重叠部分后,第一次切分需要覆盖的有效长度。
    L−OL - O
  2. 分母 C−O从第二个节点开始,每个新节点真正引入的新内容是块长减去重叠。
    C−OC - O
  3. 向上取整最后不足一块的尾巴也算一个节点,取天花板保证不丢内容。
    ⌈L−OC−O⌉\left\lceil \frac{L-O}{C-O} \right\rceil

索引体系:三套目录各显神通

图书馆不是把书堆在一起就完事,还要编目录。LlamaIndex 提供了三套风格迥异的目录:老式卡片目录(关键词索引)、语义关系网(向量索引)、分类大树(树状索引)。同一个查询,用不同目录去找,路径完全不同。

向量索引(VectorStoreIndex) 把每个节点用 Embedding 模型映射成高维向量,查询时寻找“语义最接近”的向量。它最强的地方是能理解“意思差不多”:用户问“怎么提升检索准确率”,它能召回“相似度打分优化”这类没有共同关键词的文档。关键词索引(KeywordTableIndex) 维护一张“词 → 节点”的倒排表,适合精确匹配代码变量、订单编号、产品型号。树状索引(TreeIndex) 先把相邻节点递归摘要成树,再从根向叶子逐层下钻,适合篇章级、总结型的问题。

三者怎么选?开放式的语义问答优先向量索引;精确匹配优先关键词索引;结构化强、层级分明的文档用树状索引。真实系统通常不押注单一目录,而是做混合检索:向量语义召回 + 关键词精确召回,再用权重合并得分。

三套目录不是互相取代,而是互补。聪明的管理员会根据问题类型选目录,或者干脆同时查完再合并——这就是企业级系统里常见的混合检索思路。

score=α×cos⁡(q⃗,d⃗)+(1−α)×BM25(q,d)\displaystyle \text{score} = \alpha \times \cos(\vec{q}, \vec{d}) + (1 - \alpha) \times \mathrm{BM25}(q, d)
混合得分 = 语义相似度得分与关键词匹配得分的加权和,α 控制哪一边更重要。
  1. 向量语义分用余弦相似度衡量查询与文档在语义空间中的贴近程度。
    cos⁡(q⃗,d⃗)=q⃗⋅d⃗∥q⃗∥×∥d⃗∥\displaystyle \cos(\vec{q}, \vec{d}) = \frac{\vec{q} \cdot \vec{d}}{\|\vec{q}\| \times \|\vec{d}\|}
  2. 关键词分 BM25统计词频与逆文档频率,专门处理精确词条匹配。
    BM25(q,d)\mathrm{BM25}(q, d)
  3. 权重 α取值为 0 到 1,调节混合策略偏向语义还是偏向精确。
    α∈[0,1]\alpha \in [0, 1]

检索机制:图书管理员怎么高效找书

读者报出一个模糊需求,管理员不会把整座图书馆搬出来,而是先判断意图,再选目录,迅速锁定一摞候选书,最后把最相关的放在最上面。在 LlamaIndex 中,这个角色叫 Retriever(检索器)。不同的索引对应不同的检索器,查询进来后各走各的路。

向量检索的本质是向量空间中的距离比较,最常用的是余弦相似度:两个向量夹角越小,语义越接近。工程实现上,还会做 Query Transform——比如把复杂问题拆成多个子问题分别检索,或者先用大模型生成一个虚拟答案再检索(HyDE)。多路检索拿到的结果怎么合并?常用 RRF(倒数排名融合):按文档在每路结果中的名次打分,而不是看原始得分,这样不同打分体系也能公平比较。最后还可以接一个 Reranker 做精排。

在 LlamaIndex 里,你既可以用最简单的 retriever.retrieve(query),也可以自由组合:向量检索 + 关键词检索 → RRF 融合 → Reranker 精排 → 拼进提示词。检索链路越精细,回答的“地基”就越扎实。

检索不是一个“魔法按钮”,而是层层精筛的过程。管理员先把候选捞全,再排序、融合、精排,保证递到教授手里的每一份材料都相关、不重复、不跑题。

similarity⁡(q⃗,d⃗)=∑i=1nqi⋅di∑i=1nqi2×∑i=1ndi2\displaystyle \operatorname{similarity}(\vec{q}, \vec{d}) = \frac{\sum_{i=1}^{n} q_i \cdot d_i}{\sqrt{\sum_{i=1}^{n} q_i^2} \times \sqrt{\sum_{i=1}^{n} d_i^2}}
余弦相似度公式:它衡量两个向量方向的一致程度,取值约在 -1 到 1 之间,越大表示越相似。
  1. 分子点积两个向量对应维度相乘再累加,得到方向一致的量化值。
    q⃗⋅d⃗=∑i=1nqi×di\displaystyle \vec{q} \cdot \vec{d} = \sum_{i=1}^{n} q_i \times d_i
  2. 分母模长分别算出两个向量的长度再相乘,把结果归一化。
    ∥q⃗∥=∑i=1nqi2\displaystyle \|\vec{q}\| = \sqrt{\sum_{i=1}^{n} q_i^2}
  3. 整体比值归一化后只关心方向、不关心文本长短,避免长文档天然占便宜。
    q⃗⋅d⃗∥q⃗∥×∥d⃗∥∈[−1,1]\displaystyle \frac{\vec{q} \cdot \vec{d}}{\|\vec{q}\| \times \|\vec{d}\|} \in [-1, 1]

Agent编排:从找书到做研究

前面的能力都停留在“你要什么我找什么”。但真实需求往往是“帮我对标竞品的市场策略”——这需要查行业报告、抓最新新闻、读财报,再整理成对比表。普通的图书管理员做不了,需要一位升级版的研究助理:把大任务拆成小任务,按顺序执行,中途还能根据结果调整计划。这就是 Agent。

Agent 的骨架很简洁:一个大模型大脑负责思考和决策,一圈工具负责动手。工具注册(Tool Registration)就是把检索器、SQL 查询、外部 API 包装成“名称 + 功能描述 + 可执行函数”的结构,让大模型知道什么场景该用什么工具。核心循环叫 ReAct:Thought(思考)→ Action(行动)→ Observation(观察)→ 再思考,直到模型认为信息足够,输出最终答案。

LlamaIndex 的 Agent 层把这个循环封装得很好:你只需要注册好工具,剩下“该调哪个工具、参数填什么、要不要再查一次”全由大模型自主决定。工程上要注意设置 max_iterations 防止死循环,还要给工具写清楚边界,避免模型在模棱两可时乱调。

从“找一本书”到“做一项研究”,Agent 的价值在于把复杂问题拆成几步,让每一步都有据可查、可回溯。这是企业级知识库从“问答机器人”进化到“智能助理”的关键一步。

(Thoughtt, Actiont, Obst)→(Thoughtt+1, Actiont+1, Obst+1)\displaystyle (\mathrm{Thought}_t,\ \mathrm{Action}_t,\ \mathrm{Obs}_t) \rightarrow (\mathrm{Thought}_{t+1},\ \mathrm{Action}_{t+1},\ \mathrm{Obs}_{t+1})
这是 ReAct 循环的一步:思考、行动、观察,然后再进入下一轮,直到问题解决。
  1. 思考 Thought模型用自然语言表达“我现在缺什么信息、下一步该做什么”。
    Thoughtt=推导出下一步需要的信息\displaystyle \mathrm{Thought}_t = \text{推导出下一步需要的信息}
  2. 行动 Action调用某个已注册工具,例如执行一次检索。
    Actiont=Tool(x)\displaystyle \mathrm{Action}_t = \text{Tool}(x)
  3. 观察 Obs把工具返回的结果作为新观察,喂回模型。
    Obst=Result→Thoughtt+1\displaystyle \mathrm{Obs}_t = \text{Result} \rightarrow \mathrm{Thought}_{t+1}
  4. 结束条件模型判断信息足够时,不再调用工具,直接输出答案。
    若无需更多信息,输出 Answer\text{若无需更多信息,输出}\ \mathrm{Answer}

应用实践:企业知识库落地实战

企业不是 demo 环境,图书馆正式开业就要考虑排队、丢书、权限。以最典型的 HR 制度问答为例:把制度文档装载、切分、建索引之后,员工问“年假怎么算”,Agent 先判断问题属于哪个模块,再检索对应制度文件,必要时调用计算工具算天数,最后给出带出处的答案。

企业落地有四件绕不开的事。第一是权限隔离:利用节点元数据打部门标签,检索时强制过滤,保证 A 部门文档不会被 B 部门员工搜到。第二是增量更新:制度会变,知识库不能只建一次,要用 update_ref_docs 或定期重建索引,否则就会出现“问新政策得旧答案”的尴尬。第三是评测驱动优化:准备一批标准问答对,量出 Recall@k 等指标,用数据说话,而不是靠感觉调参。第四是性能优化:高频问题做缓存,向量数据库开连接池,检索链路上能并行的不要串行。

评测指标中最朴素也最实用的是 Recall@k:看前 k 条检索结果里,真正相关的文档占全部相关文档的比例。它不关心排序的精细程度,只关心“该捞上来的捞上来了没有”。

图书馆的生命力在于持续运营:权限、更新、评估、调优。指标就是读者的满意度,只有把 Recall@k 这类指标量化出来,优化才有方向,知识库才会越用越准。

Recall@k⁡=∣Rrel∩Rretrieved∣∣Rrel∣\displaystyle \operatorname{Recall@k} = \frac{|\mathcal{R}_{\text{rel}} \cap \mathcal{R}_{\text{retrieved}}|}{|\mathcal{R}_{\text{rel}}|}
前 k 条检索结果中,相关文档被召回的比例。这是评估检索器质量的入门指标。
  1. 分子前 k 条结果中,确实相关的文档数量。
    ∣Rrel∩Rretrieved∣\displaystyle |\mathcal{R}_{\text{rel}} \cap \mathcal{R}_{\text{retrieved}}|
  2. 分母评测集中标注的全部相关文档数量。
    ∣Rrel∣\displaystyle |\mathcal{R}_{\text{rel}}|
  3. 比值k 越大召回越高,但引入的噪音也越多,需要在召回率和精确率之间取平衡。
    Recall@k∈[0,1]\displaystyle \text{Recall@k} \in [0, 1]

AI 应用场景

企业知识库问答机器人(HR / IT 支持)

阶段:数据装载 → 索引体系 → 检索机制 → Agent 编排

解决的问题:传统企业资料分散在 wiki、网盘、OA 系统里,员工搜不到答案,只能反复问 HR 和 IT。LlamaIndex 把这些数据源统一接入、切分索引,再用 Agent 按问题类型路由到对应制度库,回答同时附上原文链接,既提效又留痕。

具体案例:一家 2000 人公司把 1.2 万份制度、公告、FAQ 接入 LlamaIndex。员工问“产假有多少天”,Agent 先判断这是 HR 模块,检索 top-5 制度节点,再结合休假规则计算天数,返回答案并标注文件页码。上线后一线 HR 咨询量下降 40%。

竞品情报自动聚合(投研 / 市场)

阶段:Agent 编排 → 多步推理 → 检索机制

解决的问题:研究员每天要翻新闻、公告、研报才能写出一份竞品简报,手工检索耗时长且容易漏。LlamaIndex Agent 把“新闻检索、公告检索、研报摘要”注册成工具,按 ReAct 循环依次调用,最后汇总成结构化日报。

具体案例:某券商研究部部署了一套竞品动态 Agent,每天 8 点自动抓取目标公司公告,检索相关研报,多步归纳后推送企业微信群。单份日报从人工 2 小时缩短到 5 分钟,且覆盖源更全。

Python 演示

python115 行
"""Mini LlamaIndex demo: load -> split -> index -> retrieve -> agent"""import mathimport re  class Document:    def __init__(self, text, source=""):        self.text = text        self.source = source  class Node:    def __init__(self, text, doc_id, idx):        self.text = text        self.doc_id = doc_id        self.idx = idx  def split_nodes(doc, size=10, overlap=2):    words = doc.text.split()    nodes = []    start = 0    while start < len(words):        chunk = words[start:start + size]        nodes.append(Node(" ".join(chunk), doc.source, start))        start += size - overlap    return nodes  def build_keyword_index(nodes):    index = {}    for n in nodes:        for w in set(re.findall(r"\w+", n.text.lower())):            index.setdefault(w, []).append(n)    return index  def keyword_retrieve(query, index):    hits = []    for w in re.findall(r"\w+", query.lower()):        hits.extend(index.get(w, []))    seen, out = set(), []    for n in hits:        if id(n) not in seen:            seen.add(id(n))            out.append(n)    return out  def to_vec(text):    v = {}    for w in re.findall(r"\w+", text.lower()):        v[w] = v.get(w, 0) + 1    return v  def cosine(a, b):    inter = set(a) & set(b)    dot = sum(a[w] * b[w] for w in inter)    na = math.sqrt(sum(x * x for x in a.values()))    nb = math.sqrt(sum(x * x for x in b.values()))    return dot / (na * nb) if na and nb else 0.0  def vector_retrieve(query, nodes, top_k=2):    qv = to_vec(query)    ranked = sorted(nodes, key=lambda n: cosine(qv, to_vec(n.text)), reverse=True)    return ranked[:top_k]  def run_agent(query, tools):    notes = []    for step_name in ["collect nodes", "extract key info"]:        if step_name == "collect nodes":            for tool in tools:                notes.extend(tool(query))    return notes  def main():    docs = [        Document("LlamaIndex is a bridge between LLM and private data.", "guide.txt"),        Document("Vector index works well for semantic similarity search.", "arch.txt"),        Document("Agent can call multiple tools for multi-step reasoning.", "agent.txt"),        Document("Semantic retrieval helps find related context quickly.", "tips.txt"),    ]    nodes = []    for d in docs:        nodes.extend(split_nodes(d, size=10, overlap=2))     kidx = build_keyword_index(nodes)    query = "semantic similarity"     print("=== Keyword retrieve ===")    for n in keyword_retrieve(query, kidx)[:2]:        print(" -", n.text)     print("=== Vector retrieve ===")    for n in vector_retrieve(query, nodes):        print(" -", n.text)     print("=== Agent collect ===")    notes = run_agent(        query,        [            lambda q: keyword_retrieve(q, kidx),            lambda q: vector_retrieve(q, nodes),        ],    )    for n in notes:        print(" ~", n.text)  if __name__ == "__main__":    main()
目的:用纯 Python 模拟 LlamaIndex 的核心流程——文档切分、关键词倒排索引、向量余弦检索、Agent 多工具聚合,无需安装任何第三方库即可运行。
  1. while start < len(words):按 size - overlap 的步进切分文档,重叠部分保证跨块上下文不断裂。
  2. nodes.append(Node(" ".join(chunk), doc.source, start))每个切块包装成 Node,并记录来源和起始位置。
  3. index.setdefault(w, []).append(n)构建“词 → 节点列表”的倒排索引,关键词检索的基础。
  4. ranked = sorted(nodes, key=lambda n: cosine(qv, to_vec(n.text)), reverse=True)用余弦相似度对全部节点排序,模拟向量检索的 top-k。
  5. notes.extend(tool(query))Agent 把多个工具的结果合并收集,为下一步推理准备材料。

常见误区

误区很多人一上来就把所有文档 embedding 进向量库,认为语义检索能搞定一切。结果追问订单编号、产品型号、代码片段时,答案经常驴唇不对马嘴。

正解向量索引擅长“意思相近”的召回,但遇到精确词、唯一编号、短代码时反而吃亏。关键词索引在精确匹配上更可靠。真实系统应当按查询特点做混合检索:先用路由判断问题类型,再决定走向量、关键词还是两者都走。

为何常见:Embedding 和语义搜索是当下最热门的概念,容易让人产生“语义能秒杀一切”的错觉,忽略了精确匹配这个朴素而刚需的场景。

误区有人把文档切成几十个字的碎块,认为块小命中准。结果检索到的片段都是孤立的词句,大模型根本看不出上下文,回答自然支离破碎。

正解块太小会丢失上下文,块太大又引入噪音。通常按 256~512 token 切分,并设置 10%~20% 的重叠。具体数值要结合文档类型评测,而不是拍脑袋定一个极小的值。

为何常见:把“粒度细”等同于“精度高”,忽略了语言理解需要上下文这一基本事实。

误区有人觉得给 Agent 注册十几个工具,它就能解决所有问题。实际运行时模型频繁选错工具、参数填错、反复试错,延迟飙升还答非所问。

正解工具数量要克制,每个工具必须有清晰唯一的 name 和 description,让模型一眼知道“什么时候用、不用的时候别碰”。复杂场景可以分层:先用一个路由 Agent 判断领域,再分发给专门的子 Agent。

为何常见:对大模型推理能力过度期待,忽略了工具选择的决策负担会随工具数量急剧上升。

误区很多人本地跑通一个知识库 demo,就把检索结果直接拼进提示词上线。结果线上问题五花八门,回答质量忽高忽低,却说不出哪里出了问题。

正解检索质量必须用评测集量化。先准备一批标准问答对,算 Recall@k 和命中率,再逐步调 chunk、调融合权重、加 Reranker。每一步优化都要有指标对比。

为何常见:demo 能跑通让人误以为生产可用,忽略了真实数据噪音和评测迭代的工程必要性。

面试题

Q1. LlamaIndex 的核心定位是什么?

单选题 · easy

  • A.训练大模型的预训练框架
  • B.连接大模型与私有数据← 正确答案
  • C.替代向量数据库的存储
  • D.大模型分布式推理加速

答案:B。LlamaIndex 是数据框架,负责把私有数据组织成可检索的索引并交给大模型使用。它不训练模型、不自己做向量存储、也不做推理加速。正如图书馆不负责教书,只负责把书摆好递到教授手里。

Q2. 向量索引主要依据什么实现语义检索?

单选题 · easy

  • A.关键词的倒排表
  • B.文档的字符统计
  • C.嵌入向量相似度← 正确答案
  • D.文档的访问次数

答案:C。向量索引把文档和查询都映射成高维向量,用余弦相似度等度量判断语义远近。关键词倒排表是关键词索引的做法,字符统计和访问次数与语义无关。

Q3. 哪类场景更适合使用关键词索引?

单选题 · easy

  • A.语义模糊的开放问答
  • B.精确代码片段和编号← 正确答案
  • C.长文档自动生成摘要
  • D.图片分类与标签预测

答案:B。代码片段、订单号、产品型号这类精确词,语义检索反而容易跑偏,关键词索引靠倒排表精确命中。语义模糊的开放问答是向量索引的主场。

Q4. 下列哪些属于 LlamaIndex 的索引类型?

多选题 · mid

  • A.向量索引← 正确答案
  • B.关键词索引← 正确答案
  • C.SQL索引
  • D.树状索引← 正确答案

答案:ABD。LlamaIndex 提供了向量索引、关键词索引、树状索引、摘要索引等。SQL 索引不是独立索引类型,LlamaIndex 里的 SQL 相关能力属于查询引擎或数据连接模块。

Q5. 切分文档时设置 overlap 的主要目的是什么?

单选题 · mid

  • A.减少节点数量节省存储
  • B.保持跨块上下文连贯← 正确答案
  • C.加快文本切分的速度
  • D.完全消除重复内容

答案:B。overlap 让相邻节点共享部分文本,避免关键信息恰好被切在边界上而丢失上下文。它不会减少节点数,反而会略微增加,也不能消除重复。

Q6. RRF 融合多路检索结果时,主要依赖哪些信息?

多选题 · mid

  • A.每路检索的原始得分
  • B.文档在各路的名次← 正确答案
  • C.检索器的类型名称
  • D.固定常数 k 的调节← 正确答案

答案:BD。RRF 不看原始得分,只看文档在每路结果中的排名,用 1/(k+rank) 累加。这样不同打分体系的检索器也能公平融合。常数 k 用于平滑排名影响。

Q7. ReAct 循环中正确的执行顺序是什么?

单选题 · hard

  • A.行动 → 观察 → 思考
  • B.观察 → 思考 → 行动
  • C.思考 → 行动 → 观察← 正确答案
  • D.思考 → 观察 → 行动

答案:C。ReAct 的每一步是“先思考下一步要什么信息,再调用工具行动,最后观察返回结果”,然后带着观察进入下一轮思考。顺序错了,模型就失去了决策依据。

Q8. 企业知识库项目上线前,最先应该做哪件事?

单选题 · mid

  • A.微调大模型适配领域
  • B.建立评测集再调优← 正确答案
  • C.更换更大的 GPU 服务器
  • D.把所有文档切成最小块

答案:B。先建评测集,才能量化检索和回答质量,后续切分、融合、重排的优化才有依据。盲目微调或堆算力都解决不了“查不准”这个核心问题。

Q9. 注册工具给 Agent 时,必须提供哪些信息?

多选题 · hard

  • A.工具的鉴权凭证
  • B.工具有效名称与描述← 正确答案
  • C.可执行函数的实现← 正确答案
  • D.工具内部训练样本

答案:BC。大模型靠名称和描述决定何时调用,靠可执行函数真正执行。鉴权凭证属于运行时配置而非注册信息,训练样本与工具调用无关。注册信息的核心是“让模型看得懂、调得对”。

Q10. 在 LlamaIndex 中,Document 与 Node 是什么关系?

单选题 · mid

  • A.彼此独立毫无联系
  • B.单节点包裹多个文档
  • C.文档被切分为多个节点← 正确答案
  • D.文档属于节点的元数据

答案:C。一个 Document 是原始数据源,经过切分后产生多个 Node,Node 是最小检索单元。节点包含文本、来源和索引位置,并可以挂载元数据。关系是“一对多”。