suppr.wilddata.cn 文献检索,用中文搜 PubMed 一种基于大语言模型的智能搜索引擎构建方法

如何让小智AI成为你的第二大脑——“免费”送小智AI智能音箱征文活动 10w+人浏览 157人参与

AI助手已提取文章相关产品:

根据检索结果,专利CN118964589B的详细信息如下:


专利基本信息

  • 专利名称:一种基于大语言模型的智能搜索引擎构建方法
  • 授权公告号:CN118964589B
  • 授权公告日:2025年4月11日
  • 申请号:2024108105490
  • 申请日:2024年6月21日
  • 申请人:数野科技(深圳)有限公司(成立于2023年,注册资本200万人民币,主营软件和信息技术服务)

技术方案概述

该专利公开了一种基于大语言模型的智能搜索引擎构建方法,包含6个核心步骤,重点优化了查询改写模块文档重排序模块

步骤1:原始查询

用户以自然语言形式输入检索语句。

步骤2:过滤器人工设置

用户可设置多种过滤器约束召回文档,包括:

  • 时间过滤器:指定文档发布时间范围
  • 出版方过滤器:限制特定出版方文档
  • 文献影响因子过滤器:指定影响因子范围
  • 文档类型过滤器:如正式文章、时评等
步骤3:检索改写(核心创新模块)

基于用户输入的原始查询和过滤器设置,通过以下子模块转换为专业检索语句:

  1. 基于NER的动态few-shot示例

    • 从系统积累的"原始查询-改写结果"示例库中,使用命名实体识别(NER)技术召回结构相似的示例(而非仅主题相似),提升LLM改写准确率
  2. 专业术语推荐

    • 先用LLM总结原始查询的关键词列表
    • 在自建Elasticsearch术语库中检索,召回书写完全正确的专业术语,辅助精准改写
  3. 基于LLM的检索主句改写

    • 构建包含任务说明、检索引擎信息、改写原则、few-shot示例、专业术语列表和原始查询的prompt
    • 由LLM生成改写的检索主句
  4. 检索主句校验

    • 采用多轮"改写-校验"机制:若检索引擎执行报错,将错误信息反馈给LLM要求其修改
    • 提高改写语句的准确率和执行成功率
  5. 过滤器自动规划模块

    • 总体规划:通过LLM和提示词工程确定所需过滤器列表(不使用React等"贪心"型agent,提高并行性)
    • 参数确定:对每个过滤器,通过LLM确定具体参数
    • 子句生成:调用过滤器生成对应的检索子句
  6. 检索语句转换模块与主句合并

    • 将过滤器生成的子句与检索主句合并,得到最终检索语句
步骤4:检索引擎

使用检索引擎获取相关文档列表。

步骤5:文档重排序(另一核心创新)

针对冷启动阶段缺乏标注语料的问题,提出两种基于LLM的zero-shot重排序方案

  1. Pointwise重排序

    • 使用多元评分框架将文档相关性拆解为多层次评分,使排序更准确合理
  2. Listwise重排序

    • 结合快速排序/部分快速排序算法
    • 解决LLM无法通过listwise prompt一次性给出完整排序的问题
步骤6:文档总结与标引
  • 基于用户原始查询和重排序后的文档列表
  • 使用LLM总结文档内容、回答问题
  • 在作答片段后标识引用来源,方便用户事实性校验,提升可信度

主要创新点

根据专利说明,本发明在以下方面实现突破:

  1. 检索改写模块

    • 提出过滤器自动规划和检索语句转换框架,处理复杂检索需求
    • 提出基于NER的动态few-shot提示词策略,提升召回示例的参考价值
  2. 文档重排序模块

    • 提出基于LLM的pointwise重排序方案(多元评分框架)
    • 提出基于LLM的listwise重排序方案(结合快速排序算法)

技术术语解释

术语含义
NER命名实体识别(Named Entity Recognition)
few-shot示例在prompt中提供少量任务示例,提升LLM完成任务的准确率
Pointwise逐个点对点评分的排序方法
Listwise整体列表排序方法
RAG检索增强生成(Retrieval-Augmented Generation)
zero-shot无需标注语料即可执行任务

