企业官网建设流程全解析

最近在盘一套传统命理问答资料，“天辛大师最新著作命理学三千问与AI全息智能体”这个标题里的首发项目，我第一时间就拆开看了。第一反应是：终于有人把知识库和智能体真正焊在一起了，而不是又做一个只会顺着话头瞎聊的聊天机器人。天辛是这套资料的署名，我更愿意把它当成一个资料集品牌来看。项目本身很直接——把传统命理领域里常见的问题、术语解释、流派观点整理成三千多个问答条目，再配合大模型做检索增强对话，让智能体回答问题时先查资料、再开口，而不是凭模型记忆自由发挥。

我按同样的思路做了一遍技术复盘，也实际测了一批问答效果。如果你关心三件事：垂直领域知识库怎么做、AI智能体怎么接进传统文化内容、以及“小步快跑”地做一套能落地的问答系统，那这篇内容值得看。先把话说清楚：这是一套知识检索与文本对照工具，不是在线预测工具。它不会替任何人算运势、下吉凶结论，它的价值在于把散落在典籍里的概念、口径和案例整理成可查阅的体系。

1. 三千问不是堆问题：命理知识库的边界与分类策略

1.1 为什么要用“三千问”这种形式做垂直知识库

大多数人做知识库，第一步就栽在“什么都想收”上面。条款、案例、术语、口诀、古籍原文一股脑丢进去，最后检索出来的内容既不够准也不够稳。这套“三千问”的做法给了我一个很关键的启发：用“问题”作为知识库的基本单元。不是存“什么是用神”这种百科式定义，而是存“用神在什么情况下需要变通取用”“已知典籍对用神偏枯的处理口径有哪些”这类带语境的问题，每个问题下挂对应的文本依据和简明回答。

这种结构的天然好处有两个。其一，检索目标非常明确：用户提问和大库里的问题本身可以做强匹配，比拿一段散文去撞向量要稳得多。其二，回答的口径容易收敛：每个问题背后都有明确的文本出处，大模型即使要润色，也必须在一个相对固定的逻辑框架内展开，而不是自由生成一段看起来像那么回事、实际上没有任何依据的内容。

从使用场景看，“问题库不是给人从头读到尾的，是给检索做靶子的”。这句话是我在拆完它之后最大的体会。三千问真正服务的对象不是“想看完三千条的人”，而是“在某一刻带着某个具体疑问来的人”。所以问题的颗粒度、分类粒度，必须从查询习惯出发，而不是从知识体系完整性出发。

1.2 分类框架：按查询习惯拆七个维度

分类是否合理，直接决定后期检索能不能打。我对照这套项目的整理逻辑，结合自己做知识库的经验，梳理出七个可复用的维度。它不是学术分类法，是“面向检索的分类法”。

注意最后两个维度。它们不是传统知识库会主动设的东西，但非常实用。易混清单能大幅降低模型“张冠李戴”的概率，查询提示则是给用户的一条引导路径，让对话型智能体不至于一上来就冷场。七个维度之间不搞成严格树状结构，允许一个问题挂多个维度标签，存的时候多写几条索引，查的时候多几条路。

1.3 内容边界：哪些收进库，哪些坚决不收

做命理内容，最容易踩的坑不是技术，是边界。知识库收录什么，直接决定这产品是“知识工具”还是“算命摊”。我看到的这套设计思路，在边界上有几个原则值得抄作业。

第一，只收录典籍与流派的说理性内容，不收所谓的“亲测案例”。第二，收录解答时一律采用“某典籍认为、某流派主张、按某种规则可推得”的表述，不做绝对判断。第三，涉及具体时间、具体事件的预测性断语，不建条目、不生成内容。做不到这三点，后续无论是合规风险还是用户预期管理，都会非常麻烦。

我说句实在话：知识库能不能做好，不看收了多少，看挡掉了多少。筛掉那些容易引发过度解读的敏感内容后，剩下的反而更干净、更有长期价值。

2. AI全息智能体的技术骨架：从裸模型到“有据可查”的回答

2.1 裸模型的两大痛点：易编造、口径不一

命理类内容本身就很依赖上下文，一个概念在不同流派里可能含义不同。裸模型的问题恰恰在这两点上特别明显。

第一是编造。模型没有真正的记忆库，它对“某典籍怎么说”这类问题的回答，经常是把训练数据里的碎片重新拼起来，语气很笃定，内容却经不起核对。在知识问答场景里，这种问题比“回答不出”严重得多。回答不出还能引导用户换种问法，编造出来的内容却会被不少人当真。

