Sikhbani.ai 是一个面向《Sri Guru Granth Sahib》的 AI 问答应用。用户输入一个问题它从这部锡克教圣典中检索相关段落再由大语言模型组织成一段回答。放到 AI 应用开发的坐标系里看它不是某个全新的基础模型而是一个把经典文本、向量检索、提示词工程和模型生成组合在一起的垂直问答系统。这种组合在工程上更常用的名字是 RAG也就是检索增强生成。如果你正在做文化经典、专利文档、企业内部知识库或长文本问答类应用这个项目的拆解价值不低。这篇文章会从问题定义、数据准备、检索链路、模型选型、质量评估和上线细节几个角度展开顺便把我在类似项目里踩过的坑放进去。核心观点先说在前面这类项目能不能做好第一优先级不是模型多强而是文本结构处理得清不清楚、检索结果准不准、提示词有没有让模型克制下来。1. 先确认 Sikhbani.ai 解决的是什么问题1.1 它是“向经典文本提问”不是通用闲聊这类问答系统的关键特征不是模型能力而是“知识边界”。通用聊天机器人可以回答天气、代码、菜谱而 Sikhbani.ai 这类应用会把回答范围限制在《Sri Guru Granth Sahib》这部文本之内。用户问“圣典里如何看待诚实劳动”系统要先到文本库里找相关段落再让大模型基于这些段落写出回答。这个“先检索、再生成”的过程决定了它和通用大模型聊天的体验差异答案能追踪到原文上下文不会随意发散也不会把其他领域的知识混进来。对用户来说它更像一个带着原文依据的导读工具而不是一个试图替经典下结论的解释器。1.2 和普通关键词搜索相比它多出的是语言组织能力如果只做关键词搜索也能搜出包含“诚实”“劳动”的段落但用户拿到的是零散片段甚至要自己在十几段原文里翻找。Sikhbani.ai 这类应用会额外做两件事把最相关的几个段落筛选出来再让大模型调整表述让回答更像一段完整说明。所以它的价值不只是“找到相关文本”而是“基于相关文本给出可读性更强的解答”。这正好落在传统搜索和通用大模型之间的空档。搜索少了组织通用大模型少了依据RAG 就是想两边都占住。1.3 谁适合参考这个项目做文化经典数字化的团队需要把古籍、经卷、地方志做成可问答的知识库。做企业内部知识库 QA 的工程师可以把经典问答当作简化版 RAG 案例来研究。对《Sri Guru Granth Sahib》有兴趣但缺乏阅读背景的人可以借助问答工具快速了解原文中的相关表述。做 AI 应用开发或本地部署学习的人可以用它理解检索增强生成、向量检索、提示词工程的分工。可以这么说Sikhbani.ai 是“垂直知识库问答”这个大家庭里的一个典型案例。它解决的问题不是“如何训练一个无所不知的大模型”而是“如何让一个通用模型在特定文本范围内保持稳定”。2. 从文本到问答整条链路怎么拆2.1 四层结构RAG 类应用通常可以拆成四层数据层、检索层、增强层、生成层。数据层负责把原始经典文本转成适合检索的切片检索层根据用户问题找出最相关的切片增强层把这些切片与用户问题一起拼进提示词生成层让大模型基于提示词输出答案。Sikhbani.ai 不管最终界面多简单底层几乎都会走这条链路。理解这四层之后很多问题的排查方向就清楚了。比如果回答质量差你可以先判断是检索层召回了错误内容还是生成层没有正确使用检索结果而不是笼统地归咎于“模型不行”。2.2 为什么第一版优先选 RAG而不是直接微调面对“AI 问答圣典”这个需求有人会想直接拿开源大模型微调一部圣典语料是不是效果更好我的建议是第一版不要这样做原因有四个。第一微调需要大量高质量的问答对。把一部经典整理成问答对标注成本很高而且很容易在整理时就加入主观解释。第二圣典文本可能存在多版本、多语言、注释不同的问题。微调会把知识固化进模型权重文本版本一旦更新就要重新训练。RAG 只需要替换数据库或更新文档改动成本低得多。第三RAG 可以给出出处。系统能告诉用户“这个回答来自哪一段”这对严肃阅读特别重要。微调模型很难在回答时稳定输出具体出处。第四从工程效率角度看RAG 不需要高显存训练环境普通开发机就能验证。微调哪怕用 LoRA也要比一个检索链路复杂不少。所以先用 RAG 做第一版是更稳的路线。等将来积累了足够多的问答对再考虑用微调优化特定场景。2.3 数据准备第一件事是给原文做结构化切分经典文本和一般 PDF 很不一样切分方式直接决定检索质量。以《Sri Guru Granth Sahib》为例它通常按章节组织每个章节里有具体唱段还会伴随原语言、音译、翻译等不同版本。如果直接把整章塞进一个向量里或者按固定 500 字硬切检索出来的片段很容易语义不完整。比较常见的做法是按语义单元切。如果一个段落本身由多个小段组成可以再细分但尽量保持每个片段表达一个相对完整的意思。同时要在元数据里记录章节号、版本、语言、翻译对应关系。这样检索之后系统才能知道“这个片段属于哪一章、来自哪个版本”后续回答才可以带出处。切分参数上文本长度和重叠区间需要实际验证。下面是一个通用示例不是 Sikhbani.ai 的官方参数from langchain_text_splitters import RecursiveCharacterTextSplitter text_splitter RecursiveCharacterTextSplitter( chunk_size600, chunk_overlap80, separators[\n\n, \n, 。, ., ] ) chunks text_splitter.split_text(original_text) print(len(chunks))chunk_size 越大每个片段上下文越完整但单个向量包含的信息越杂检索精度可能下降。overlap 太小跨边界的句子会断开overlap 太大索引体积和重复片段变多。建议先跑一轮测试把明显语义半截的片段找出来再调整参数。2.4 检索层怎么找到最相关的段落检索层有两种常见思路向量检索和关键词检索。向量检索擅长处理语义相近的表达比如用户问“服务他人”文本里可能是“seva”关键词检索擅长精确匹配术语。经典文本场景容易出现术语音译差异所以实际项目里经常把两者做混合检索。向量检索依赖嵌入模型。嵌入模型决定文本以什么方式映射到向量空间。如果语料包含多种语言和大量专有名词嵌入模型的选择比想象中更重要。不要只看模型参数量要看它对目标语言的实际支持效果。最稳妥的办法是准备一批测试问题分别用不同嵌入模型跑检索再人工看召回结果是否合理。top_k 是常见的检索参数表示返回多少个相关片段给大模型。数值太小模型没有足够上下文数值太大无关信息混进去回答反而容易发散。如果一部经典文本比较长我建议从 top_k6 到 8 开始试再根据回答质量调整。检索索引的通用示例from langchain_core.documents import Document from langchain_community.vectorstores import FAISS from langchain_huggingface import HuggingFaceEmbeddings # 实际使用时嵌入模型要按你的语言场景选择 embeddings HuggingFaceEmbeddings(model_nameyour-embedding-model-name) docs [ Document( page_contentc, metadata{source: guru_granth_sahib, section: unknown} ) for c in chunks ] vectorstore FAISS.from_documents(docs, embeddings) retriever vectorstore.as_retriever(search_kwargs{k: 6}) result retriever.invoke(圣典中如何描述服务他人的行为) for doc in result: print(doc.page_content)这段代码是通用示例。具体嵌入模型名称、向量库类型、索引路径要以你自己的环境和数据为准。2.5 生成层让大模型只做“语言重组”不做“自由创作”RAG 里最难的一点不是让模型答出来而是让模型克制住不把检索上下文之外的信息编进来。经典问答场景尤其如此。用户问的是某部典籍里的内容答案必须落在文本依据上。一个比较稳的提示词结构包含三部分角色定义、约束条件、输入材料。下面是一个通用模板prompt_template 你是一个经典文本问答助手。 请严格根据下面提供的参考段落回答问题。 如果参考段落中没有相关内容请直接说“没有找到相关依据”不要自行发挥。 回答时尽量用日常语言解释可以在末尾标注来源段落编号。 参考段落 {context} 用户问题 {question} 这里最关键的一句是“没有找到相关依据就直说”。它能让模型在检索结果为空时放弃编造而不是硬凑一个答案。实际效果不会每次都很完美但提示词里先写明这个约束能明显减少幻觉。温度参数也值得注意。问答类场景通常把 temperature 调低一些比如 0 到 0.3输出会更稳定。如果调得太高模型每次回答的措辞差异很大对严肃阅读场景不是好事。3. 本地部署的最低条件与参数取舍3.1 低配置机器也能跑但边界要降下来Sikhbani.ai 这类应用如果做成本地部署资源需求主要来自两部分嵌入模型和大语言模型。嵌入模型通常很小普通 CPU 就能跑。生成模型才是资源大户。一个 7B 级别的开源对话模型量化后运行在 16GB 显存环境下比较常见显存只有 8GB 时可以尝试更小参数的模型或者降低上下文长度。如果完全没有 GPU也能用 CPU 跑但要接受速度慢很多。实测时不要一上来就追求“完美效果”。先跑通单条问答再逐步加长文本、加大并发。如果要做 AI 模型部署资源判断要比模型选型更早做否则后面每改一个参数都会碰到性能瓶颈。3.2 需要重点盯住的资源指标本地部署时我会关注四个指标显存占用看生成模型是否被完整加载是否有频繁的显存溢出。内存占用向量数据库、文档加载、模型推理都会吃内存。CPU 占用向量检索和文本预处理阶段是否出现高 CPU 等待。磁盘占用模型文件、向量索引、日志文件长期运行后会累积。判断标准很简单单条请求跑完后资源能释放连续跑 10 条不出错基本说明这个环境可以支撑原型。如果连续跑几条就开始卡顿或 OOM说明已经走到资源边界了。3.3 参数怎么取舍本地部署时最常调的参数大概是五类嵌入模型大小小模型加载快但多语言和专有名词能力可能弱。生成模型量化量化能降低显存占用但极端情况下输出质量略降。上下文长度本地跑不起来时优先砍掉不必要的历史对话和长文档加载。top_k检索片段太多会让 prompt 变长直接影响显存和响应速度。并发数刚开始设 1跑通后按资源余量逐步加到 2、4。这些参数没有固定最优值。你只要记住一个原则先保证稳定再追求效果先压资源再谈并发。3.4 一条合适的验证路径单条、批量、接口很多人在本地部署阶段就踩了“一步到位”的坑直接写一个 Web 服务然后跑 200 个文件最后发现全乱。我建议按这个顺序来先跑单条问题。确认输入、检索、生成、输出全程无报错。再跑一个小批量比如 10 条问题。看平均耗时、失败率和日志。最后再封装成接口。接口层只需要关心请求格式、超时、错误码和日志。如果单条已经报错先不要开批量。先把错误日志读明白再说。批量任务能跑了才算真正具备“持续使用”的基础。4. 回答质量怎么评估不能只看“答得挺顺”4.1 建一个小规模评测集再谈优化判断 RAG 问答效果不能凭感觉。我一般会准备一个 20 到 50 条的评测集覆盖四类问题直接出处类比如“圣典里关于谦卑的表述有哪些”这类问题看重召回是否准确。概念解释类比如“seva 是什么”看重模型能否从多个片段里整合出解释。综合类比如“圣典如何看待帮助他人”看重多个片段的综合分析能力。无答案类比如“圣典里关于股票的表述”这类问题应返回“没有找到相关依据”最考验模型是否克制。评测集不用一次做全先做 20 条跑完记录结果再逐步扩充。重点是让每个版本的效果有可比性能复现。4.2 评估维度相关性、依据性、完整性、语言一致性、稳定性评估维度判断方式可接受标准相关性答案是否围绕用户问题展开不能答非所问依据性答案是否来自检索片段是否给出来源关键结论能在原文中找到对应完整性问题涉及多个角度时是否覆盖主要关键点不能只答一半语言一致性用户用什么语言提问回答应使用同一种语言不混用、不跳语言稳定性相同问题重复 3 到 5 次结果差异是否可接受措辞可以变核心含义不应飘这五个维度里依据性和稳定性最容易被忽略。依据性不足回答再有文采也像“模型编故事”稳定性不好用户今天看到一种解释明天又看到另一种信任感会明显下降。4.3 常见失败模式检索为空一般不是模型问题而是文本切分不合理、术语拼写不一致或嵌入模型语言支持不足。答案泛化模型没有认真使用检索片段而是凭通用知识回答。此时要检查提示词是否强调“只能使用参考段落”。幻觉模型输出了检索片段中不存在的内容。最有效的缓解办法是让模型明确说明出处并允许它回答“未找到”。截断输出到一半就断。先看 max_tokens 是否太小再看上下文拼接是否超过模型限制。检索噪声top_k 太大导致不相干段落混入回答被带偏。适当降低 top_k或提高相似度阈值。4.4 为什么“有出处”对经典问答是硬需求宗教经典、学术文献、法律条文这类文本有一个共同特点读者对准确性要求极高而且希望每句话都能查证。如果系统只给出“模型认为正确的解释”用户很难判断可信度。比较简单的做法是在提示词里让模型回答时附带来源段落编号或章节信息。这样用户既能快速理解又能回到原文复查。对 Sikhbani.ai 这类面向圣典问答的产品来说“可回溯”本身就是核心体验的一部分。5. 工程落地时最容易翻车的一组细节5.1 多语言输入Gurmukhi、旁遮普语、英语《Sri Guru Granth Sahib》相关文本天然是多语言的。用户可能用英文提问也可能使用旁遮普语的音译或原文。同一个术语可以有多种拼写方式检索阶段如果把这些变体完全交给嵌入模型容易出现漏召回。比较实用的办法是对用户问题做一层预处理统一术语、归一化音译形式。如果应用支持英文和旁遮普语最好在接口层就识别出语言类型再用对应的关键词扩充或词典映射。评测集里也要放一些拼写变体问题确保检索不会被“换个写法”就击败。5.2 日志、缓存和重试RAG 应用上线后最值钱的资产不是模型而是日志。每条请求至少记录用户问题