RAG 是 Retrieval-Augmented Generation 的缩写，是一种结合了检索和生成技术的问答系统架构
背景
公司的 1024 节日开展了一个自建 RAG 应用的比赛，虽然在比赛之前，我已经接触并参与了一些相关项目，但相比于比赛的形式，这种有标准化输入输出还能评判优劣的场景，对自己的实际能力考察确实会更加全面
赛事经历
赛事介绍：
- 模仿客服的角色定位，结合众多产品的私有知识库，回答赛方评委提供的一些问题，问题类型包含（文本、图片和视频）
- 应用结果通过公网可访问 API 来输出，问题即 request，答案即 response
- 团队作业，4-5 人一组（不同方向：前端、大数据、IT 等等）
期间自己还参与了其他的一些 toy 项目，比如： AI 女友聊天机器人
这里先聊聊团队作业，从离开大学之后，再次和不同频道、不同专业的人协作比赛，人和人的沟通成本确实比自己闷头做要高很多，但好处是大家都有自己的分工，自己只需要做好自己的事情，然后和队友同步进度，最后再合并到一起，这样确实可以完成一个相对完整的东西
技术思考
比赛的整体方案思路比较朴实无华：
- 对图片做 OCR 提取文本信息，对视频做字幕提取文本信息，对所有文本信息做结构化处理
- 对知识库做清洗、切片、整理，内嵌到 LLM 中
- 对问题做前置工作：意图识别、意图发散、问题转义和记忆上下文变量
- LLM 处理问题，对得到的结果进行过滤、精炼、总结
- 格式化最终返回结果
期间尝试了字节的 COZE，其应用完善程度超乎我的想象，就是有些节点（记忆上下文、知识库查询）效果还差点
期间也做了两套方案：
- COZE 的工作流编排方案
- 使用 LangChain 的直接 prompt 调用方案
最后因为知识库查询的准确度问题，还是使用了方案 2
后续
团队老大最后在赛事总结的时候，提到一个概念：我们要当设计者，而不是执行者
结合我自身也将近两年的工作经历来看，这确实是一个方向上的转变，从执行者到设计者的转变
- 管理层的绩效目标，是定向锚定目标去拿结果，至于过程中谁做的、谁付出最多，那是团队内部的事情
- 社会性群体，天然就会形成类似 1-3-5-1 的比例群体，十个人的团队，锚定📌自己的定位，很重要
承上启下
技术之外的事情到此结束，回到技术本身
行业内对这个业务场景的标准作业流是怎样的，我找到了这样一张图
问答系统架构分析
上图展示了一个复杂的问答系统的工作流程，分为 查询翻译、路由、查询构建、索引、检索 和 生成 六大模块。以下是按流程顺序的详细分析和补充说明：
1. 查询翻译（Query Translation）
- 查询分解（Query Decomposition）:
将复杂问题分解为子问题或分步问题，例如：- 多轮查询（Multi-query）
- 回溯查询（Step-back）
- 检索-生成融合（RAG-Fusion）
- 伪文档生成（Pseudo-documents）:
使用 HyDE 技术生成假设性文档，以帮助回答潜在的复杂问题。
补充分析：
通过问题分解与伪文档生成，可以提升系统处理复杂问题的能力，适用于需要多轮推理或具备丰富背景知识的对话场景。
2. 路由（Routing）
- 逻辑路由（Logical Routing）:
基于查询逻辑选择适合的数据库类型（关系型数据库、图数据库或向量数据库）。 - 语义路由（Semantic Routing）:
将查询转换为语义向量，通过语义匹配选择最合适的提示或数据库。
路由模块提升了系统的效率和准确性。逻辑路由解决了数据库选择的问题，而语义路由进一步优化了查询意图与匹配效果。
3. 查询构建（Query Construction）
- 关系型数据库（Relational DBs）:
- 通过 Text-to-SQL 技术将自然语言转换为 SQL 查询。
- 支持关系型数据库操作，并可结合 PGVector 进行嵌入查询。
- 图数据库（Graph DBs）:
使用 Text-to-Cypher 技术将自然语言转换为 Cypher 查询语言，以访问图数据库。 - 向量数据库（Vector DBs）:
采用自查询检索器（Self-query Retriever），自动生成元数据过滤条件，支持向量数据库。
该模块支持多模态查询（SQL、Cypher、向量化），适用于结构化和非结构化数据存储，实现多源信息的融合。
4. 索引（Indexing）
- 分块优化（Chunk Optimization）:
使用语义分割器（Semantic Splitter）按字符、段落或语义片段拆分文档，提高嵌入效率。 - 多表示索引（Multi-representation Indexing）:
将文档转化为紧凑的表示单元（如摘要），以便快速检索。 - 专用嵌入（Specialized Embeddings）:
通过微调技术（如 ColBERT）优化嵌入表示的任务特化能力。 - 分层索引（Hierarchical Indexing）:
采用 RAPTOR 技术实现文档的分层抽象与组织。
索引模块通过分块、分层和优化技术，提升系统性能，特别适合大规模语料库的高效检索需求。
5. 检索（Retrieval）
- 排序与精炼（Ranking & Refinement）:
使用 Re-Rank、RankGPT 或 RAG-Fusion，对检索到的文档进行相关性排序、过滤和压缩。 - 主动检索（Active Retrieval）:
如果初始检索结果不理想，可采用 CRAG 技术从其他数据源重新检索。
检索模块支持动态调整，确保系统对实时数据和复杂查询的适应性，是开放域问答系统的核心能力。
6. 生成（Generation）
- 主动生成检索（Active Retrieval for Generation）:
根据生成质量，动态调整问题的重写或重新检索。 - Self-RAG 与 RRR:
将生成模型（如 GPT）与检索模块（如 RAG）结合，优化答案质量。
生成模块结合检索结果与生成能力，提供高质量且解释性强的答案，适用于需要推理或生成复杂内容的场景。
总结
图中的技术（如 RAG-Fusion、ColBERT、HyDE）处于前沿水平，是多源异构数据融合与生成增强的典型架构
可以看出，RAG 技术在问答系统中已经非常成熟，在实际应用中，RAG 可与其他技术结合使用，以达到更好的效果
AI 当下发展
我目前日常使用的 AI 应用：
- Cursor IDE
- 豆包（拍照识图、百度百科
体验过程中明显能感觉到：
- 国内应用在服务体验上，更能体现一个产品的优势
- 国外应用则是在专业角度上，内容更加全面和权威
再来看这位行业投资人的看法：
其中不乏有些"暴论"，但整体的一个思考逻辑，还是挺能反映问题的
- AI 应用会先落实在 b 端，然后反哺 c 端
- 国内因为体制的原因，真正的 AI 助手落地十分困难
至于我们的态度? —— 当下的风口还没停下来，需要关注亦或者等待一个机会的来临