第二是口径漂移。同一个问题，换个问法，模型给出的逻辑依据可能完全不同。上下文长一点，它甚至会在一次对话里同时出现前后矛盾的解释。对娱乐型聊天来说无所谓，但对定位为“知识对照工具”的智能体来说，这是致命的。

所以这套三千问项目选了“先检索、后生成”的路线，也就是最常见的RAG架构。它的本质不是让模型更聪明，而是给模型一副眼镜，让它必须看着资料说话。

2.2 RAG架构：让模型先检索再回答

RAG的结构一句话可以讲完：用户问题进来，先做一个检索步骤，从三千问库里拿到最相关的若干条目，把条目内容拼成上下文，再一起交给大模型，由模型基于这段上下文生成回答。

听起来简单，做起来需要抠的细节很多。整套系统在逻辑上分成四块：用户问题预处理、向量检索、候选重排、答案生成。问题预处理负责把口语化问题转成适合检索的专用问法，比如“用神和忌神啥关系”会被改写为“用神与忌神的概念关系”。向量检索负责从库里捞相关条目；候选重排负责把捞回来的条目按匹配质量重新排序；答案生成由大模型完成，但提示词里明确限定“只能引用参考上下文”。

这一套组合下来，最直观的变化是回答里开始出现库内条目编号，用户可以对“模型说的到底有没有出处”做二次核验。能追溯，才配叫“全息”——不是全知全能，而是全文全量可查。

2.3 知识图谱与向量库：一体还是分离

有一个问题我纠结了很久：要不要额外建知识图谱？实体关系抽取、图数据库、多跳推理……听起来很高大上，但对三千问这类场景，我最终的判断是：先用向量库跑通，图谱以后需要再加。

原因很现实。知识图谱的收益在于关系查询和多跳推导，但它的构建成本是人工标注或复杂的信息抽取管线。对于命理问答这种“概念存在大量同义异名、规则高度依赖上下文”的内容，图谱写浅了没有价值，写深了维护成本太高。向量库则不同，它可以容忍语义模糊，把“相似”当成一种检索信号，这跟人类查询习惯更加贴近。

我建议和我一样做垂直内容智能体的人，用这种策略：一开始不做图谱，把文本条目切好、向量索引建好，把RAG链路跑通。当测试中发现“某类问题老是因为缺一条跨条目关系而答错”时，再针对性地补一个关系索引表，而不是一开始就铺大图。

2.4 检索回答的工程骨架示例

我把自己测试时用的检索与生成流程简化成了伪代码，方便理解这套链路：

def build_context(question, retriever, top_k=5): chunks = retriever.search(question, top_k=top_k) context = "\n---\n".join(chunk.text for chunk in chunks) return context def ask(question, history): rewritten = query_rewrite(question) context = build_context(rewritten, retriever) prompt = system_prompt.format(context=context, question=question) return llm.chat(prompt, history)

实际链路里还要加超时处理、兜底回答、检索失败时的重试策略。核心思路就一句话：任何一步出问题，都别让用户看到系统在裸奔。检索不到相关内容时，宁可让模型回答“库内现有条目未能覆盖”，也别让它硬编一段。

3. 搭建全流程复盘：清洗、切分、检索调参与提示词约束

3.1 文本清洗阶段：统一口径比清理格式更重要

三千问这类资料，原始文档往往是混排的——有些条目是古籍摘录，有些是整理者的白话解释，还有一些是延伸注释。直接拿去切分建索引，检索效果会很差，因为向量空间里混入了太多噪音。

清洗阶段最容易被忽略的是统一口径。什么叫口径？就是同一个意思在不同条目的表达方式要尽量一致。比如“身强”这个词，有些条目写成“身旺”，有些写成“日元有根”，如果不同时保留同义标记，检索时就会漏召回。我做了一版简单的同义术语对照表，把常见的同义表达全部映射到一个主词上，切分前先做一次文本归一化。

清洗顺序我建议是：先去掉与主题无关的片头片尾、编辑注释，再做术语归一化，再补条目编号和来源标记，最后才做分段。来源标记尤其重要，它让后面提示词里的“只能引用参考上下文”有了实际抓手。

3.2 向量化切分：chunk长度与重叠参数的经验值

切分是RAG里最影响手感的一个参数。切得太短，语义不完整；切得太长，向量被无关信息稀释，检索精度下降。我用三千问的文本做了多组对比实验，记录如下：

