主要技术：Django、MaxKB、LangChain、PostgreSQL、pgvector
项目目录
项目简介
MaxKB 是开源知识库问答与智能体平台，可以上传文档或采集在线资料，经过分段和向量化后搭建问答应用。对于需要多步处理的任务，也可以在画布中连接知识检索、模型、判断器、函数和工具，并将问答入口嵌入已有系统。
它的内置知识库问答模板把结果分成标准内容直返、模型解释和无资料回复：固定问题可保留资料原文，需要归纳时再交给模型。前端使用 Vue，后端基于 Python、Django 与 LangChain，由 PostgreSQL、pgvector 保存知识索引及检索数据。
项目亮点
- 常见问法可以指向同一段证据。 问题与知识段落建立映射，问题文本单独参与向量索引；命中后按
paragraph_id回取正文，让口语化问法与资料原文之间多一条检索入口。 - 召回与重排是独立步骤。 检索节点按知识库或文档范围取候选，工作流再按需连接重排节点。候选数量、检索分数、重排分数和引用字符数分别配置，便于检查证据是没找到、排序靠后，还是进入模型前被裁掉。
- 回答分支由流程明确选择。 检索节点输出
paragraph_list、data和directly_return，判断器据此连接标准回复、模型生成或无资料提示；同一资料命中后是否调用模型，可以在节点连线中看清。 - 人工修正能补入后续检索。 对话改答操作在事务中保存新段落、问题映射和改答标记，再触发向量化，使人工确认过的答案成为新的知识入口。
技术架构
ui/ 提供知识管理、应用配置与工作流画布，Django 接口承接文档和问答请求。资料以知识库、文档、段落及关联问题组织，向量和关键词索引保留段落身份；检索时先按资源范围筛选，再从 PostgreSQL 中取回候选正文。
工作流把检索结果交给独立重排、判断器或 AI 节点，变量引用决定后续使用哪份文本。仓库还保留简单应用的问答流水线，两条执行路线各自组装引用和历史；排查时应核对实际应用类型与最终模型输入。
| 代码位置 | 职责 |
|---|---|
ui/src/workflow/、ui/src/workflow/common/template.ts |
画布、内置问答模板与结果分支 |
apps/knowledge/vector/pg_vector.py、apps/knowledge/sql/ |
向量、关键词与混合模式的候选查询 |
apps/application/flow/step_node/search_knowledge_node/、apps/application/flow/step_node/reranker_node/ |
检索范围、候选重排与引用文本输出 |
apps/application/flow/step_node/ai_chat_step_node/、apps/application/chat_pipeline/ |
工作流和简单应用的消息组装与回答 |
apps/knowledge/serializers/paragraph.py、apps/application/serializers/application_chat_record.py |
问题关联、人工改答及后续向量化入口 |
如何写进简历
差旅智答 · 差旅报销制度助手 | 企业服务业场景示例
项目描述：面向企业员工的差旅报销制度助手，查询交通、住宿和凭证要求，结合出差条件返回标准条款或解释，并支持围绕制度继续追问。
技术栈：Python、Django、MaxKB、LangChain、PostgreSQL、pgvector
主要工作：
- 问题与条款双入口索引：将常见报销问法关联到制度段落，分别为问题和正文建立向量入口；检索后按
paragraph_id归并同一条款的多次命中并保留最高分，再回取正文，兼顾口语化问法与制度原文表达。 - pgvector 检索与独立重排：基于
pgvector在适用制度范围内检索候选，再显式衔接独立重排节点，以模型分数、条数和字符预算筛选材料；分开控制召回与精排，将报销金额、条件和凭证说明组织为回答依据。 - 标准条款与解释链路分流：通过工作流判断器区分
directly_return、普通命中和无资料结果，固定制度说明按原文返回，条件解释进入模型节点；结合近期对话与本次提问组装上下文，支持员工补充出差条件后继续询问。
住店百事通 · 酒店住客服务问答助手 | 酒店业场景示例
项目描述：面向酒店住客的服务问答系统，结合门店服务手册回答早餐、停车和设施使用问题，支持标准答复、进一步解释及前台改答后的知识更新。
技术栈：Python、Django、MaxKB、LangChain、PostgreSQL、pgvector
主要工作：
- FAQ 问法与服务知识归并：将早餐时间、停车规则等不同问法关联到同一服务段落，为问法和正文分别建立检索入口；按
paragraph_id汇合同一说明的候选，再返回正文与文档身份，减少相近问法重复占用回答上下文。 - 标准答复与模型解释分支：按服务段落的处理方式与命中阈值生成
directly_return，通过工作流判断器选择原文答复、模型解释或无资料提示；将固定时段、收费规则与开放性咨询分开处理，减少标准说明被反复改写。 - 人工改答事务与知识补充：基于
Django事务将前台修订写为新服务段落，建立问题关联并记录会话改答标记，再触发向量化供后续检索；以段落、问题和对话关系保留修订来源，衔接人工反馈与知识维护。
面试题与回答
2 题如何提高知识库检索召回的准确性与上下文匹配能力？
展开收起
核心回答
在
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：依据候选检索与联合精排的分工，解释重排只能优化输入候选，以及候选数量与计算成本的取舍。
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 提示词不会改变这条分支的输出。
可用哪些样本复核
可以准备三组对照：同一段规则的适用条件放在引用预算内外；同一问题带有或不带有旧历史回答；同一问题分别触发直接回答、模型生成和无资料回复。每组都记录实际节点输出、最终消息和所走分支，再核对条件是否保留、是否调用模型以及答案依据。