本文是专栏 《AI 赋能图书馆与知识服务》 第 4 篇，属于“架构与系统篇”。
前一篇我们讲了三层架构：数据层 / 能力层 / 应用层。
这一篇聚焦一个很多馆都在问的现实问题：
“我们已经有 OPAC/统一检索了，怎么在不推翻系统的前提下，引入 AI 能力？”
一、先承认一个现实：OPAC “没那么差”，只是“没跟上”
很多技术讨论喜欢把传统 OPAC 说得一无是处：
“不能理解自然语言问题”“搜索体验太原始”“一点都不智能”
但站在图书馆业务的角度，要更公平地看：
它在做的事，一直都很稳定
按题名、作者、主题、分类号检索；支持布尔逻辑与字段限定；和借还、预约、读者状态深度绑定。
它承载了大量既有工作流
馆员培训、读者使用习惯、后台管理流程，都是围绕现有 OPAC 形成的。
真正的问题不是“OPAC 一无是处”，
而是：它停在了关键词时代，没有跟上语义检索与多语种时代。
所以本文的目标不是“推翻 OPAC”，而是：
在不动现有核心业务逻辑的前提下，
给它外挂一层“更聪明的脑子”和“更友好的界面”。
二、我们到底想从“传统检索”升级到什么样的“智能检索”？
先把目标画像画清楚，否则很容易变成“堆功能”。
目标 A：读者可以用自然语言提问，而不是死磕关键词
例如：
原来要这样查：
主题 = “跨文化交际” AND 语种 = “法语” AND 文献类型 = “教材”
升级之后，读者可以直接输入：
“帮我找一些适合法语跨文化交际课程用的教材和参考书”
系统能做到：
解析出 主题、语种、类型、用途 等要素；在 OPAC / 统一检索上组合出更合理的检索式；或用 RAG + 向量检索，从相关记录中挑出更贴近需求的条目。
目标 B：检索结果更“懂人”，而不仅仅是“排个相关度”
可以按 主题、学科、时间线、文献类型 做简单聚类与分组；在列表旁边加出 “相关主题/相关课程/常用组合资源”；对小白用户提供“预设检索视图”（如：入门阅读、课程推荐等）。
目标 C：逐步支持多语种与跨语言检索
至少包括：
中文问题 → 找到英文/外文资源；
一种语言的主题词 → 自动扩展为多语种同义概念集；
在结果界面提示：
“你查的是这个主题，相关的外文/小语种资源在这里”。
一句话总结目标：
不要求一夜之间变成“像某大厂搜索那样牛”，
而是给读者一个更自然的提问方式、
更友好的结果结构、
和一条通往多语种的升级路径。
三、核心思路：用“旁路增强”而不是“开膛手术”
如果用一句术语来概括，就是：
在 OPAC 外面，再加一个“智能检索前台 + 能力中间层”，
而不是直接动 OPAC 的核心代码。
可以用一个简化的架构图来表示：
这张图背后有几条重要原则：
不直接改 OPAC 的核心逻辑
仍由 OPAC 负责：借还、预约、权限控制、基础检索。
所有“智能”的东西放在中间层与前台
中间层负责：
解析用户意图、决定调用 OPAC 还是向量检索、或两者都调、做结果融合。
OPAC 通过接口/脚本被“调用”，而不是“被重写”
用 HTTP 接口、SQL 视图、批量导出等方式接入。
四、步骤一：先在“前台”上做一个“小升级”
1.1 建一个“智能入口”，而不是替换全部检索界面
可以非常务实地做：
在原有 OPAC/统一检索页面上，
增加一个按钮/Tab：“智能检索（Beta）” 或 “自然语言检索”；
第一期只把有限的功能放在这个入口：
自然语言提问简单的检索式生成与推荐一两个特定场景（如“帮我找课程参考书”）。
这样有几个好处：
不打乱原有用户习惯；遇到问题时，用户随时可以退回“传统检索”；便于 A/B 测试和渐进式优化。
1.2 用“大白话引导 + 模板句”降低使用门槛
很多“自然语言检索”失败，不是因为技术不行，而是：
用户不知道该怎么问，或者对“AI 能做什么”期待过高。
可以在界面上加入：
提示语：
✅ “你可以这样提问：‘帮我找…’、‘我想了解…’、‘有没有适合作为…的资料’”❌ “避免只输入单个词，如‘英语’‘法律’，建议描述你的具体需求。”
预设提示按钮，例如：
“帮我为某门课程挑选基础阅读书单”“准备写论文，帮我扩大某个主题的文献范围”“找某个国家/地区相关的小语种资源”
这些按钮背后，都可以映射到相对规范的检索策略，
再由中间层翻译成 OPAC 可接受的检索式。
1.3 第一阶段可以“不用大模型”，先做“规则+引导”
如果条件有限，完全可以先不用大模型，做两件事：
把自然语言问题“模板化拆分”
用正则/简单 NLP：识别出
学科/主题词文献类型（教材/论文/报告/工具书）语种（中文/英文/小语种）时间范围（近 5 年、近 10 年等）
把拆分后的要素，映射到 OPAC 检索字段
例如：
主题 → 主题词字段 / 关键词字段文献类型 → 文献类型字段语种 → 语种字段时间 → 出版年字段
这已经可以让很多不会写复杂检索式的用户，
通过“说人话”获得接近专业检索效果的结果。
之后大模型可以逐步补上：
在拆分、扩展主题、改写问题等方面，做得更柔和一些。
五、步骤二：在“中间层”中接入语义检索与 RAG
当前台的“自然语言入口”初步跑起来后，
下一步就是在中间层加入语义检索能力。
2.1 把书目/摘要/部分全文嵌入向量库
可以从很小的范围做起：
先选一个学科或一个专题库（如“小语种特色资源库”）；
对以下内容做向量化并存入向量数据库：
题名 + 摘要主题词 + 分类号说明部分关键章节/简介
保留与 OPAC 记录的关联键（如记录号、馆藏号）。
2.2 决定“什么时候走 OPAC，什么时候走向量检索”
中间层需要一个简单的“策略选择器”，逻辑可以大致如下：
如果用户问题 结构化很强（包含明确的书名、作者、ISBN 等）
→ 优先走 OPAC 字段检索。
如果用户问题是 开放式、描述性问题（如“帮我找…相关的入门读物”）
→ 同时调用：
OPAC 的主题/关键词检索向量检索（在向量库中召回语义相似的记录）
对两个结果集做 融合与去重，再返回给前端。
简单伪代码示意（概念性的）：
if is_structured_query(user_query):
result = opac_search(parse_to_structured_query(user_query))
else:
result_opac = opac_search(generate_query(user_query))
result_vec = vector_search(user_query)
result = merge_and_rank(result_opac, result_vec)
return result
2.3 逐步引入 RAG：从“找记录”到“回答问题”
当向量检索跑稳后，可以尝试引入 RAG，用于：
回答“图书馆业务相关”的常见问题：
“如何在某数据库中查找某类文献？”“某专业的核心期刊有哪些？”
回答与某个专题知识库相关的问题：
利用该专题库的内容片段和说明文档。
简单架构可以是：
中间层识别问题属于“FAQ/指南型”问题；调用向量库，在“FAQ+指南文档+培训讲义”等语料中召回文本片段；把片段交给大模型，让它生成自然语言回答，
并附上“相关资源链接”。
注意：对学术内容的 RAG，需要更严格的审核与标识，
本文先侧重“图书馆服务说明类内容”的 RAG。
六、步骤三：循序渐进地接入多语种与跨语言能力
在 OPAC 之上引入多语种/跨语言能力，不必一口吃成胖子，可以这样分层：
3.1 第一层：界面与检索式的“多语种友好”
在检索界面上，让用户可以 选择界面语言（至少中英）；内部对常见字段名、提示语、错误信息等做多语种支持；对同一 OPAC 检索式，提供多语言的“人类可读表达”。
3.2 第二层：对常见主题和学科，建立多语种“同义词表”
为重点学科、课程、研究方向，
建立一个 小型、多语种的主题词对照表；在用户用某种语言检索时，自动扩展为其他语言的相关词。
例如：
用户输入中文：“跨文化交际”
系统在后台扩展为：
英文：“intercultural communication”法语：“communication interculturelle”相关同义词/近义词
这些扩展可以：
用于传统 OPAC 的多字段、多语种检索；也可以用于向量检索的查询增强。
3.3 第三层：跨语言向量检索与多语种 RAG
在向量库阶段，如果选用 多语种嵌入模型（如支持多语言的句向量），
可以做到：
用一种语言提问，跨多语种文本资源做语义检索；在结果中标记资源的语种，并提供（谨慎的）机器翻译提示。
之后，如果条件允许，可以：
为多语种关键文献生成 双语/多语种摘要；在 RAG 回答中，
明确给出：原文语种、摘录来源、译文与原文的关系。
这部分会在《跨语言检索与多语种 RAG 实战手册》专栏中展开，
在本专栏里，我们重点讲“图书馆从哪里开始动手”。
七、风险与边界：哪些事“不要着急做”，或者“必须谨慎做”
1. 不要让“实验性功能”直接替代关键业务入口
智能检索入口可以有，但最好保留传统检索入口；
对外宣传时，要合理管理用户预期：
清楚标注“内测/Beta”“结果仅供参考”等。
2. 不要在没有审查机制的前提下，
直接让大模型回答“学术内容问题”
对于“某理论是谁提出的”“某概念的定义是什么”等问题，
如果大模型的回答来源没有被严格控制，容易产生严重幻觉；
在没有稳定的学术 RAG 体系前，建议：
大模型更多用于 解释检索策略、整理指南，而不是直接“代替专业检索与阅读”。
3. 严格区分：日志分析 与 个体画像
在使用检索日志等行为数据时：
优先进行汇总与匿名化分析；不要做过细的个人画像分析，尤其是与敏感主题相关的部分；
在界面与政策上，
要让用户知道：图书馆如何保护他们的使用数据隐私。
八、一个可执行的小路线图（给项目负责人用）
最后，用一个“最小可行计划”收个尾。
假设你是图书馆技术/项目负责人，可以这样规划 6–12 个月：
阶段 1：前台与规则引导（1–2 个月）
在 OPAC 或统一检索页上新增“智能检索（Beta）”入口；做简单的自然语言 → 检索参数解析（先用规则/模板实现）；做若干示例问题与模板按钮；做内部试用与小规模用户测试。
阶段 2：中间层初步搭建（2–4 个月）
抽象出一个“中间层服务”：
接受自然语言问题；决定调用 OPAC 哪些字段检索；对结果做简单重排与聚类；
同步准备：
日志记录与分析框架（了解用户使用情况）。
阶段 3：向量检索试点（3–6 个月，可并行）
选一个学科/专题库做向量化；
搭建简易向量库与检索 API；
在中间层中增加“混合检索”策略；
在前台界面上增加：
“相关主题推荐”“你可能还要看的资源”。
阶段 4：多语种/跨语言增强（6 个月后，小步推进）
从高需求学科入手，建立多语种主题词表；在检索前端提供多语种界面和提示；逐步尝试跨语言向量检索与多语种摘要。
九、结语：不求“一步到位”，但求“每一步都可复用”
从传统 OPAC 到智能检索，
不是一次性换系统，而是：
在现有系统周围，慢慢长出一层“更聪明的外壳”和“更稳定的中台”。
每往前走一步，你都在积累：
更清晰的数据资产图谱；更可复用的检索与分析能力；更成熟的前台交互经验。
下一篇，我们会转向一个与你这篇紧密相关的话题：
《图书馆版 RAG 系统：从馆藏到知识问答的一条完整链路》
在那里，我们会把今天出现多次的“向量检索 + RAG”
专门拉出来，用“图书馆场景”一条线讲清楚。
上一篇：
《图书馆智能服务三层架构：数据层 / 能力层 / 应用层》
© 版权声明
文章版权归作者所有，未经允许请勿转载。
相关文章
暂无评论...
