MaxKB

项目简介

MaxKB 是基于 Python、Django 和 PostgreSQL 的知识库与智能体平台，支持文档入库、知识检索、可视化工作流及工具调用。问答可以按命中资料直接回复，也可以将资料和历史交给模型生成；常见问法和人工改答可补充到知识库。

如何写进简历

面试题与回答

1. 如何提高知识库检索召回的准确性与上下文匹配能力？

   展开收起

   核心回答

   在 MaxKB 中，提高检索准确性要同时处理检索范围、问题表达、候选排序和最终上下文。它用 Python 实现知识库问答与工作流，PostgreSQL/pgvector 保存检索数据；工作流中的知识库检索节点先按范围召回段落，需要精排时再连接独立的重排节点。

   具体来说，先限定允许查询的知识库或文档，检查有效段落是否完成索引；再用关联问题补充用户常见问法，选择 embedding、keywords 或 blend 模式，并分别调整召回与重排的 top_n、similarity。最后检查实际拼接文本，确认关键条件没有被字符预算截掉。分数高、返回段落多，都不等于回答所需的上下文完整。

   范围和参数怎样影响召回

   知识库检索节点既能使用配置的知识库列表，也能引用上游输出的知识库或文档列表。执行时先过滤可用的授权资源，检查所选知识库是否使用相同的向量模型，再排除禁用文档，并在检索查询中要求索引记录有效、排除指定段落。没有可用知识库时返回空结果。

   top_n 控制返回段落数，similarity 是当前检索分数的筛选门槛。多库查询会逐库取结果，再按分数合并，最终只保留全局前 top_n 段，并非每个库各保留这么多段。因此，某个知识库有正确证据，仍可能在全局截取时被挤掉。范围过滤、逐库查询和结果截取分别见检索节点与向量存储查询。

   三种模式的分数含义不同：

   • embedding 按向量距离得到语义相似度，适合措辞不同但含义接近的问题。
   • keywords 使用全文检索与 ts_rank_cd 排序，查询分词会采用知识库的自定义术语。
   • 当前 blend 先取向量近邻窗口，最多 min(top_n × 10, 500) 条索引记录，再叠加这些记录的全文分数，按段落保留最高分并筛选、排序。它没有将两路独立候选做并集，也没有使用 RRF；向量窗口外的纯关键词证据不会因此补进来。

   所以切换模式后，需要重新校准阈值。若精确术语始终漏召回，应对照关键词检索与混合检索的候选，而非只降低混合分数门槛。具体评分与窗口见混合检索 SQL。

   关联问题和人工改答怎样补覆盖

   MaxKB 可以把常见问法关联到已有段落。索引中既包含段落内容的分块，也包含关联问题的文本；每条记录都保留对应的 paragraph_id。用户命中某种问法后，系统按段落归并结果，再取回段落正文。因此，关联问题扩展的是找到答案的入口，返回的证据仍来自对应段落。

   人工改答也能用于补充知识：聊天记录的改答操作在事务中新增答案段落，创建或复用问题并保存问题—段落映射，随后触发该段落向量化。这让经过修订的答案有机会被后续相近提问检索到，属于知识与索引更新；模型参数没有因此被训练，向量化完成后仍要用相关问题验证是否正确命中。实现见人工改答与后置向量化。

   问题与段落的关联要覆盖真实问法，也要避免把适用条件不同的问题全部挂到同一答案上。若正文缺少必要条件，补再多关联问题也只能更容易找到一段不完整的证据。

   重排与上下文各管什么

   工作流的重排节点接收上游候选，把标题和正文交给所选重排模型，再按重排分数、top_n 和 max_paragraph_char_number 筛选输出。它能调整已有候选的顺序，无法补回检索范围或候选窗口外的段落；其 similarity 针对重排结果，不能与召回分数混为同一标准。

   检索节点本身按相似度排序后拼接标题与正文，再按字符数切片；它不会自动按照原文顺序补回相邻段落。重排节点也有自己的字符预算。因此，正确段落命中却漏掉例外条件时，要查看实际输出文本，区分条件原本不在候选、排在预算之后，还是在段落中途被截断。可以调整分段，让规则与条件保持完整，再分别控制候选规模和最终引用长度。

   验证时固定文档与问题集，比较各模式下的必要证据覆盖、正确段落排名、最终文本完整度、答案及延迟。对人工改答，还应补测同义问法和条件相近但答案不同的问题，确认改善覆盖的同时没有增加误匹配。

   参考资料

   • 国内：飞致云：MaxKB 问题管理：采用维护常见问题并关联文档分段的方式，解释正文中用问题表达补充段落召回入口的做法。
   • 国外：Sentence Transformers：Retrieve & Re-Rank：依据候选检索与联合精排的分工，解释重排只能优化输入候选，以及候选数量与计算成本的取舍。