检索结果补充说明

虽然直接访问专利局链接失败,但第三方来源证实该专利于2025年4月19日由数野科技(深圳)有限公司正式取得授权。专利的核心是通过LLM实现智能查询改写和文档重排序,解决了传统搜索引擎在语义理解和结果排序上的局限性。


总结:该专利构建了一套完整的基于LLM的搜索引擎技术栈,在查询改写阶段通过NER动态示例和术语推荐提升准确性,在重排序阶段通过zero-shot方案解决冷启动问题,最终通过引用标引增强结果可信度,显著提升了检索准确率与重排序合理性。

专利CN118964589B规避策略分析

绕开专利的核心是避免落入其权利要求保护范围。必须首先获取该专利的权利要求书进行精确分析,以下策略基于专利摘要和说明书内容提供方向性建议:


第一步:精确界定保护范围

必做工作:

  1. 获取权利要求书:通过专利局或商业数据库获取完整权利要求文本
  2. 技术特征分解:将独立权利要求分解为必要技术特征(A+B+C…)
  3. 识别创新点:重点针对"基于NER的动态few-shot"和"zero-shot重排序"两大核心创新

第二步:系统性规避路径

路径一:省略非必要技术特征(最稳妥)

原理:若某特征非解决技术问题所必需,可直接删除

  • 可尝试省略
    • 移除"过滤器自动规划"模块,改为预定义过滤器模板(用户手动选择而非LLM自动规划)
    • 移除"专业术语推荐"模块,改用通用同义词扩展无需术语库的改写方式
    • 移除"检索主句校验"的多轮纠错机制,改为单次生成+人工审核
  • 风险:需验证省略后是否影响整体技术效果,避免被认定为"变劣发明"

路径二:技术特征替换(关键创新点规避)

原理:用不同技术手段实现相似功能,避免等同侵权

专利特征规避替代方案
基于NER的动态few-shot示例改用向量相似度检索(非NER结构相似)或固定few-shot示例库(非动态)
过滤器自动规划(LLM+提示词工程)改用规则引擎决策树进行过滤器选择,完全不用LLM规划
Pointwise重排序(多元评分框架)改用Pairwise排序传统Learning to Rank模型(非LLM-based)
Listwise重排序(快速排序)改用归并排序或其他排序算法,或不分割列表直接处理

路径三:改变技术架构(深层规避)

原理:重构整体流程,使技术方案在结构上与专利有本质差异

  1. 检索改写模块重构

    • 专利方案:原始查询 → NER示例召回 → 术语推荐 → LLM改写 → 过滤器规划 → 合并
    • 规避方案:原始查询 → 查询分类器多模板匹配模板填充 → 输出检索语句
    • 差异点:移除LLM生成,改用基于模板的确定性规则
  2. 重排序模块重构

    • 专利方案:文档列表 → LLM多元评分/快速排序 → 重排序结果
    • 规避方案:文档列表 → 传统特征工程(如BM25、TF-IDF加权)→ 贪心重排序
    • 差异点:完全不用LLM参与重排序,回归传统信息检索方法

路径四:利用专利局限性

类型利用方式
地域性该专利仅在中国有效,可在**海外(未申请国家)**部署相同技术
时间性发明专利保护期20年(2044年到期),可等待到期后实施
保护范围漏洞若权利要求未明确限定开源组件使用,可全部采用开源技术栈规避

路径五:功能裁剪+增量创新

采用TRIZ理论中的功能裁剪法:

  1. 识别核心功能:专利的核心是"提升检索准确率"而非具体实现方式
  2. 裁剪有害功能:移除"依赖LLM导致的高成本"这一潜在不足
  3. 重新组合:将剩余功能与新的技术特征(如用户行为反馈、知识图谱)结合,形成改进发明

第三步:具体实施建议

低风险规避方案(推荐)

# 规避方案示例:用规则引擎替代LLM自动规划

# 专利方案:LLM自动规划过滤器
def original_approach(query, llm_client):
    prompt = f"为用户查询'{query}'规划需要的过滤器类型"
    filters = llm_client.generate(prompt)  # 侵权风险高
    return filters