经验是：不要一个参数走天下。三千问里不同维度的问题适合不同粒度的切分。术语解释适合短块，规则辨析适合中长块，典籍对照需要保留足够上下文才不至于答偏。如果项目初期不想做太复杂的路由，可以先用中等长度起步，跑一段时间再按问题类型调。

3.3 检索参数调优：相似度阈值、Top-K与重排序

检索阶段我重点关注三个参数：相似度阈值、Top-K、是否加重排序。

相似度阈值控制“多不相关才算不相关”。阈值设太低，容易召回一堆似是而非的内容；设太高，则经常检索不到资料，回答变得保守且无趣。我在三千问上试下来，余弦相似度阈值设在0.56到0.62之间比较合适，具体值要看向量模型和文本清洗质量。

Top-K的设计要区分“给模型的量”和“给用户的量”。给模型可以多一点，比如5条；但最终回答里能明确当成依据展示的，最多2到3条，多了就变成了信息轰炸。重排序我强烈建议加。向量模型求的是“语义接近”，但用户真正需要的往往是“口径匹配、覆盖直接答案”的条目，重排序模型能根据用户问题与条目的细粒度相关性重新打分，效果提升非常明显。

3.4 提示词模板：让模型只引资料、不脑补

同样的RAG链路，提示词写得好不好，回答质量可以差一个档次。我在测试中使用的系统提示词大致如下：

你是一个传统文化典籍知识问答助手。你只能基于【参考资料】中的条目回答问题，不能使用资料以外的内容。 【参考资料】 --- {context} --- 用户问题：{question} 要求： 1. 先用口语解释核心概念，再给出资料依据。 2. 引用资料时标注条目编号，例如“据库内第245号条目”。 3. 如果资料无法覆盖问题，直接回答“库内现有条目未能覆盖”，不要自行脑补。 4. 不输出任何涉及具体时间、具体当事人的吉凶结论。

这套提示词有几个巧思：一是明确区分了“口语解释”和“资料依据”，让模型先服务理解、再展示出处；二是给模型留了一条安全出口——回答“库内现有条目未能覆盖”不会被视为失败；三是不输出吉凶结论这条，既是合规红线，也是产品定位。

提示：提示词里的【参考资料】字段不要贪多。给模型塞十几条检索结果，它不仅用不过来，还容易在多个条目之间挑一个最顺眼的自由发挥，反而降低准确性。

4. 上线实测：哪些问答像样，哪些问答当场翻车

4.1 表现好的三类问题：术语解释、流派对照、易混辨析

我把这套智能体跑了一轮，按问题类型统计了回答质量。表现最好的是术语解释类。问“七杀和偏官是不是一回事”，系统能直接命中易混清单条目，给出异同说明和典籍口径。回答结构很清楚：先下结论，再给依据，最后补充一个容易混淆的分支。

流派对照类也做得不错。只要知识库条目本身标注了来源流派，模型就能按“某流派主张A，另一流派主张B”的方式组织答案，而不会强行统一成一种说法。这种“允许不同口径共存”的能力，恰恰是垂直知识库区别于常见搜索引擎回答的地方。

易混辨析类表现同样稳定。库里的易混清单相当于事前做了大量人工标注，模型只需要把既有对照复述出来，再根据用户追问微调解释角度。这说明一个道理：知识库里多投入一分整理功夫，模型回答就少一分随性发挥。

4.2 翻车案例：组合问题、断语类问题、指代不清

当然也踩了不少坑，而且踩得很有价值。

翻车最严重的是组合型问题。比如“身强身弱对取用神的影响具体是怎么体现的”，这类问题需要跨多个条目做二次推理，模型有时会把A条目的前提条件套到B条目上面，导致逻辑链出现跳步。翻车现场通常是：“看起来说了很多，但中间一步是模型自己补的。”

断语类问题同样危险。只要是问“某年会不会发生某事”这种诉求，系统要么检索不到对应条目，要么只能给出“库内现有条目未能覆盖”。这种保守回答会导致一部分用户觉得“不够聪明”，但我的判断是：宁可保守，不能硬编。

指代不清的问题也比较考验交互设计。用户问“它和它之间的冲是什么意思”，系统很难知道“它”指代什么。解决方案是加一轮澄清追问：请用户明确主体。多轮对话的设计里，追问不是打断，而是避免后续一连串错误的关键闸门。

4.3 我的补救策略：多路召回、追问式过滤与兜底口径

针对翻车案例，我跑了几套补救策略，逐一提炼如下。