2. RAG 检索精度已经较好但生成答案仍不准确时，除了优化检索还能怎样改进？

   展开收起

   核心回答

   在 MaxKB 中，应对照命中的分段、实际引用文本、历史消息和最终回答分支排查。命中完整段落后，引用字符预算仍可能截掉段尾条件；历史对话也不属于这项引用预算。另一方面，符合直接回答条件时可能直接返回分段，问题未必发生在大模型生成阶段。

   以企业制度问答为例，命中“可以报销”的规定，但发送给模型的引用漏掉了后面的适用对象，模型仍可能答错。应先把最终输入中的条件补完整，再调整生成提示词或模型；对于适合原文回答的标准问题，还可以配置直接回答，并验证其命中条件。

   引用字符数控制的是哪部分内容

   工作流的知识库检索节点同时输出完整的 paragraph_list 和供提示词引用的 data。data 将标题、正文拼接后，按 max_paragraph_char_number 做字符切片。因此，完整列表里有答案，并不能证明 AI 节点使用的 data 也保留了完整条件。若连接了独立重排节点，还要查看它实际输出的 result，而不是只看上游分段列表。检索节点输出、重排节点的字符裁剪。

   仓库还保留独立的 chat_simple 流水线，依次执行检索、用户消息组装和回答。它按顺序保留 title:content，超过剩余字符容量时截取当前段落，再包成 <data> 填入提示词。这项限制不包含标签、换行、系统提示词和历史消息，也不是整次请求的 Token 上限。简单应用入口、简单应用消息组装。

   历史按 dialogue_number 选择最近的对话记录，再组装用户与 AI 消息，并非自动按剩余 Token 容量截断。排查时可比较关闭历史与保留必要历史的结果，确认旧回答有没有覆盖当前资料；同时检查实际模型输入长度。简单应用历史组装、工作流 AI 节点历史选择。

   先确认答案走了哪条分支

   内置“知识库问答助手”工作流模板有三条分支：满足直接回答条件时，回复节点引用 directly_return；有分段但未满足直接回答条件时，AI 节点读取 data 与用户问题；无分段时，返回预设的无资料回复。检索节点只是提供结果和命中标记，实际走向由后续判断器与连线决定，用户修改过的工作流也应按其实际连线核对。模板判断条件、直接回复、AI 与无资料节点。

   chat_simple 则在检索阶段优先选出满足文档直接回答配置的候选，回答步骤再次检查相似度条件后直接输出分段内容。无分段且配置为 designated_answer 时返回指定回复；配置为 ai_questioning 时，可继续将无引用提示词发给模型，并不会自动拒答。直接候选选择、回答分支、无引用提示词。

   直接返回能保留原分段措辞，但仍依赖命中的文档版本、适用对象与阈值是否正确。如果当前答案来自直接回复分支，应先改相应资料或分支条件；修改 AI 提示词不会改变这条分支的输出。

   可用哪些样本复核

   可以准备三组对照：同一段规则的适用条件放在引用预算内外；同一问题带有或不带有旧历史回答；同一问题分别触发直接回答、模型生成和无资料回复。每组都记录实际节点输出、最终消息和所走分支，再核对条件是否保留、是否调用模型以及答案依据。