# 规避方案:基于规则映射
def avoided_approach(query, rule_engine):
    query_type = rule_engine.classify(query)  # 改用分类器
    filters = rule_engine.get_preset_filters(query_type)  # 预定义模板
    return filters

规避要点:移除LLM的生成决策,改用确定性规则

高风险规避方案(慎选)

  • 简单替换LLM模型:如用不同厂商LLM(仍属等同侵权)
  • 仅调整prompt措辞:不改变LLM核心作用(极易构成等同侵权)
  • 增加无关功能模块:如添加日志记录(不改变侵权实质)

第四步:法律风险防控

  1. FTO分析(自由实施):在研发早期进行全面的专利侵权检索,确认规避方案不侵犯其他专利
  2. 专利无效检索:检索该专利的现有技术,评估提起无效宣告的可能性
  3. 文档留痕:详细记录规避设计的技术决策过程,证明独立研发
  4. 商业秘密保护:对规避方案中的关键算法参数作为技术秘密保护,不公开

核心建议

策略推荐度说明
省略过滤器自动规划⭐⭐⭐⭐⭐最易实现,侵权风险最低
替换NER相似度算法⭐⭐⭐⭐需确保新算法在原理上有本质差异
改用传统排序模型⭐⭐⭐⭐效果可能下降但法律风险极低
海外部署⭐⭐⭐需确认目标国家无同族专利
挑战专利有效性⭐⭐⭐需找到强有力的现有技术证据

最终建议:聘请专业专利律师+技术专家联合分析权利要求书,制定3-5套规避方案,并通过专利地图分析确认不侵犯其他相关专利。规避的核心原则是 “技术方案实质性不同” 而非"表面差异"。

您可能感兴趣的与本文相关内容

