尧图网站建设 
简介面向第十六届蓝桥杯项目实战赛智能体开发赛道的备赛资料系基于对话型智能体的“智能阅读助手”赛题详解适合具备一定编程基础、对AI智能体与自然语言处理感兴趣的研发人员。PDF完整收录了省赛比赛须知、HiAgent平台登录方式、交卷及APPID提交时限并提炼了从目标到落地的技术实现要点包括提高回答准确率的高频问题缓存、多级索引与分阶段处理多轮记忆的Session机制、意图槽位填充与历史摘要归档以及固定格式输出、低置信度拒答、信息审查七类问题和多语言/OCR封面识别等复杂内容处理方案。资源为1个PDF文件压缩包约553KB轻量便携便于赛前快速通读规则并直接对照设计智能体架构。已有445人学习浏览适合需要在有限备赛时间内快速理解赛题要求、梳理实现路径并规避常见误区的参赛选手。1. 蓝桥杯智能体开发省赛一场关于「对话型智能体」的极限四小时第十六届蓝桥杯项目实战赛的智能体开发省赛题目是做一个基于对话型智能体的智能阅读助手。比赛规则先划了一条硬线只允许用对话型智能体创建流程编排型智能体会被直接取消评奖资格。这意味着你不能靠拖节点搭 DAG 来绕开问题所有能力都得在对话框架内用 Prompt、工具调用和记忆机制实现。赛题给出的场景是书店「悦读阁」需要一个能查书、答内容、给推荐、hold 住多轮追问的助手底层数据是一份 books.csv 和一张同结构的 book 表。比赛当天登录蓝桥杯 HiAgent 平台开发完成后发布并提交 APPID四小时内要同时搞定准确性、响应速度、上下文记忆和严格输出格式四个维度的要求。这篇笔记适合两类人一类是准备参赛、想提前摸清评分点和坑的选手另一类是正在做企业级问答 Agent、被格式错乱和上下文断裂折磨的研发人员。我按自己的拆解顺序来写——规则怎么理解、数据怎么接、准确率怎么抠、记忆怎么存、格式怎么守、最后怎么验。2. 比赛规则与数据准备先读懂评分点再动手搭 Agent2.1 赛题规则里的四个硬指标省赛题面表面上是在讲书店需求实际上评分点全部收敛在四个可量化指标上。第一是回答准确率书籍基本信息必须精准提取书名、作者、出版社、ISBN、出版日期一个都不能错内容摘要必须从数据集准确概括作者背景信息不能过度搜索外部资料。第二是响应时间从用户提交问题到返回答案时间越短越好题面直接给了三个实现策略高频问题缓存、多级索引结构、分阶段并行处理意图与字段提取。第三是历史问答作为后续提问依据一次会话里多个问题往往有上下文关联Agent 要具备记忆能力题面提示了 Session 记忆机制、意图槽位填充、历史问答摘要归档三条路。第四是禁止胡乱作答选择就只给序号填空别答成段落低置信度要拒答而不是硬编。这里有个容易被忽略的细节回答要求里写明「问题统一视为选择题答案必须为大写字母序列」单选输出一个大写字母多选按字母顺序连续输出超出知识范围统一输出「未查询到以上知识/ 以上答案都不对」。这条规则直接决定了你的 Prompt 怎么写、后处理校验怎么加。多数队伍翻车都翻在这里——模型输出了一大段解释文字格式分直接清零。2.2 登录、解压试题与定位数据文件比赛流程是固定的4 月 26 日 9:00 到 13:00先登录蓝桥杯 HiAgent 平台租户名称、子用户准考证号、登录密码Lanqiao选手身份证后 6 位和验证码四要素缺一不可。登录后进「个人空间」数据已经预置好了知识库里有一个名为「智能阅读助手知识库」的知识库内含 books.csv数据库里有一个「智能阅读助手数据库」内含 book 表两者字段一致。比赛试题压缩包在比赛系统页面下载解压密码在公告栏比赛开始后才能拿到。数据准备阶段我建议做三件事先把 books.csv 下载下来看字段结构确认到底有哪些列——书名、作者、译者、出版社、ISBN、出版时间、页数、定价、内容摘要、分类这些大概率都有然后连接数据库测试连通性题面给了 DSNmysql://lanqiao:JRemizRCwKZqPAGvDmiV28Qmysql38ab0bc01cc2.rds.ivolces.com/lqb_ss_books注意表名是 book字段与个人空间数据库里的 book 表一致最后对比 csv 和数据库表的数据量是否相同避免只接了其中一个导致答案缺失。这里有个我自己踩过的坑很多选手拿到 csv 就直接让 Agent 去检索知识库压根不测数据库连接。但赛题明确说了「数据库」表也是数据源而且选择题选项里出现过「原知识库未提及」「原手册中未提及」这类选项说明判分时会有意识测试你的数据覆盖边界。我建议把数据库连接写成 Agent 的一个工具知识库检索不到时自动回落到 SQL 查询。2.3 用 Python 快速探查 books.csv 的字段与数据质量拿到数据第一步是探查结构不要急着写 Prompt。下面这段代码可以快速看清 books.csv 的全貌import pandas as pd df pd.read_csv(books.csv, encodingutf-8) print(总行数:, len(df)) print(字段列表:, list(df.columns)) print(\n每列非空值统计:) print(df.notna().sum()) print(\n前5行样本:) print(df.head().to_string())逻辑说明read_csv 读取时注意编码utf-8 读出乱码就换 gbknotna().sum() 统计每列非空值直接暴露数据不完整的问题——比如某本书缺出版时间、某本书缺 ISBN这些就是评审规则里说的「数据不完整」类缺陷head() 打印前五行是为了直观看到字段内容的格式比如定价是数字还是字符串、出版时间是「2015-01-01」还是「2015.1」。参数说明encoding 字段视文件实际编码调整中文字符集的 csv 经常是 gbk 或 gb18030如果 books.csv 有特别大的字段比如长摘要用 df.info() 看内存占用和 dtype。探查完你就能判断哪些字段适合做精确匹配、哪些字段适合做全文检索这一步直接决定后续索引怎么建。3. 回答准确率优化多级索引、字段提取与版本差异识别3.1 为什么直接全文检索拿不到高分拿知识库直接做向量检索是最快的思路但准确率很难达标。原因有两个。第一书籍基本信息类问题ISBN、出版社、出版日期要求的是精确匹配向量检索给的是语义相似ISBN 错一位就等于全错。第二赛题里有一类「对比题」比如「《百年孤独》新版与旧版相比以下哪个差异是正确的」这种题需要同一个书名下的多版本记录做横向对比向量检索只能召回碎片化文本拼不出「新版多了作者序言、换了译者、页数增加 15%、定价提高 20 元」这种结构化差异。所以我的做法是分层字段级精确匹配优先全文检索兜底必要时走 SQL 做聚合对比。题面说的「多级索引结构建立文档字段级别的索引加快数据检索」就是这个意思——对书名、ISBN、作者、出版社分别建索引而不是把整本书的描述文本揉成一个向量。3.2 字段级索引与缓存响应速度与准确率一起优化高频问题缓存很好理解用户问「《小王子》的作者是谁」和「小王子谁写的」是同一道题第一次从数据源算出答案后缓存下来第二次直接命中。缓存 key 要设计好我用的是「意图 书名实体 字段名」三元组。下面是一个最小实现import hashlib import json import time from functools import lru_cache class AnswerCache: def __init__(self, maxsize256, ttl300): self.cache {} self.maxsize maxsize self.ttl ttl # 秒5分钟内相同问题直接返回 def _build_key(self, intent, entity, field): raw f{intent}|{entity}|{field} return hashlib.md5(raw.encode(utf-8)).hexdigest() def get(self, intent, entity, field): key self._build_key(intent, entity, field) item self.cache.get(key) if item and time.time() - item[ts] self.ttl: return item[answer] return None def set(self, intent, entity, field, answer): key self._build_key(intent, entity, field) self.cache[key] {answer: answer, ts: time.time()} cache AnswerCache(maxsize512, ttl600)逻辑说明_build_key 把意图、实体、字段名拼接后做 MD5避免中文太长影响 dict 性能get 方法检查过期时间TTL 设为 600 秒一场比赛 4 小时用户对同一本书的追问往往集中在某段时间内过期后重新检索一次成本也不高set 方法直接覆盖旧值。注意 maxsize 设 512 就够了比赛题量有限缓存太大反而浪费内存。参数说明ttl 不要设太大否则版本对比题会出问题——同书名不同版本的书用户第一次问旧版、第二次问新版缓存 key 里没带版本信息就会答非所问。所以我给版本对比类问题单独关缓存强制走数据源。3.3 SQL 兜底查询DSN 连接与多版本对比知识库检索命不中、或者遇到版本对比题时我直接用 SQL 查数据库。题面给的 DSN 是 MySQL 连接串用 pymysql 写一个查询工具注册给 Agent 即可import pymysql def query_book(book_title, fieldNone): conn pymysql.connect( hostmysql38ab0bc01cc2.rds.ivolces.com, userlanqiao, passwordJRemizRCwKZqPAGvDmiV28Q, databaselqb_ss_books, charsetutf8mb4, connect_timeout10 ) try: with conn.cursor() as cur: if field: sql fSELECT {field} FROM book WHERE 书名 LIKE %s LIMIT 1 cur.execute(sql, (f%{book_title}%,)) else: sql SELECT * FROM book WHERE 书名 LIKE %s cur.execute(sql, (f%{book_title}%,)) return cur.fetchall() finally: conn.close()逻辑说明连接参数全部来自题面 DSN注意 charset 必须用 utf8mb4否则中文可能乱码connect_timeout 设 10 秒防止数据库连不上时 Agent 长时间卡死。LIKE 查询在数据量几百行时够用不需要上全文索引field 参数传列名时只查所需的那个字段减少数据传输响应时间更快。参数说明书名匹配用 LIKE %关键词% 能解决「《小王子》」和「小王子」的差异但要注意「百年孤独」和「《百年孤独》新版本」这种带修饰词的书名最好在传入 SQL 前用正则把括号和修饰词剥离。多版本对比的 SQL 要用 GROUP BY 书名查出所有版本然后根据题面问的差异点在 Python 里做字段比对不要试图一条 SQL 查出「差异」。3.4 版本差异识别的实现思路版本混淆是评审明确点名的缺陷类型「回答中将 2015 版定价与 2020 版的页数混合引用」就是这类失误。要避免它必须在数据查询阶段就把版本区分开。我的做法是在 Prompt 里强约束回答任何书籍信息问题前先判定这本书有几个版本如果有多个版本必须显式说明引用的是哪个版本并且同一问题的所有字段来自同一个版本记录。技术上可以做一层版本聚合用 pandas 按书名分组组内按出版时间排序为每个版本生成一个包含完整字段的快照字符串。这样模型在回答时拿到的是「版本快照」而不是散乱的字段混用的概率大幅降低。快照生成代码import pandas as pd df pd.read_csv(books.csv, encodingutf-8) df[版本快照] df.apply( lambda row: f版本ID:{row[出版时间]} 书名:{row[书名]} 作者:{row[作者]} 译者:{row.get(译者,)} 出版社:{row[出版社]} ISBN:{row[ISBN]} 页数:{row.get(页数,)} 定价:{row.get(定价,)} 摘要:{row.get(内容摘要,)}, axis1 ) snapshot_by_book df.groupby(书名)[版本快照].apply(list).to_dict()逻辑说明groupby 按书名分组后同一本书的不同版本会聚合成一个列表每个快照字符串里完整包含了该版本的所有字段模型只需要在快照内取值就不会跨版本混用。注意译者、页数、定价这些字段可能不存在用 get 加默认空字符串防止 KeyError。参数说明出版时间字段如果格式不统一比如「2015-01-01」和「2015/1/1」混用要先统一成字符串格式再拼进快照否则排序会出错。版本快照的优点是模型看到的是「一个版本一条完整记录」比提供 JSON 数组更不容易产生幻觉。4. 多轮记忆机制Session 状态管理、意图槽位填充与摘要归档4.1 为什么「每轮重新解析」必挂赛题在记忆部分直接写明了一个典型误区每轮提问都重新解析导致上下文断裂。实际测试中你会发现用户第一轮问「《小王子》的作者是谁」第二轮接着问「那这本书的出版社呢」第三轮问「它和《狐狸的故事》是同一个作者吗」——如果第二轮还把「这本书」当成一个新实体去全局检索大概率匹配到错误的书。多轮对话的核心是把「指代消解」和「会话状态维护」做对。最常见的方案是维护一个 session 状态对象里面记录当前讨论的主要实体、实体的版本、上一轮意图。用户每一轮的新问题先做意图识别如果是追问类意图「它」「这本书」「那本」就用状态里的实体填充槽位而不是重新解析。4.2 Session 记忆与槽位填充的最小实现对话型智能体平台上一般有内置的会话变量能力但如果你是在自己代码里调试下面这个结构足够比赛用class SessionState: def __init__(self, session_id): self.session_id session_id self.current_book None self.current_version None self.history [] self.slots {} # intent槽位填充 self.summary None def update(self, intentNone, bookNone, versionNone): if book: self.current_book book if version: self.current_version version if intent: self.slots[intent] intent self.history.append({ intent: intent, book: book, version: version, ts: time.time() }) def resolve_entity(self, raw_question): # 指代消解如果问题中出现这本它那本等代词使用当前context pronouns [这本, 这个, 它, 该书, 那本, 上述] for p in pronouns: if p in raw_question: return self.current_book, self.current_version return None, None逻辑说明update 方法在每一轮对话后用新的实体/意图覆盖旧状态resolve_entity 是关键的指代消解逻辑检测到代词时直接用当前书和当前版本兜底。注意版本信息也要存不然用户说「这本书的新版页数是多少」时你不知道他指的是哪个版本。参数说明代词列表要覆盖常见指代但也要小心误判——「那本《红楼梦》」既包含代词也包含新书名这时要优先识别书名实体而不是直接用 context。判断顺序应该是先做命名实体识别识别出书名就用新实体识别不出才走指代消解。4.3 长对话摘要归档与「过度记忆」的边界赛题要求「历史问答摘要归档」同时提醒「不恰当的过度记忆误用历史内容答非所问」。这两条要平衡。我的处理策略是每轮对话在状态里追加一条摘要记录摘要只保留三个要素——用户问了什么书、关注哪些字段、上一轮结论是什么。超过 6 轮对话后用大模型把历史条目压缩成一段三句话以内的会话摘要用于后续引用。过度记忆的典型翻车现场是用户第一轮问「《百年孤独》的作者是谁」你记住了「百年孤独」第二轮问「《百年孤独》的亚马逊评分是多少」这是合理关联但如果用户第三轮问「《霍乱时期的爱情》呢」你还在用「百年孤独」的上下文去解析代词的指代就会答错。所以每次识别到新书名实体时必须强制替换 current_book而不是追加到记忆里混合使用。关于摘要归档我建议在 Prompt 里增加一条系统提示「当用户的问题中包含前序对话中提到的信息时优先使用会话摘要和槽位内容但每个事实必须能从数据源或历史对话中溯源无法溯源的内容不得输出。」这就把记忆和拒答机制绑在了一起——记忆只是指路牌不是事实来源。4.4 多轮对话评测追问理解率怎么测评测记忆效果不能只看单轮准确率要模拟真实追问链路。我的做法是构造一组三轮对话测试集test_conversations [ [ {role: user, content: 《小王子》的作者是谁}, {role: user, content: 这本书的出版社是哪家}, {role: user, content: 它的出版时间呢} ], [ {role: user, content: J.K.罗琳写了哪些作品}, {role: user, content: 《哈利·波特与魔法石》是哪一年出版的}, {role: user, content: 这本和《密室》比哪本更早} ] ] def evaluate_memory(agent, conversations): correct 0 total 0 for conv in conversations: agent.reset_session() for turn in conv: answer agent.respond(turn[content]) # 此处接入标准答案比对逻辑比对时忽略格式差异 total 1 if is_correct(answer, turn.get(expected)): correct 1 return correct / total逻辑说明每个会话里连续三个问题共享同一个主题上下文第二、第三问必须依赖第一轮的语义才能真正答对——「这本书」指代《小王子》「这本」指代《哈利·波特与魔法石》。reset_session 在每组合法会话前清空状态避免串场。评测指标就是「多轮会话中正确理解上下文比例」。参数说明注意第三问「这本和《密室》比」既包含指代「这本」也包含新实体「《密室》」这是一个典型的混合问题——解法是提取出所有书名实体指代词单独用上下文兜底两个实体同时进入槽位。如果 Agent 对这类混合问题答错说明实体识别和指代消解的优先级没调对。5. 避坑与排查格式错乱、拒答误判和数据源断连5.1 选择题输出了选项内容而不是序号现象模型对「《小王子》的作者是谁 A. 马克·吐温 B. 安托万·德·圣埃克苏佩里 C. 查尔斯·狄更斯 D. 原知识库未提及」直接回答「作者是安托万·德·圣埃克苏佩里」而不是输出「B」。原因默认对话模型有强烈的「完整回答」惯性看到问句就喜欢组织自然语言答案而不是执行格式指令。题面明确要求只输出选择序号。解决Prompt 里加一条硬约束「当问题呈现为选择题格式包含 A/B/C/D 选项时你只允许输出一个或若干个字母禁止输出任何其他字符」并在后处理里加正则校验——如果输出内容不是纯字母序列强制截取或置为拒答短语。我在比赛里直接写了一个后处理函数answer 只保留大写字母如果长度超过 5 个且包含「A」「B」之外的字符就判断为格式错误。5.2 多选题输出顺序不符合要求现象多选题标准答案是「ABD」模型输出「DAB」或「A、B、D」。原因模型在排序上没有确定性尤其是多个选项置信度接近时输出顺序随机。解决后处理里做一步排序——把答案字符串拆成单字符列表按字母表排序后再拼接。注意题面明确说「多选输出时按照字母顺序输出」所以这道题不存在其他合法顺序直接 sort 即可。如果是「AB,AC,BC,ABC」这种多组合输出要按组合的字典序排列分号或逗号分隔格式也要统一。5.3 查询原文时句尾多了标点符号现象题面要求「回答内容应当完全引用原文且句尾不需要保留标点符号」模型输出「书是一本描写孤独的经典著作。」句尾带了句号。原因模型在生成自然语言时习惯性补标点完全不理解「句尾不需要保留标点符号」这个约束的语义。解决检测到「查询原文」关键词时走单独的 Prompt 分支强调「逐字复制原文片段禁止任何增改禁止添加句尾标点」同时在代码后处理里对答案做 strip 和标点剥离。注意标点剥离只能删句尾的一个符号不能删掉原文中句中的标点否则内容就失真了。5.4 数据源断连导致 Agent 卡死或超时现象用户提交问题后Agent 长时间无响应最后返回超时报错。原因数据库连接池没配超时时间MySQL 连接失败时 pymysql 默认会阻塞较长时间或者 CSV 解析失败后 Agent 直接报错没有降级方案。解决所有外部数据源调用都套 try-except 和超时参数。connect_timeout 设 10 秒读操作超时设 5 秒CSV 读取失败时自动切换到数据库查询数据库查询失败时自动切换回 CSV。双数据源互为冗余题面本来就给了 csv 和 MySQL 两个来源不要只依赖一个。5.5 情感化和扩展回答导致知识边界失控现象用户问「这本书好看吗」或「你觉得《小王子》传递了什么价值观」模型开始长篇大论谈感想。原因题面要求「高度主观或需要外部新近资讯的问题若数据集中无明确记录触发统一拒答」。模型的共情能力强非常容易被诱导输出数据集之外的观点。解决系统提示里强调「你是信息检索助手不是书评人回答仅依据数据集的字段内容不包含任何个人观点、评价或推测当问题涉及价值判断或外部知识时输出统一拒答语」。同时加一层意图分类主观评价类意图直接走拒答分支不触发检索。这也回应了赛题里「乱用参考资料、生成伪知识」的误区警示。6. 发布、验证与 APPID 提交四小时内的可用性闭环开发完不等于比赛结束你还需要完成发布、验证和提交 APPID 三个动作。开考 1 小时后可以提前交卷但交卷后无法再进入答题环境也不能继续操作 HiAgent 平台。所以时间分配上我建议前 2.5 小时专注开发和测试第 3 小时做完整验证和修复最后 30 分钟发布并提交 APPID。先做发布前验证。验证清单至少包含四类题单选精确匹配答案字母、多选输出顺序排序、对比题多版本差异、查询原文句尾无标点。每题都要实际跑一遍不要只在 Prompt 层面推理。# 验证脚本框架跑通全部题型再发布 test_cases [ {type: 单选, question: 《小王子》的作者是谁\nA. 马克·吐温\nB. 安托万·德·圣埃克苏佩里\nC. 查尔斯·狄更斯\nD. 原知识库未提及, expected: B}, {type: 多选, question: 以下哪些作品是J.K.罗琳创作的\nA. 《哈利·波特与魔法石》\nB. 《哈利·波特与密室》\nC. 《杀死一只知更鸟》\nD. 《哈利·波特与死亡圣器》\nE. 原手册中未提及, expected: ABD}, {type: 对比, question: 数据集中的《百年孤独》新版与旧版相比以下哪个差异是正确的\nA. 新版增加了作者序言\nB. 新版采用了不同的译者\nC. 新版页数增加了15%以上\nD. 新版零售价格提高了20元, expected: A}, {type: 原文, question: 查询原文《百年孤独》的内容摘要第一句是什么, expected: 无句尾标点的原文片段} ] for t in test_cases: result agent.respond(t[question]) print(f{t[type]}: 模型输出{result}, 期望{t[expected]}, 通过{result.strip() t[expected]})逻辑说明验证脚本的用意是防回归——你改了一版 Prompt 后不能只测刚改的那道题要把全部题型重跑一遍。选择题比对用 strip 后的精确匹配原文题比对要把句尾标点去掉后比对。注意多选题的 expected 必须是「ABD」这种排序后的格式。参数说明测试顺序有讲究——先测格式最严格的题单选/多选再测需要数据比对能力的题对比/原文最后测拒答类。格式题不过就不要再测内容题因为输出格式是硬门槛。发布操作在 HiAgent 平台完成核心是拿到 APPID 并提交到比赛系统的问答题答题框。特别注意提交的必须是你最终发布的那个版本的 APPID改过 Prompt 后重新发布会生成新的 APPID不要提交旧的。比赛结束时系统自动交卷未提交 APPID 或上传错误 APPID 均不予评奖。最后说一个我的习惯每次发布新版前我都会花两分钟跑一遍上面四类题的验证脚本确认五种边界行为都正常——选择题只出字母、多选题已排序、对比题答案在数据范围内、过滤外部信息、正确引用前文。从那以后我每次搭比赛 Agent 都强制走一遍「边界五查」宁可多花两分钟验证也不要交卷后才发现某个简单题因为格式问题丢分。希望帮到你。本文还有配套的精品资源点击获取 蓝桥杯智能体省赛实战：对话型智能阅读助手开发全攻略
简介面向第十六届蓝桥杯项目实战赛智能体开发赛道的备赛资料系基于对话型智能体的“智能阅读助手”赛题详解适合具备一定编程基础、对AI智能体与自然语言处理感兴趣的研发人员。PDF完整收录了省赛比赛须知、HiAgent平台登录方式、交卷及APPID提交时限并提炼了从目标到落地的技术实现要点包括提高回答准确率的高频问题缓存、多级索引与分阶段处理多轮记忆的Session机制、意图槽位填充与历史摘要归档以及固定格式输出、低置信度拒答、信息审查七类问题和多语言/OCR封面识别等复杂内容处理方案。资源为1个PDF文件压缩包约553KB轻量便携便于赛前快速通读规则并直接对照设计智能体架构。已有445人学习浏览适合需要在有限备赛时间内快速理解赛题要求、梳理实现路径并规避常见误区的参赛选手。1. 蓝桥杯智能体开发省赛一场关于「对话型智能体」的极限四小时第十六届蓝桥杯项目实战赛的智能体开发省赛题目是做一个基于对话型智能体的智能阅读助手。比赛规则先划了一条硬线只允许用对话型智能体创建流程编排型智能体会被直接取消评奖资格。这意味着你不能靠拖节点搭 DAG 来绕开问题所有能力都得在对话框架内用 Prompt、工具调用和记忆机制实现。赛题给出的场景是书店「悦读阁」需要一个能查书、答内容、给推荐、hold 住多轮追问的助手底层数据是一份 books.csv 和一张同结构的 book 表。比赛当天登录蓝桥杯 HiAgent 平台开发完成后发布并提交 APPID四小时内要同时搞定准确性、响应速度、上下文记忆和严格输出格式四个维度的要求。这篇笔记适合两类人一类是准备参赛、想提前摸清评分点和坑的选手另一类是正在做企业级问答 Agent、被格式错乱和上下文断裂折磨的研发人员。我按自己的拆解顺序来写——规则怎么理解、数据怎么接、准确率怎么抠、记忆怎么存、格式怎么守、最后怎么验。2. 比赛规则与数据准备先读懂评分点再动手搭 Agent2.1 赛题规则里的四个硬指标省赛题面表面上是在讲书店需求实际上评分点全部收敛在四个可量化指标上。第一是回答准确率书籍基本信息必须精准提取书名、作者、出版社、ISBN、出版日期一个都不能错内容摘要必须从数据集准确概括作者背景信息不能过度搜索外部资料。第二是响应时间从用户提交问题到返回答案时间越短越好题面直接给了三个实现策略高频问题缓存、多级索引结构、分阶段并行处理意图与字段提取。第三是历史问答作为后续提问依据一次会话里多个问题往往有上下文关联Agent 要具备记忆能力题面提示了 Session 记忆机制、意图槽位填充、历史问答摘要归档三条路。第四是禁止胡乱作答选择就只给序号填空别答成段落低置信度要拒答而不是硬编。这里有个容易被忽略的细节回答要求里写明「问题统一视为选择题答案必须为大写字母序列」单选输出一个大写字母多选按字母顺序连续输出超出知识范围统一输出「未查询到以上知识/ 以上答案都不对」。这条规则直接决定了你的 Prompt 怎么写、后处理校验怎么加。多数队伍翻车都翻在这里——模型输出了一大段解释文字格式分直接清零。2.2 登录、解压试题与定位数据文件比赛流程是固定的4 月 26 日 9:00 到 13:00先登录蓝桥杯 HiAgent 平台租户名称、子用户准考证号、登录密码Lanqiao选手身份证后 6 位和验证码四要素缺一不可。登录后进「个人空间」数据已经预置好了知识库里有一个名为「智能阅读助手知识库」的知识库内含 books.csv数据库里有一个「智能阅读助手数据库」内含 book 表两者字段一致。比赛试题压缩包在比赛系统页面下载解压密码在公告栏比赛开始后才能拿到。数据准备阶段我建议做三件事先把 books.csv 下载下来看字段结构确认到底有哪些列——书名、作者、译者、出版社、ISBN、出版时间、页数、定价、内容摘要、分类这些大概率都有然后连接数据库测试连通性题面给了 DSNmysql://lanqiao:JRemizRCwKZqPAGvDmiV28Qmysql38ab0bc01cc2.rds.ivolces.com/lqb_ss_books注意表名是 book字段与个人空间数据库里的 book 表一致最后对比 csv 和数据库表的数据量是否相同避免只接了其中一个导致答案缺失。这里有个我自己踩过的坑很多选手拿到 csv 就直接让 Agent 去检索知识库压根不测数据库连接。但赛题明确说了「数据库」表也是数据源而且选择题选项里出现过「原知识库未提及」「原手册中未提及」这类选项说明判分时会有意识测试你的数据覆盖边界。我建议把数据库连接写成 Agent 的一个工具知识库检索不到时自动回落到 SQL 查询。2.3 用 Python 快速探查 books.csv 的字段与数据质量拿到数据第一步是探查结构不要急着写 Prompt。下面这段代码可以快速看清 books.csv 的全貌import pandas as pd df pd.read_csv(books.csv, encodingutf-8) print(总行数:, len(df)) print(字段列表:, list(df.columns)) print(\n每列非空值统计:) print(df.notna().sum()) print(\n前5行样本:) print(df.head().to_string())逻辑说明read_csv 读取时注意编码utf-8 读出乱码就换 gbknotna().sum() 统计每列非空值直接暴露数据不完整的问题——比如某本书缺出版时间、某本书缺 ISBN这些就是评审规则里说的「数据不完整」类缺陷head() 打印前五行是为了直观看到字段内容的格式比如定价是数字还是字符串、出版时间是「2015-01-01」还是「2015.1」。参数说明encoding 字段视文件实际编码调整中文字符集的 csv 经常是 gbk 或 gb18030如果 books.csv 有特别大的字段比如长摘要用 df.info() 看内存占用和 dtype。探查完你就能判断哪些字段适合做精确匹配、哪些字段适合做全文检索这一步直接决定后续索引怎么建。3. 回答准确率优化多级索引、字段提取与版本差异识别3.1 为什么直接全文检索拿不到高分拿知识库直接做向量检索是最快的思路但准确率很难达标。原因有两个。第一书籍基本信息类问题ISBN、出版社、出版日期要求的是精确匹配向量检索给的是语义相似ISBN 错一位就等于全错。第二赛题里有一类「对比题」比如「《百年孤独》新版与旧版相比以下哪个差异是正确的」这种题需要同一个书名下的多版本记录做横向对比向量检索只能召回碎片化文本拼不出「新版多了作者序言、换了译者、页数增加 15%、定价提高 20 元」这种结构化差异。所以我的做法是分层字段级精确匹配优先全文检索兜底必要时走 SQL 做聚合对比。题面说的「多级索引结构建立文档字段级别的索引加快数据检索」就是这个意思——对书名、ISBN、作者、出版社分别建索引而不是把整本书的描述文本揉成一个向量。3.2 字段级索引与缓存响应速度与准确率一起优化高频问题缓存很好理解用户问「《小王子》的作者是谁」和「小王子谁写的」是同一道题第一次从数据源算出答案后缓存下来第二次直接命中。缓存 key 要设计好我用的是「意图 书名实体 字段名」三元组。下面是一个最小实现import hashlib import json import time from functools import lru_cache class AnswerCache: def __init__(self, maxsize256, ttl300): self.cache {} self.maxsize maxsize self.ttl ttl # 秒5分钟内相同问题直接返回 def _build_key(self, intent, entity, field): raw f{intent}|{entity}|{field} return hashlib.md5(raw.encode(utf-8)).hexdigest() def get(self, intent, entity, field): key self._build_key(intent, entity, field) item self.cache.get(key) if item and time.time() - item[ts] self.ttl: return item[answer] return None def set(self, intent, entity, field, answer): key self._build_key(intent, entity, field) self.cache[key] {answer: answer, ts: time.time()} cache AnswerCache(maxsize512, ttl600)逻辑说明_build_key 把意图、实体、字段名拼接后做 MD5避免中文太长影响 dict 性能get 方法检查过期时间TTL 设为 600 秒一场比赛 4 小时用户对同一本书的追问往往集中在某段时间内过期后重新检索一次成本也不高set 方法直接覆盖旧值。注意 maxsize 设 512 就够了比赛题量有限缓存太大反而浪费内存。参数说明ttl 不要设太大否则版本对比题会出问题——同书名不同版本的书用户第一次问旧版、第二次问新版缓存 key 里没带版本信息就会答非所问。所以我给版本对比类问题单独关缓存强制走数据源。3.3 SQL 兜底查询DSN 连接与多版本对比知识库检索命不中、或者遇到版本对比题时我直接用 SQL 查数据库。题面给的 DSN 是 MySQL 连接串用 pymysql 写一个查询工具注册给 Agent 即可import pymysql def query_book(book_title, fieldNone): conn pymysql.connect( hostmysql38ab0bc01cc2.rds.ivolces.com, userlanqiao, passwordJRemizRCwKZqPAGvDmiV28Q, databaselqb_ss_books, charsetutf8mb4, connect_timeout10 ) try: with conn.cursor() as cur: if field: sql fSELECT {field} FROM book WHERE 书名 LIKE %s LIMIT 1 cur.execute(sql, (f%{book_title}%,)) else: sql SELECT * FROM book WHERE 书名 LIKE %s cur.execute(sql, (f%{book_title}%,)) return cur.fetchall() finally: conn.close()逻辑说明连接参数全部来自题面 DSN注意 charset 必须用 utf8mb4否则中文可能乱码connect_timeout 设 10 秒防止数据库连不上时 Agent 长时间卡死。LIKE 查询在数据量几百行时够用不需要上全文索引field 参数传列名时只查所需的那个字段减少数据传输响应时间更快。参数说明书名匹配用 LIKE %关键词% 能解决「《小王子》」和「小王子」的差异但要注意「百年孤独」和「《百年孤独》新版本」这种带修饰词的书名最好在传入 SQL 前用正则把括号和修饰词剥离。多版本对比的 SQL 要用 GROUP BY 书名查出所有版本然后根据题面问的差异点在 Python 里做字段比对不要试图一条 SQL 查出「差异」。3.4 版本差异识别的实现思路版本混淆是评审明确点名的缺陷类型「回答中将 2015 版定价与 2020 版的页数混合引用」就是这类失误。要避免它必须在数据查询阶段就把版本区分开。我的做法是在 Prompt 里强约束回答任何书籍信息问题前先判定这本书有几个版本如果有多个版本必须显式说明引用的是哪个版本并且同一问题的所有字段来自同一个版本记录。技术上可以做一层版本聚合用 pandas 按书名分组组内按出版时间排序为每个版本生成一个包含完整字段的快照字符串。这样模型在回答时拿到的是「版本快照」而不是散乱的字段混用的概率大幅降低。快照生成代码import pandas as pd df pd.read_csv(books.csv, encodingutf-8) df[版本快照] df.apply( lambda row: f版本ID:{row[出版时间]} 书名:{row[书名]} 作者:{row[作者]} 译者:{row.get(译者,)} 出版社:{row[出版社]} ISBN:{row[ISBN]} 页数:{row.get(页数,)} 定价:{row.get(定价,)} 摘要:{row.get(内容摘要,)}, axis1 ) snapshot_by_book df.groupby(书名)[版本快照].apply(list).to_dict()逻辑说明groupby 按书名分组后同一本书的不同版本会聚合成一个列表每个快照字符串里完整包含了该版本的所有字段模型只需要在快照内取值就不会跨版本混用。注意译者、页数、定价这些字段可能不存在用 get 加默认空字符串防止 KeyError。参数说明出版时间字段如果格式不统一比如「2015-01-01」和「2015/1/1」混用要先统一成字符串格式再拼进快照否则排序会出错。版本快照的优点是模型看到的是「一个版本一条完整记录」比提供 JSON 数组更不容易产生幻觉。4. 多轮记忆机制Session 状态管理、意图槽位填充与摘要归档4.1 为什么「每轮重新解析」必挂赛题在记忆部分直接写明了一个典型误区每轮提问都重新解析导致上下文断裂。实际测试中你会发现用户第一轮问「《小王子》的作者是谁」第二轮接着问「那这本书的出版社呢」第三轮问「它和《狐狸的故事》是同一个作者吗」——如果第二轮还把「这本书」当成一个新实体去全局检索大概率匹配到错误的书。多轮对话的核心是把「指代消解」和「会话状态维护」做对。最常见的方案是维护一个 session 状态对象里面记录当前讨论的主要实体、实体的版本、上一轮意图。用户每一轮的新问题先做意图识别如果是追问类意图「它」「这本书」「那本」就用状态里的实体填充槽位而不是重新解析。4.2 Session 记忆与槽位填充的最小实现对话型智能体平台上一般有内置的会话变量能力但如果你是在自己代码里调试下面这个结构足够比赛用class SessionState: def __init__(self, session_id): self.session_id session_id self.current_book None self.current_version None self.history [] self.slots {} # intent槽位填充 self.summary None def update(self, intentNone, bookNone, versionNone): if book: self.current_book book if version: self.current_version version if intent: self.slots[intent] intent self.history.append({ intent: intent, book: book, version: version, ts: time.time() }) def resolve_entity(self, raw_question): # 指代消解如果问题中出现这本它那本等代词使用当前context pronouns [这本, 这个, 它, 该书, 那本, 上述] for p in pronouns: if p in raw_question: return self.current_book, self.current_version return None, None逻辑说明update 方法在每一轮对话后用新的实体/意图覆盖旧状态resolve_entity 是关键的指代消解逻辑检测到代词时直接用当前书和当前版本兜底。注意版本信息也要存不然用户说「这本书的新版页数是多少」时你不知道他指的是哪个版本。参数说明代词列表要覆盖常见指代但也要小心误判——「那本《红楼梦》」既包含代词也包含新书名这时要优先识别书名实体而不是直接用 context。判断顺序应该是先做命名实体识别识别出书名就用新实体识别不出才走指代消解。4.3 长对话摘要归档与「过度记忆」的边界赛题要求「历史问答摘要归档」同时提醒「不恰当的过度记忆误用历史内容答非所问」。这两条要平衡。我的处理策略是每轮对话在状态里追加一条摘要记录摘要只保留三个要素——用户问了什么书、关注哪些字段、上一轮结论是什么。超过 6 轮对话后用大模型把历史条目压缩成一段三句话以内的会话摘要用于后续引用。过度记忆的典型翻车现场是用户第一轮问「《百年孤独》的作者是谁」你记住了「百年孤独」第二轮问「《百年孤独》的亚马逊评分是多少」这是合理关联但如果用户第三轮问「《霍乱时期的爱情》呢」你还在用「百年孤独」的上下文去解析代词的指代就会答错。所以每次识别到新书名实体时必须强制替换 current_book而不是追加到记忆里混合使用。关于摘要归档我建议在 Prompt 里增加一条系统提示「当用户的问题中包含前序对话中提到的信息时优先使用会话摘要和槽位内容但每个事实必须能从数据源或历史对话中溯源无法溯源的内容不得输出。」这就把记忆和拒答机制绑在了一起——记忆只是指路牌不是事实来源。4.4 多轮对话评测追问理解率怎么测评测记忆效果不能只看单轮准确率要模拟真实追问链路。我的做法是构造一组三轮对话测试集test_conversations [ [ {role: user, content: 《小王子》的作者是谁}, {role: user, content: 这本书的出版社是哪家}, {role: user, content: 它的出版时间呢} ], [ {role: user, content: J.K.罗琳写了哪些作品}, {role: user, content: 《哈利·波特与魔法石》是哪一年出版的}, {role: user, content: 这本和《密室》比哪本更早} ] ] def evaluate_memory(agent, conversations): correct 0 total 0 for conv in conversations: agent.reset_session() for turn in conv: answer agent.respond(turn[content]) # 此处接入标准答案比对逻辑比对时忽略格式差异 total 1 if is_correct(answer, turn.get(expected)): correct 1 return correct / total逻辑说明每个会话里连续三个问题共享同一个主题上下文第二、第三问必须依赖第一轮的语义才能真正答对——「这本书」指代《小王子》「这本」指代《哈利·波特与魔法石》。reset_session 在每组合法会话前清空状态避免串场。评测指标就是「多轮会话中正确理解上下文比例」。参数说明注意第三问「这本和《密室》比」既包含指代「这本」也包含新实体「《密室》」这是一个典型的混合问题——解法是提取出所有书名实体指代词单独用上下文兜底两个实体同时进入槽位。如果 Agent 对这类混合问题答错说明实体识别和指代消解的优先级没调对。5. 避坑与排查格式错乱、拒答误判和数据源断连5.1 选择题输出了选项内容而不是序号现象模型对「《小王子》的作者是谁 A. 马克·吐温 B. 安托万·德·圣埃克苏佩里 C. 查尔斯·狄更斯 D. 原知识库未提及」直接回答「作者是安托万·德·圣埃克苏佩里」而不是输出「B」。原因默认对话模型有强烈的「完整回答」惯性看到问句就喜欢组织自然语言答案而不是执行格式指令。题面明确要求只输出选择序号。解决Prompt 里加一条硬约束「当问题呈现为选择题格式包含 A/B/C/D 选项时你只允许输出一个或若干个字母禁止输出任何其他字符」并在后处理里加正则校验——如果输出内容不是纯字母序列强制截取或置为拒答短语。我在比赛里直接写了一个后处理函数answer 只保留大写字母如果长度超过 5 个且包含「A」「B」之外的字符就判断为格式错误。5.2 多选题输出顺序不符合要求现象多选题标准答案是「ABD」模型输出「DAB」或「A、B、D」。原因模型在排序上没有确定性尤其是多个选项置信度接近时输出顺序随机。解决后处理里做一步排序——把答案字符串拆成单字符列表按字母表排序后再拼接。注意题面明确说「多选输出时按照字母顺序输出」所以这道题不存在其他合法顺序直接 sort 即可。如果是「AB,AC,BC,ABC」这种多组合输出要按组合的字典序排列分号或逗号分隔格式也要统一。5.3 查询原文时句尾多了标点符号现象题面要求「回答内容应当完全引用原文且句尾不需要保留标点符号」模型输出「书是一本描写孤独的经典著作。」句尾带了句号。原因模型在生成自然语言时习惯性补标点完全不理解「句尾不需要保留标点符号」这个约束的语义。解决检测到「查询原文」关键词时走单独的 Prompt 分支强调「逐字复制原文片段禁止任何增改禁止添加句尾标点」同时在代码后处理里对答案做 strip 和标点剥离。注意标点剥离只能删句尾的一个符号不能删掉原文中句中的标点否则内容就失真了。5.4 数据源断连导致 Agent 卡死或超时现象用户提交问题后Agent 长时间无响应最后返回超时报错。原因数据库连接池没配超时时间MySQL 连接失败时 pymysql 默认会阻塞较长时间或者 CSV 解析失败后 Agent 直接报错没有降级方案。解决所有外部数据源调用都套 try-except 和超时参数。connect_timeout 设 10 秒读操作超时设 5 秒CSV 读取失败时自动切换到数据库查询数据库查询失败时自动切换回 CSV。双数据源互为冗余题面本来就给了 csv 和 MySQL 两个来源不要只依赖一个。5.5 情感化和扩展回答导致知识边界失控现象用户问「这本书好看吗」或「你觉得《小王子》传递了什么价值观」模型开始长篇大论谈感想。原因题面要求「高度主观或需要外部新近资讯的问题若数据集中无明确记录触发统一拒答」。模型的共情能力强非常容易被诱导输出数据集之外的观点。解决系统提示里强调「你是信息检索助手不是书评人回答仅依据数据集的字段内容不包含任何个人观点、评价或推测当问题涉及价值判断或外部知识时输出统一拒答语」。同时加一层意图分类主观评价类意图直接走拒答分支不触发检索。这也回应了赛题里「乱用参考资料、生成伪知识」的误区警示。6. 发布、验证与 APPID 提交四小时内的可用性闭环开发完不等于比赛结束你还需要完成发布、验证和提交 APPID 三个动作。开考 1 小时后可以提前交卷但交卷后无法再进入答题环境也不能继续操作 HiAgent 平台。所以时间分配上我建议前 2.5 小时专注开发和测试第 3 小时做完整验证和修复最后 30 分钟发布并提交 APPID。先做发布前验证。验证清单至少包含四类题单选精确匹配答案字母、多选输出顺序排序、对比题多版本差异、查询原文句尾无标点。每题都要实际跑一遍不要只在 Prompt 层面推理。# 验证脚本框架跑通全部题型再发布 test_cases [ {type: 单选, question: 《小王子》的作者是谁\nA. 马克·吐温\nB. 安托万·德·圣埃克苏佩里\nC. 查尔斯·狄更斯\nD. 原知识库未提及, expected: B}, {type: 多选, question: 以下哪些作品是J.K.罗琳创作的\nA. 《哈利·波特与魔法石》\nB. 《哈利·波特与密室》\nC. 《杀死一只知更鸟》\nD. 《哈利·波特与死亡圣器》\nE. 原手册中未提及, expected: ABD}, {type: 对比, question: 数据集中的《百年孤独》新版与旧版相比以下哪个差异是正确的\nA. 新版增加了作者序言\nB. 新版采用了不同的译者\nC. 新版页数增加了15%以上\nD. 新版零售价格提高了20元, expected: A}, {type: 原文, question: 查询原文《百年孤独》的内容摘要第一句是什么, expected: 无句尾标点的原文片段} ] for t in test_cases: result agent.respond(t[question]) print(f{t[type]}: 模型输出{result}, 期望{t[expected]}, 通过{result.strip() t[expected]})逻辑说明验证脚本的用意是防回归——你改了一版 Prompt 后不能只测刚改的那道题要把全部题型重跑一遍。选择题比对用 strip 后的精确匹配原文题比对要把句尾标点去掉后比对。注意多选题的 expected 必须是「ABD」这种排序后的格式。参数说明测试顺序有讲究——先测格式最严格的题单选/多选再测需要数据比对能力的题对比/原文最后测拒答类。格式题不过就不要再测内容题因为输出格式是硬门槛。发布操作在 HiAgent 平台完成核心是拿到 APPID 并提交到比赛系统的问答题答题框。特别注意提交的必须是你最终发布的那个版本的 APPID改过 Prompt 后重新发布会生成新的 APPID不要提交旧的。比赛结束时系统自动交卷未提交 APPID 或上传错误 APPID 均不予评奖。最后说一个我的习惯每次发布新版前我都会花两分钟跑一遍上面四类题的验证脚本确认五种边界行为都正常——选择题只出字母、多选题已排序、对比题答案在数据范围内、过滤外部信息、正确引用前文。从那以后我每次搭比赛 Agent 都强制走一遍「边界五查」宁可多花两分钟验证也不要交卷后才发现某个简单题因为格式问题丢分。希望帮到你。本文还有配套的精品资源点击获取