多路召回是指同时走向量检索和关键词匹配，最后合并结果。组合型问题靠向量召回容易漏，但关键词可以把涉及“身强”“身弱”“用神”的条目全部拉出来，再交给重排模型做聚合。合并后的召回量变大，但目标更完整。

追问式过滤主要应对指代不清。当系统识别到用户问题存在多种可能解读时，先不回答案，而是给出候选解读让用户确认。虽然多了一次交互，但后续回答的准确率明显上升。

兜底口径是最后一道防线。系统无论遇到多难的问题，都必须给出一种明确回应。要么是“问题太宽泛，建议缩小范围”，要么是“库内现有条目未能覆盖”。不让模型用“可能”“也许”这类暧昧词去掩盖没把握的推断。下面是我整理的满意度测试表：

65%满意度的断语类查询，在我的产品定位里反而是“正确行为”。知识工具不应该去答它不该答的问题，满意度扣分换来的，是回答边界的安全线。

4.4 一次典型的日志复盘

随手贴一段我测试时的日志记录，能看出整个链路在处理组合问题时的表现。

用户问：“格局不正的人，用神取用会有什么不同？”系统先把问题改写为“格局不正与用神取用的关系”，召回了两组条目：一组是格局分类，一组是用神取用规则。第一轮回答时，模型把“格局不正”等同于“从格”，这个判断库内条目没有支持，于是回答里出现了一个未经证实的断言。

定位到这个错误后，我在知识库里补了一条关系索引“格局不正≠从格，需结合具体十神配置”。同时给提示词加了一句：“涉及类别判断时，请先确认库内是否存在明确条目，若没有，请引导用户补充形成条件。”之后同类问题的准确率提高了一截。这个过程也证明了垂直智能体的迭代重点：错在哪，就想办法让库或提示词在哪个点位上堵住它。

5. 复盘后的三点经验，以及下一步最想做的事

5.1 经验一：垂直智能体最贵的不是模型，是数据整理

跑完这套三千问项目，我最大的感受是模型本身已经完全不稀奇，真正决定一个智能体好不好用的，是背后的知识库整理水平。同样一个开源模型，接一个随便爬来的资料库，和一个经过清洗、分类、同义映射、条目标注的知识库，回答质量天差地别。

语言模型像一位表达能力极强的发言人，但发言人肚子里有没有货，全靠你事先准备的资料包。后续想提升这套系统，把所有心思花在“把三千问变成三万问”的同时，更要花在“让每个问题都更精确”上面。数据的整理，永远是垂直智能体的地基。

5.2 经验二：“全息”的前提是引文可追溯

“AI全息智能体”这个名字听起来很玄，但实际落地时，最容易获得用户信任的设计，不是无所不知，而是每条回答都能追到库内条目。可追溯就是“全息”的真正含义。用户点开一个来源编号，能看到原始条目、编辑说明和整理时间，信任感会大幅提升。

做这类产品一定要重建“引用文化”。模型回答时给出依据，比回答本身更宝贵。如果用户以后能方便地反馈“这条依据不对”，知识库就能在真实使用中被持续修正，而不是锁在一个固定的静态版本里。

5.3 经验三：交互设计要主动告知能力边界

关于边界，我踩过的坑是：不在开场把能力边界讲清，用户一定会拿它当预测工具来问。后来我在欢迎语里直接写清楚“本助手提供命理典籍知识问答，不提供个人预测与吉凶判断”，并把典型案例做成推荐问题按钮，用户慢慢就学会在边界内提问了。

核心是要给用户一个“在边界内也能获得价值”的路径。光告诉用户“这个不做”是不够的，还要让用户知道“那这个能做，而且做得不错”。提供规范问题模板和引导提示，就是在帮用户把模糊的好奇心，转化成库内能够回答的具体问题。

5.4 下一步：开放征集、本地化部署、做成可安装工具

目前这套“三千问+智能体”的首发版本，我已经跑通核心链路，接下来有三个方向想推进：面向内容爱好者开放新问题征集，把大家关心的增量问题纳入知识库；把整个系统做成可本地化部署的轻量工具，支持个人电脑直接运行；对知识库增加版本对比和条目溯源能力，让每次内容迭代都可回溯。

我个人在实操中最大的体会是，垂直知识库智能体不是一次投入就能一劳永逸的东西，它是一个需要持续喂养和修正的有机体。模型的角色像一个聪明的接线员，知识库才是真正的话务中心。把线路设计清楚、把话术边界定明白，剩下的就是在一次次提问与反馈中，让这套东西越来越结实。