<think> 我们分析命令:`cppcheck test.c --enable=all 2> test_log.err.origin` 这条命令的作用是使用Cppcheck静态分析工具对`test.c`文件进行代码检查,并开启所有可用的检查规则(通过`--enable=all`选项),同时将标准错误输出(stderr)重定向到文件`test_log.err.origin`中。 具体分解: 1. `cppcheck`: 静态分析工具的名称。 2. `test.c`: 要分析的源文件。 3. `--enable=all`: 启用所有检查器。Cppcheck默认只启用一部分检查,此选项会启用包括风格、性能、可移植性等所有类别的检查。 4. `2> test_log.err.origin`: 将标准错误输出(文件描述符2)重定向到文件`test_log.err.origin`。这意味着所有的错误信息(包括警告、错误、内部错误等)都会被写入该文件,而不会显示在终端上。 可能出现的情况: - **正常情况**:Cppcheck会分析`test.c`文件,并将检测到的问题(如内存泄漏、空指针解引用、未初始化变量等)输出到标准错误流,因此这些信息会被保存到`test_log.err.origin`文件中。用户可以通过查看该文件了解代码中的潜在问题。 - **错误情况**: 1. 如果`test.c`文件不存在或路径错误,Cppcheck会输出错误信息到标准错误,因此该错误信息也会被重定向到`test_log.err.origin`中,此时文件中会有类似`test.c: No such file or directory`的错误。 2. 如果Cppcheck命令本身有错误(如选项错误),同样会输出错误信息到该文件。 3. 如果Cppcheck在分析过程中遇到内部错误(例如,语法解析失败、内存不足等),这些错误也会被记录到该文件。 4. 如果目标文件很大或者启用了所有规则,分析时间可能会很长。 注意:标准输出(stdout)默认仍然是终端,所以正常的进度信息(如果Cppcheck有输出)会显示在终端,但错误信息会被重定向。然而,Cppcheck通常将检查结果输出到stderr,因此`test_log.err.origin`文件将包含主要的检查结果。 另外,使用`--enable=all`可能会产生大量的警告,其中包括一些风格和可移植性问题,这些问题可能并不都是关键的。因此,我们需要仔细分析日志文件,筛选出真正的问题。 相关问题: 1. 如何理解Cppcheck的输出日志格式? 2. 如何过滤Cppcheck的输出,只显示特定严重性(如错误、警告)的信息? 3. 如何配置Cppcheck忽略某些文件或目录? 4. 如何将Cppcheck的结果集成到持续集成(CI)流程中? 5. 如何处理Cppcheck报告的大量风格警告? </think> ### 分析命令:`cppcheck test.c --enable=all 2> test_log.err.origin` #### 1. 命令组成解析 | 组成部分 | 作用说明 | |---------|----------| | `cppcheck` | 静态代码分析工具主程序 | | `test.c` | 待分析的C语言源文件 | | `--enable=all` | **关键参数**:启用所有检查规则(包含但不限于):<br>- `style`:编码风格问题<br>- `warning`:潜在逻辑错误<br>- `performance`:性能隐患<br>- `portability`:跨平台问题<br>- `information`:代码信息提示<br>- `unusedFunction`:未使用函数检测 | | `2> test_log.err.origin` | 将**标准错误输出(stderr)**重定向到文件:<br>- 保存所有错误/警告信息<br>- 保留原始未处理格式 | #### 2. 执行过程与输出解析 ```mermaid graph LR A[启动cppcheck] --> B[加载test.c] B --> C[[执行全规则扫描]] C --> D{检测结果分类} D -->|错误/警告| E[输出到stderr] D -->|进度信息| F[输出到stdout] E --> G[重定向至test_log.err.origin] F --> H[显示在终端] ``` **典型输出内容**: ```log test.c:15: error: Null pointer dereference [nullPointer] if (ptr->data) {...} ^ test.c:32: warning: Possible leak of memory 'buf' [memleak] buf = malloc(100); ^ test.c:5: style: The function 'func' is never used [unusedFunction] ``` #### 3. 可能出现的情况分析 ##### ✅ **正常情况** 1. **生成完整报告文件** `test_log.err.origin`包含所有发现问题,格式: ``` [文件名]:[行号]: [严重级别]: [描述] [规则ID] [代码片段] ^(错误位置标记) ``` 2. **终端显示进度信息** 如:`Checking test.c: 50% done` ##### ️ **异常情况** 1. **空输出文件** - 代码完全规范(罕见) - 分析被中断(如权限问题) 2. **超大输出文件** 常见原因: - 代码存在大量风格问题(如缺少空格、括号位置等) - 启用`information`级别产生冗余提示 *解决方案*:`--enable=warning,performance`限定范围 3. **误报(false positive)** 典型场景: - 宏定义导致的逻辑误判 - 跨文件调用未识别 *解决方案*:添加`--inline-suppr`注释抑制 4. **分析崩溃** 错误表现: ```log Internal error: Segmentation fault Bailing out from analysis... ``` 常见原因: - 复杂模板元编程 - 深度嵌套的宏展开 *解决方案*:分模块检查或使用`--max-ctu-depth=5` #### 4. 最佳实践建议 1. **分级启用规则**(推荐替代`--enable=all`) ```bash cppcheck test.c --enable=warning,performance # 仅关键问题 ``` 2. **结果过滤技巧** ```bash # 提取特定类型错误 grep 'error:' test_log.err.origin ``` 3. **与编译系统集成** ```makefile check: cppcheck $(SRCS) --enable=warning 2> cppcheck.log [ $(shell grep -c "error" cppcheck.log) -eq 0 ] # 错误计数检查 ``` #### 5. 扩展应用场景 1. **CI/CD流水线集成** ```yaml - name: Static Analysis run: | cppcheck src/ --enable=all --xml 2> report.xml cppcheck-htmlreport --file=report.xml --title=MyProject ``` 2. **定制规则扩展** 通过Python插件添加自定义规则(需解决前述接口问题[^1]) --- ### 相关问题 1. 如何过滤Cppcheck结果中的低优先级警告? 2. Cppcheck的XML报告格式如何解析? 3. 如何为大型项目配置Cppcheck的扫描策略? 4. Cppcheck与其他静态分析工具(Clang-Tidy)有何优劣? 5. 如何通过编译选项减少误报?[^2]
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值