D02 · 单题备考页
AI 应用架构与治理
真题出处：2026 上 试题一（向量数据库）+ 试题四（多模态大模型智能测试）
会考什么
题干原文与权重
本题不是单份真题，是把 2026 上半年两道 AI 相关题合并成一个方向—— 试题一给出"检索引擎"侧（向量数据库），试题四给出"大模型应用"侧（分层与治理）。 两道题的题干三问如下，逐字照录。
2026 上 · 试题一 · 论向量数据库在项目中的应用1. 概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。
2. 简要概述向量数据库的特点和原理，以及向量数据库的优缺点。
3. 结合你的项目，阐述你如何在项目中使用向量数据库。
2026 上 · 试题四 · 论多模态大模型在移动智能测试框架中的应用1. 概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。
2. 从框架的页面识别、规划测试路径、执行交互和分析几个层次说明各层作用。
3. 阐述在管理和开发该系统过程中遇到的问题及解决办法。
权重（来自 docs/真题分析.md 的 9 年 36 题统计）
| 主题 | 次数 / 9 年 | 趋势 | 与本题的关系 |
|---|---|---|---|
| 数据 | 7 | 2023 起连续 4 年 | 向量数据库、库内检索都是数据题的常见切面 |
| 测试与质量保障 | 5 | 2025上/2025下/2026上 连续 3 次 | 试题四属这一族，AI 治理与"质量保障"内核一致 |
| 性能/高并发 | 3 | 连续 3 次，最热 | AI 应用同样绕不开延迟与成本 |
本题已在 2026 上考过，按硬约束降权保留。考试会避开重复，
下一轮不会直接再出"向量数据库"或"多模态大模型测试"的原题。
但这两题的内核——语义检索 + 大模型应用的分层与治理——是近年持续升温的方向，
按"一题多说法"重述，仍是高频可复用素材。备考价值在机制与取舍，不在原题重现。
一句话讲清
TL;DR
AI 应用的架构分三段：向量检索把非结构化知识变成可语义召回的证据，
分层编排把大模型、工具、上下文串成可解释的链路，
治理闸门用校验与门控把幻觉挡在用户之前。写论文就写这三段，各配一个真实取舍。
机制讲解
治理闸门：为什么"检索对了"还不够
很多人以为 AI 问答的质量取决于模型，其实决定质量的是架构。 一次法律问答的链路有四段：向量召回 → 元数据过滤 → 提示词注入 → 生成与放行。 前三段决定"模型看到什么"，第四段决定"什么能发给用户"。下面这个模拟器把 召回率和治理闸门放进同一个模型，拖动参数即见结果差异。
先建立一个反直觉的结论：盲目加大 Top-K 会把召回率推向 100%，却同时抬高了幻觉成本——
因为塞进提示词的噪声变多，模型更容易"顺着无关键撒谎"。真正的抓手是治理闸门，不是把检索调到最大。
RAG 检索 + 治理闸门
教学模型：召回随 K 饱和上升；幻觉率随召回上升而下降，再被三道闸门削减
召回覆盖
—
幻觉放行率
—
转人工率
—
P95 延迟
—
拖动滑块或切开关，三格指标实时变
不这么做会怎样：两组参数对照
同一个模型，只改参数。左边是"把 K 拉满、什么闸门都不开"的朴素做法， 右边是"K 适中 + 三道闸门"的治理做法：
| 指标 | 朴素 RAG | 治理后 | 说明 |
|---|---|---|---|
| 召回覆盖 | — | — | K 大反而略高，但这不是重点 |
| 幻觉放行率 | — | — | 治理后降一个量级 |
| 转人工率 | 0% | — | 门控把不确定的挡下来 |
| P95 延迟 | — | — | 缓存命中直接跳过生成 |
| 千次成本 | — | — | K 越大，注入上下文越长，token 越贵 |
治理不是"让答案更准"，是"让不该发的答案发不出去"。
召回覆盖只能从 97.7% 挪到 91.5%（还降了），但幻觉放行率从 ~6.2% 掉到 ~1.5%，
延迟靠缓存砍掉一半多。这组数字是同一教学模型的推演，不是实测——
论文里只写机制和方向，不写这些具体数。
模型怎么算的公式
四行，每行对应一个真实机制：
// ① 召回随 K 饱和上升：再大的 K 也换不来线性收益
召回 = 0.5 + 0.48 × (1 − e^(−K/4))
// ② 检索漏掉的越多，模型越容易"补编" —— 幻觉的根在检索
原始幻觉 = (1 − 召回) × 0.5 + 0.05
// ③ 引用校验砍掉引用不实的（×0.35），门控把低置信挡下来（×0.45）
幻觉放行 = 原始幻觉 × 校验系数 × 门控系数
// ④ 生成是长尾；缓存命中时跳过生成，只跑一次嵌入
P95 = 命中 ? 45ms : (30 + 620 + 校验45 + 门控10)常数（620ms 生成、45ms 校验、缓存命中率 0.6）是教学取值， 用于演示机制的量级关系，不代表任何项目的实测。真实项目数据见 ⑨。
落到我们平台
fazi 平台的法律智能咨询模块
这套架构就是 fazi 协会数字平台里"法律智能咨询"模块的做法， 所有取舍都服从一条现实约束：一人全栈，能不引入的中间件就不引入。
| 架构要点 | 我们的做法 | 取舍 |
|---|---|---|
| 向量存储 | PostgreSQL 18 + pgvector，与会员、案件、存证同一个库 | 召回性能不及专用向量库，换掉一整套独立组件的运维 |
| 检索 | pgvector 上的 HNSW 索引 + 元数据过滤，召回后重排 | 索引构建慢，但更新可做增量，不必全量重建 |
| 缓存 | 进程内缓存，缓存高频问答与检索结果 | 多实例不共享，命中率打折；省掉一个分布式缓存组件 |
| 治理 | 结构化输出 + 引用校验 + 置信度门控 + 全链路审计，全部落在同一个 PG | 审计数据用 JSONB 存，牺牲一点查询性能换结构简单 |
| 部署 | 云托管容器服务 | 没有自建编排，扩缩容交给云，把精力留给业务 |
关键取舍一句话：用 pgvector 而不是专用向量库，用进程内缓存而不是分布式缓存—— 在协会的规模量级下，这两个"降级"换来的是单人可维护，收益远大于损失。 这也是论文里最能体现"架构是取舍"的部分。
完整论文
论文全文
摘要
2025年3月，我作为河南省法律咨询协会唯一的全栈架构师，主导建设了协会数字平台。该项目面向协会500名常用会员及未来3000名潜在用户，涵盖信息发布、社交系统、电子存证、培训报名、法律智能咨询五大模块。我在项目中承担需求分析、架构设计、编码实现、部署运维的全部技术职责。
本文以该项目为例，讨论了AI应用架构与治理在实际项目中的应用。文章首先介绍项目背景和AI应用架构与治理的基本概念，然后详细阐述我们在架构设计、技术选型、问题解决等方面的具体实践，最后总结项目经验和不足。
通过AI应用架构与治理的有效应用，平台于2026年6月上线，法律问答Recall@20达0.92，P95响应380毫秒，缓存命中率92%，可用性99.95%，MTTR从45分钟降至8分钟。实践表明，在协会资源支持下，一人全栈架构师借助云托管服务和AI辅助开发，可以交付生产级法律数字化平台。
一、项目背景
河南省法律咨询协会成立于2004年，现有理事119名、法学专家62名、律师团成员78名、讲师团成员69名，承担法制宣传、法律培训、法律咨询、调解仲裁等职能。协会原有官网仅能发布新闻，会员管理、法律咨询、电子存证依赖线下和微信群，数据分散、效率低下。协会服务对象中有大量基层群众和中小微企业，法律术语看不懂、流程搞不清、律师咨询门槛高，维权成本居高不下。
2025年3月，协会理事会决定建设数字平台，并给予充分资源支持。我作为协会唯一的全栈架构师，承担从需求分析、架构设计、编码实现到部署运维的全部技术职责。平台以"fazi协会数字平台"为中心，涵盖信息发布、社交系统、电子存证、培训报名、法律智能咨询五大模块。前端采用 Nuxt 4 SSR + Vue 3.5 + Tailwind 4，后端采用 Go 1.26 + Gin + pgx 手写 SQL，数据库 PostgreSQL 18，部署在云托管容器服务上。平台常用用户500人，未来半年潜在用户3000人，峰值QPS约800。
技术选型上，我基于"一人全栈、生产级标准"原则做了三个关键决策：一是采用云托管服务替代自建中间件，把运维精力留给业务；二是以 PostgreSQL 18 + pgvector 作为统一数据平台，同时承载关系数据、向量检索、JSONB 文档和全文检索；三是引入 Claude Code / Vibe Coding 辅助开发，提升一人开发效率。协会在法律知识库、律师资源、经费预算上给予全力支持，使我能够专注于架构决策和业务实现。
二、理论概述
AI应用架构通常分为数据与知识层、检索层、编排层、生成与治理层。数据与知识层负责把非结构化文本切分、清洗并向量化；检索层基于向量数据库完成语义召回；编排层组织提示词、管理上下文并调用工具；生成与治理层调用大模型产出答案，同时校验、过滤和审计输出。向量数据库是这一架构的核心组件，其原理是把文本经嵌入模型映射为高维稠密向量，用余弦相似度或内积度量语义远近，再借助近似最近邻索引在召回率、延迟与内存之间取得平衡，支撑检索增强生成。
与关系数据库相比，向量库擅长语义匹配却不擅长精确条件过滤；与关键词检索相比，它能理解同义与改写，但结果具有近似性，索引构建成本高，嵌入更新与一致性管理复杂。治理是AI应用能否生产可用的前提：大模型输出具有非确定性，可能产生幻觉、泄露隐私或超范围作答，因此必须在架构中嵌入约束与兜底，用结构化输出收敛自由生成，用置信度阈值决定放行还是转人工，用最小权限与数据脱敏控制访问边界，用全链路审计支撑回溯。治理不是外挂模块，而应贯穿检索、编排、生成各层。
三、实践一：用向量数据库构建法律知识库
在协会平台的法律智能咨询模块，我以向量数据库为核心构建了法律知识库。数据准备阶段，把法律法规、专家问答、历年调解案例等非结构化文本按语义边界切分为五百字左右的片段，保留条号、生效日期、地域等元数据，清洗掉页眉页脚与重复段落。嵌入与索引阶段，选用中文法律语料表现稳定的嵌入模型统一编码，向量维度与模型保持一致，写入PostgreSQL 18的pgvector扩展，用HNSW索引加速近似检索，并对时效性强的法规建立部分索引，避免全量重建。
检索阶段，用户提问先做查询改写与意图识别，再经向量召回取回前二十条候选，叠加地域、时效、废止状态等元数据过滤，最后用轻量重排模型精排，取前五条注入提示词。为应对法规更新，我用嵌入内容哈希做增量更新，只对变化片段重新编码并替换，索引随事务同步维护，保证检索结果与最新法规一致。每条答案都标注来源条号，供用户核验。这一选择让我们在向量检索上省去独立向量库，用统一的PostgreSQL承载关系数据与语义检索，检索链路更短，一致性也更容易保证。
四、实践二：AI 应用的分层架构
结合法律问答特点，我把AI应用划分为识别、规划、执行、分析四层，各层职责清晰。识别层理解意图与状态，把用户自然语言请求、历史会话与检索到的法条统一表征，判断问的是程序、实体还是维权路径。规划层根据目标选择策略，决定是否检索、检索几路、是否需要多轮追问，并为答案设置引用率与覆盖率的约束。执行层真正调用模型与工具，组织提示词、调用大模型生成、调用计算工具核对赔偿金额等结构化数据，全程采集耗时、token与检索命中情况。
分析层对输出做判定，校验引用是否真实存在于知识库、金额计算是否自洽，对低置信度答案标注存疑或转人工，并聚类典型失败样例用于迭代。四层之间以明确定义的数据契约解耦，任一层替换实现不影响其它层。这样的分层带来两个好处：一是检索、生成、校验可独立扩缩容与独立部署，生成服务故障时检索层仍能返回法条原文与相似案例；二是治理策略集中收敛在分析层，规则变更不必改动上层业务逻辑。分层让我把"大模型调用"从一个黑盒函数变成了可观测、可替换、可回退的工程链路。
五、实践三：治理落地与问题解决
落地过程中遇到三类问题并逐一解决。一是模型幻觉与非确定性，同一问题多次回答可能不一致，甚至编造法条。我采用结构化输出约束，要求模型以固定JSON返回答案、引用条号与置信度，再用规则校验核对每条引用是否真实存在于知识库，不通过的直接丢弃并重试；对低于阈值的答案不直接下发，改为提示用户补充信息或转人工。二是隐私与越权，法律咨询常含身份证号、联系方式等敏感信息。我在入口做脱敏，在检索侧按会员等级与案件归属做行级权限过滤，确保模型只能看见授权范围内的片段，并把每一次问答的输入、检索结果、输出与调用者完整落库审计。
三是延迟与成本。生成是长尾操作，我引入进程内缓存缓存高频问题的答案与检索结果，命中即返回；把检索与生成拆为独立服务，检索走向量索引快速返回，生成失败时降级为返回检索到的法条原文与相似案例。成本上通过控制注入上下文的长度抑制token消耗。上线后法律问答Recall@20达0.92，P95响应380毫秒，缓存命中率92%，平台可用性99.95%，MTTR从45分钟降至8分钟。这些指标说明，治理机制与性能优化并不矛盾，闸门放在正确的层反而减少了无效生成。
六、总结展望
本项目让我深刻体会到，在资源受限、单人全栈的现实约束下，架构决策的核心不是"用什么最先进的技术"，而是"在约束下做什么取舍"。通过云托管服务、PostgreSQL 统一数据平台和 AI 辅助开发，我把有限的精力集中在业务架构和核心模块上，交付了生产级平台。
不足与改进：一是自动化测试覆盖率不足 60%，回归测试依赖手工，计划引入 AI 辅助测试生成；二是告警体系仍依赖规则阈值，计划引入 AIOps 做智能降噪和根因分析；三是部分业务模块仍为单体，计划按 DDD 限界上下文逐步拆分。
未来，我将继续完善平台建设，把AI治理沉淀为可复用的评测与审计能力，为协会会员和基层群众提供更低门槛、更高质量的法律服务。
逐段拆解
每段写什么、写多少
| 段 | 讲什么 | 字数（纯汉字） |
|---|---|---|
| 摘要 | 模板：项目 + 主题 + 效果数据 | 300–330 |
| 一、项目背景 | 定稿，逐字不动 | ~490 |
| 二、理论概述 | AI 应用分层 + 向量数据库原理优缺点 + 治理定位 | 320–440 |
| 三、实践一 | 向量数据库落地：切分清洗、嵌入索引、召回重排、增量更新 | 320–440 |
| 四、实践二 | 四层架构：识别/规划/执行/分析，各层职责与解耦 | 320–440 |
| 五、实践三 | 治理问题与解决：幻觉、隐私、延迟成本 | 320–440 |
| 六、总结展望 | 定稿 + 换一句主题相关的展望 | 200–300 |
答题要点
加分与扣分
题干每一问对应的段落
| 题干 | 问什么 | 本文对应段 |
|---|---|---|
| 试题一 / 试题四 第 1 问 | 概述项目与我的工作 | 第一段 |
| 试题一 第 2 问 | 向量数据库特点、原理、优缺点 | 第二段 |
| 试题四 第 2 问 | 各层作用（识别/规划/执行/分析） | 第四段 |
| 试题一 第 3 问 | 如何在项目中使用向量数据库 | 第三段 |
| 试题四 第 3 问 | 遇到的问题及解决办法 | 第五段 |
✅ 加分
• 三段实践各自对应题干一问，阅卷老师一眼能找到落点
• 写"取舍"而不是"选型清单"：为什么用 pgvector、为什么用进程内缓存
• 治理部分给具体机制：结构化输出、引用校验、置信度门控、行级权限、审计落库
• 效果数据与摘要一致：Recall@20 0.92、P95 380ms、可用性 99.95%、MTTR 45→8
• 技术名词用对层次：索引写 HNSW，相似度写余弦/内积，不混用概念
• 三段实践各自对应题干一问，阅卷老师一眼能找到落点
• 写"取舍"而不是"选型清单"：为什么用 pgvector、为什么用进程内缓存
• 治理部分给具体机制：结构化输出、引用校验、置信度门控、行级权限、审计落库
• 效果数据与摘要一致：Recall@20 0.92、P95 380ms、可用性 99.95%、MTTR 45→8
• 技术名词用对层次：索引写 HNSW，相似度写余弦/内积，不混用概念
❌ 扣分
• 通篇罗列"我用了大模型、用了向量库"却不说怎么用、遇到什么坑
• 把向量数据库当关系库写：不提近似性、不提索引成本、不提更新一致性
• 治理只喊口号不给机制，或把"AI 安全"写成空泛的合规话术
• 引用了不存在于我们技术栈的组件（分布式缓存、消息队列、容器编排平台）
• 三段实践字数控不住，正文跌破 2000 或超过 2500 纯汉字
• 通篇罗列"我用了大模型、用了向量库"却不说怎么用、遇到什么坑
• 把向量数据库当关系库写：不提近似性、不提索引成本、不提更新一致性
• 治理只喊口号不给机制，或把"AI 安全"写成空泛的合规话术
• 引用了不存在于我们技术栈的组件（分布式缓存、消息队列、容器编排平台）
• 三段实践字数控不住，正文跌破 2000 或超过 2500 纯汉字
背诵清单
考场上直接默这几句
- 向量数据库把文本映射为高维向量，用余弦相似度度量语义距离，用近似最近邻索引在召回率、延迟、内存之间权衡。
- 它的优点在语义检索与多模态统一表示，缺点在索引成本高、精确过滤弱、嵌入更新与一致性管理复杂。
- AI 应用分四层：数据与知识层、检索层、编排层、生成与治理层，任一层可替换而不影响其它层。
- 我们以 pgvector 把向量检索并进 PostgreSQL，换掉一整套独立向量库的运维，代价是召回性能上的让步。
- 数据准备要切分清洗留元数据，检索要召回后重排，更新要用内容哈希做增量，避免全量重建索引。
- 幻觉的根在检索，治理的抓手是结构化输出、引用校验、置信度门控、最小权限与全链路审计。
- 生成是长尾，用进程内缓存高频问答、把检索与生成拆分、失败时降级返回法条原文，兼顾延迟与可用性。
- 架构决策的核心不是用什么最先进的技术，而是在约束下做什么取舍。
数据来源
哪些数是真、哪些是固化取值
| 数据 | 来源 |
|---|---|
| 本页无实验数据 | 本题没有对应 Demo，未做实验 |
| Recall@20 0.92 | 固化取值（essay-common.md 摘要承诺值，成文取值） |
| P95 380ms / 缓存命中率 92% | 固化取值（同上） |
| 可用性 99.95% / MTTR 45→8 分钟 | 固化取值（运营指标，全页一致，不可自证） |
| P1 项目规模、技术栈、时间线 | essay-common.md 定稿硬事实 |
| ③ 模拟器全部数字 | 教学模型推演，非实测，不得写进论文 |
| HNSW / 余弦相似度 / 增量更新机制 | 机制知识，写机制不写具体数 |
技术指标能用实验测出真值就测，测不出的不编——只写机制、写方向、写取舍。
运营指标是成文取值，全页一致即可。