人工智能搜索引擎本地部署后端MCP 服务【免费下载链接】xerjXERJ is the new way for AI to search data. Its autoindex capability activates agents to know your data without the token waste of grep and sed. One command indexes code, docs, logs and PDFs for search, RAG, security audits and agent memory, using 40x fewer tokens than grep. Elasticsearch compatible, so existing clients just work.项目地址https://gitcode.com/GitHub_Trending/xe/xerj点击查看免费下载本文以仓库中 05-index-patterns-data-views 分类报告 为主体,完整呈现该分类下 451 条真实用户反馈(451 items · negative 172 · neutral 229 · positive 50)的评分榜单、标签分布与数据溯源方式,并结合 xerj 仓库中的语料构建管线(collect → classify → stats)、分类法定义与工件 Schema,讲清楚这份反馈报告从哪来、怎么读、怎么用,读完你可以掌握一套可复现的竞品用户反馈语料库的分析方法,并理解 Index Pattern / Data View 这一领域长期以来的真实痛点结构。语料库背景:15,282 条 Kibana 反馈是怎么来的user-feedback/kibana/是 xerj 仓库内置的一份结构化、可复现的 Kibana 真实用户反馈语料库,官方说明中它被定位为决定 XERJ.ai 应该建什么、不应该建什么的输入(see 语料库总 README)。截至 2026-04-14 的最后一次刷新,语料库共包含15,282 条工件,来自 5 个公开来源,归入 17 个分类,来源构成如下(引自语料库 README 的 Sources 表):Source采集 API认证条数GitHub Issuesapi.github.com /repos/{owner}/{repo}/issues(4 个仓库)GH_TOKEN,5K/hr9,230Stack Overflowapi.stackexchange.com /2.3/questions(13 个标签)无2,836Hacker Newshn.algolia.com /api/v1/search_by_date(25 组查询)无1,504Redditreddit.com/.json按子版块搜索(12 组查询)无962Discoursediscuss.elastic.co/search.json(20 组查询)无750其中 GitHub 是最深的来源,覆盖elastic/kibana(1,141 条)、elastic/elasticsearch(1,030 条)、elastic/eui(3,832 条,内部组件库,大多数插件破坏性问题在这里)和opensearch-project/OpenSearch-Dashboards(3,044 条,开源 fork 的 issue 追踪器)共 4 个仓库。原始数据落在sources/source/{raw.jsonl, enriched.jsonl},例如 GitHub 源数据。每个工件都是一行 JSONL,遵循 SCHEMA.md 定义的统一结构,关键字段包括:{ id: hn-42173842, source: hackernews, source_url: https://news.ycombinator.com/item?id42173842, posted_at: 2024-11-14T22:14:00Z, captured_at: 2026-04-14T18:22:41Z, author: someuser, score: 42, kind: comment, title: ..., body: ..., product: [kibana, elasticsearch], sentiment: negative, category: 09-upgrades-and-migration, secondary_categories: [01-dashboard-authoring], tags: [upgrade-break, kql, dashboards, production], quote: every upgrade breaks our dashboards }其中category是主分类(每条工件只有一个),secondary_categories最多三个,score统一为社区认同度(GitHub reactions、HN points、SO 票数等)。分类判定规则在 TAXONOMY.md 中写明:评分低于阈值的工件落入99-uncategorized/人工分诊,重跑分类器会确定性重写指针文件,绝不静默丢弃任何工件。05-index-patterns-data-views 分类的定义在 17 个分类中,本文主体05-index-patterns-data-views的官方定义(TAXONOMY.md 第 36-40 行)是:Pain axis:UX— Index patterns / data views renames, field refresh, wildcard pattern pain, runtime fields, scripted fields, mapping explosion surfaced through UI.Keywords:index pattern、data view、field refresh、runtime field、scripted field、mapping。也就是说,这个分类专门收集用户在与数据视图打交道时的挫败感:给 index pattern 改名、字段列表不刷新、通配符模式的坑、runtime/scripted 字段的支持缺口,以及 mapping 膨胀通过 UI 暴露出来的各种症状。分类器是纯关键词规则(非 LLM),因此该分类的边界由上述关键词驱动——这是阅读本分类报告时必须记住的前提。数据规模与情感分布该分类报告头部一行给出了主分类口径的统计:451items · negative 172 · neutral 229 · positive 50换算成比例约为:negative38.1%、neutral50.8%、positive11.1%。作为参照,全库 15,282 条中 negative 占 38.0%,也就是说本分类的负面比例与全库基本持平,它不是重灾区,而是一个体量中等、痛点高度集中在少数大 issue 上的分类。需要特别注意一个容易误读的细节:451统计的是主分类为本分类的工件数;而 pointers.jsonl 实际有1,199 行。按 SCHEMA.md 的说明,categories/slug/pointers.jsonl收录的是被分配到该分类的工件投影——包括把本分类作为次要分类的条目,这些条目的指针行带_secondary: true标记。对 pointers.jsonl 做来源统计,分布为:github 592、stackoverflow 494、discourse 56、reddit 45、hackernews 12。每一行指针形如:{id:disc-1106207,source:discourse,score:2,posted_at:2022-08-15T12:52:03.469Z,tags:[data-views],title:Kibana - Alert data viewer and Edit Rule are stuck and slow}要读完整正文,按id回查对应来源的sources/src/enriched.jsonl(例如gh-kibana-1084去sources/github/enriched.jsonl中查)。分类报告原文里的指针链接../../sources/src/enriched.jsonl对应仓库根路径即 GitHub 源、Stack Overflow 源、Reddit 源、Discourse 源、Hacker News 源。报告是怎么生成的:stats.mjs 的三个步骤每个分类目录下的README.md不是手写的,而是由 pipeline/stats.mjs 生成的。该脚本的头部注释写明了输入输出:// Reads all enriched JSONL category pointer files and writes: // • INDEX.md — master stats table // • categories/slug/README.md — one per category, with the top // 20 highest-score items and 1-line quotes (themes generator) // Run: node pipeline/stats.mjs生成逻辑(见 stats.mjs 源码)分三步:加载:遍历sources/下所有目录,读取每个enriched.jsonl(由classify.mjs产出),JSON.parse逐行解析并累计各来源计数;主分类 Top 20:对items.filter(i i.category cat)按score降序排序取前 20 条,渲染成本文后面完整收录的榜单表(标题经trim压缩到 80 字符);标签统计:在本分类(主分类口径)内聚合tags频次,取前 12 个渲染成 Top tags 表,最后fs.writeFileSync落盘。整条流水线在 语料库 README 的 How to refresh 一节中给出了复现命令(零依赖,纯 Node 22 ESM,只用内置fetch):cd user-feedback/kibana # 从 5 个来源拉取数据(GH_TOKEN 已设时 GitHub 拉取约 8 分钟) GH_TOKEN$GH_TOKEN node pipeline/collect.mjs # 或单来源 node pipeline/collect.mjs --source github --pages 100 # 分类(确定性、幂等) node pipeline/classify.mjs # 写 INDEX.md 各分类 README node pipeline/stats.mjsJSONL 是 append-only 且按id去重,重跑安全;GitHub 采集按仓库分批 flush,中途中断可保留已完成部分。全量刷新(含 GitHub 认证)约 10 分钟墙钟时间。Top 20 高分反馈全量榜单以下是分类报告中的完整 Top 20 榜单(按 score 降序,主分类口径)。为遵守本文输出规范,原文档中的外部跳转链接不直接保留,改为给出可在pointers.jsonl/enriched.jsonl中检索的工件 id 或仓库 issue 编号,方便逐条溯源:#SourceScoreTitle溯源1github469Nested field supportgh-kibana-1084(elastic/kibana#1084,2014 年提出)2github72Change index on visualization/dashboardgh-kibana-36683github72Date type has not enough precision for the logging use case.gh-es-10005(elastic/elasticsearch#10005)4github68ignore_malformed to support ignoring JSON objects ingested into fields of the wrong typegh-es-123665github57Remove index pattern mapping cachegh-kibana-64986stacko55Elasticsearch is still initializing the kibana indexSO 312010517github50Allow representing a document with multiple embeddings (dense vectors)gh-es-720688github45Per-user profiles, settings in Kibanagh-kibana-178889github39Timelion query language support for scripted fieldsgh-kibana-902210github38Index Patterns Refresh field list automatically update for new fieldsgh-osd-913(OpenSearch-Dashboards#913)11github37Nested field support in Visualizegh-kibana-5817512github32Latest metric agggh-kibana-687713stacko31Kibana Logstash ElasticSearch | Unindexed fields cannot be searchedSO 3047185914stacko30Timestamp not appearing in KibanaSO 2942920115stacko26Cant create two Types to same index elasticsearch KibanaSO 4763284616reddit23Help! Why is ELK so hard to configure?r/sysadmin 375h0m17stacko23Performing Calculations on Multiple Metrics (Counts) in Kibana 4SO 2965299218stacko21How to configure index pattern in KibanaSO 3428691719github20Field aliasesgh-es-2371420github20Duplicate handling with rollovergh-es-44794几个读表要点:榜首断层式领先:gh-kibana-1084(Nested field support)以 469 reactions、401 comments 位居全库 GitHub 功能请求榜首,比第二名高出 6 倍以上,是 Kibana 历史上最持久的功能诉求之一。榜首条目来自 2014 年(posted_at: 2014-03-21),该 issue 的正文直言:你读了_mapping字段,所以应该知道某个字段是 nested 的,能不能在查询或聚合选中这种字段时自动套用正确的 nested facet/query?——即希望 UI 对 nested 映射自动透明处理。榜单由 GitHub issues(11 条)、Stack Overflow 问题(6 条)、Reddit(1 条)构成,Discourse 与 HN 未进 Top 20,说明该分类的高价值信号高度集中在 issue 追踪器与问答社区。逐条深挖:六大痛点主题下面结合enriched.jsonl中的原始正文,把 Top 20 背后的诉求归并成六个可辨识的主题。以下引用均为语料库内工件正文的原话摘录。1. Nested 字段:一条 469 分的长尾诉求榜首gh-kibana-1084与其子 issuegh-kibana-58175(Nested field support in Visualize,37 分)构成同一主题。58175 的正文把问题具体化到聚合侧:对 nested 字段做 terms 聚合 count 指标时,每个桶到底数 nested 文档的数量,还是父文档的数量?两种答案都有用,取决于你要回答的问题。Visualize 编辑器需要以用户能理解的方式给出选择。 这条诉求自 2014 年挂起至今仍在被 1,是本分类里需求真实存在但产品多年未闭环的典型样本。2. 切换与导出 Data View:一个被拆分的 mega issuegh-kibana-3668(Change index on visualization/dashboard,72 分)被维护者标记为 mega issue,2018-04-04 的更新把它拆成了若干具体子问题,正文原话:Here are the three sub issues that I believe make up this mega issue: Changing index patterns on a visualization: #17542 Dashboard level index patterns: #16917 Improved export/import to include referenced objects... #16831 Nested dashboards: #16919其中子项 #17542(Ability to change the index pattern on a visualization,57 分)本身也进入了 pointers.jsonl 的前 10(带_secondary标记),说明换数据视图这一诉求在多个分类间交叉出现。相关地,gh-kibana-4288(Ability to export the index pattern along with saved objects,45 分)指向同一方向的导出侧痛点。3. 字段刷新与 mapping 缓存:最工程味的痛点簇这是本分类里技术细节最扎实的一簇,涉及三条工件:gh-kibana-6498(Remove index pattern mapping cache,57 分)正文解释了缓存的存在动机与代价:我们缓存了一份归一化后的 Elasticsearch mapping,因为大 mapping 解析很贵。但这带来了一堆问题,例如用户加了字段后,除非手动刷新 mapping 缓存(一件不明显的操作),否则看不到。基本上任何 mapping 变更都让用户痛苦……我们甚至默认把解析限制在 5 个索引内。gh-osd-913(OpenSearch-Dashboards,38 分)则给出了解决方向:我在 Dashboards 里发现新动态字段不出现在选择列表里……Kibana 在 PR 82223 里早就解决了,但我在这个版本里还得手动点 Index Patterns 的 refresh fields。他们通过移除字段缓存解决的——我希望 Dashboards 也能直接生效。Stack Overflow 侧的so-30471859(31 分)是同一症状的用户视角:JSON 日志直接入库后,很多字段在 Kibana 过滤器里报 unindexed fields cannot be searched;so-29429201(30 分)更直接:_timestamp字段旁边有个黄色警告说 No cached mapping for this field,导致无法按时间排序/过滤,时间字段下拉框为空。从这三条工件对照可以看出:新增字段不可见 → 手动刷新 → 缓存机制是 2015–2022 年间反复出现的同一故障链,后来在 Kibana 侧以去掉字段缓存的方式收敛(gh-osd-913 的引述即为证据)。对本分类之外的数据类产品而言,这提示:字段发现要么走缓存失效机制,要么干脆不缓存。4. 时间字段:精度不足与识别失败gh-es-10005(Date type has not enough precision,72 分)指出date类型只有毫秒精度,对日志场景不够,最直接的后果是按时间倒序排序时,同一毫秒的文档会乱序,用户看到事件乱序。so-29429201则是时间字段识别失败:Kibana 4.0 里_timestamp不被时间字段下拉框识别,创建 index pattern 时勾选 Index contains time-based events 后列表为空。榜单第 17 位的so-29652992和第 20 位的gh-es-44794(Duplicate handling with rollover)也与时间轴数据有关:前者要在 Kibana 4 里对多个 count 指标做计算;后者指出引入 rollover 后,文档写入哪个索引不可控了,Logstash fingerprint 按timestamp对齐索引去重的老办法失效。5. Mapping 冲突与膨胀gh-es-12366(68 分):把 JSON 对象写入已映射为 string 的字段时,即使开了index.mapping.ignore_malformed仍抛MapperParsingException。原文给出了 ES 1.6.0 的可复现 curl 用例(PUT 索引设置 POST 文档两步)。so-47632846(26 分):同一索引写两个 type 时报 Rejecting mapping update to [business],属于映射冲突的早期形态。pointers.jsonl 中还有disc-951743(Unable to load more than 30000 fields into index pattern,2021 年),代表 mapping 膨胀的另一极端——字段多到 UI 加载不动。6. 周边能力缺口:别名、多向量、每用户默认视图gh-es-23714(Field aliases,20 分)提议新增alias字段类型以支持时间序列索引下的字段改名平滑过渡,正文给出了完整的 mapping JSON 示例(sourceIP指向host.source_ip)。gh-es-72068(50 分)要求dense_vector支持一个文档挂多个 embedding,动机正是段落级检索/rerank 场景(每个 embedding 代表一个 passage,文档排序可以用最佳匹配 passage 的分数)——这条诉求与 xerj 主打的向量检索方向直接相关,是本分类中少见的未来特性类高分项。gh-kibana-17888(45 分)要求按用户配置默认项,清单里第一条就是 Default index pattern,其余包括默认 space、时区、主题等。Top tags 分布与次级信号分类报告下半部分是本分类的 Top tags(与04-performance-and-load等分类共享统计口径,仅统计主分类工件):TagCountdiscover23data-views21saved-objects8fleet5alerting4siem2license2apm2lens2dark-mode1slow-dashboard1security-app1标签分布传递两个信号:其一,discover与data-views几乎并列第一,说明数据视图问题最终都在 Discover 查询路径上爆出来;其二,fleet、alerting、siem等出现,印证了 index pattern 是底座型概念——安全与告警应用的用户一旦视图配置出错,会以这些应用为上下文来抱怨,因此该分类天然是跨应用的痛点集散地。结果怎么用:决策规则与诚实的局限语料库 README 给出了明确的使用规则(原文):When a XERJ.ai feature is being designed, the first question to ask is:which category does it serve, and whats in that categorys top 20?If the answer is nothing, the feature is speculative. If the answer is 12 of these 20, its worth shipping.即:设计一个功能时,先问它服务哪个分类、该分类 Top 20 里有多少条与它相关——答案若是零,功能就是臆想;若是20 条里占 12 条,才值得做。就本分类而言,Top 20 中字段/映射刷新、切换与导出数据视图、时间字段三类合计过半,这为任何对标 Kibana 的检索产品的 data view 设计提供了直接的优先级依据。同时必须携带 README Honest limits 一节声明的局限来解读上述结论:情感分类是朴素词表分类器,会混淆讽刺与技术性陈述(the bug is...),绝对计数要谨慎,跨分类的相对排序才是可靠的;分类器是关键词规则而非 LLM,本分类的关键词边界(index pattern、data view、field refresh等)决定了哪些抱怨会被收进来;只采集英文工件,非英文 Reddit/SO 帖子被kibana子串守卫丢弃;GitHub 每仓库受 10K 结果上限(page 100)与 422 提前中断约束,采集是深但不穷尽的。小结:一份可直接引用的痛点清单本文主体文档(05-index-patterns-data-views/README.md)的信息结构可以概括为三句话:451 条主分类反馈中负面占 38.1%;痛点头部被 2014 年提出的 Nested field support(469 分)一骑绝尘地占据;其余高分项集中在切换/导出数据视图、字段刷新与 mapping 缓存、时间字段精度与识别、mapping 冲突与膨胀四个工程化主题。所有条目均可通过 pointers.jsonl 按id回查各来源 enriched.jsonl 的完整正文,整套语料可用 pipeline/ 下的五个 Node 脚本零依赖复现,是以真实用户反馈驱动功能优先级这一产品方法论在仓库中一个完整、可验证的落地样本。赞分享人工智能搜索引擎本地部署后端MCP 服务【免费下载链接】xerjXERJ is the new way for AI to search data. Its autoindex capability activates agents to know your data without the token waste of grep and sed. One command indexes code, docs, logs and PDFs for search, RAG, security audits and agent memory, using 40x fewer tokens than grep. Elasticsearch compatible, so existing clients just work.项目地址https://gitcode.com/GitHub_Trending/xe/xerj点击查看免费下载相关推荐XERJ 用户反馈语料库实战02-discover-and-kql 分类如何量化 Kibana 的 Discover/KQL 痛点XERJ 用户反馈语料库实战02 discover and kql 分类如何量化 Kibana 的 Discover/KQL 痛点 本文以 XERJ 仓库中人工智能搜索引擎本地部署后端MCP 服务XERJ Kibana 反馈语料库01-dashboard-authoring 分类统计页的生成机制与解读方法XERJ Kibana 反馈语料库01 dashboard authoring 分类统计页的生成机制与解读方法 本文以 XERJ 仓库中 user feedb人工智能搜索引擎本地部署后端MCP 服务XERJ rc4 能力自评用真实 Kibana 用户反馈语料打分 107 个痛点与 rc5 路线图XERJ rc4 能力自评用真实 Kibana 用户反馈语料打分 107 个痛点与 rc5 路线图 导读 本文围绕 XERJ 仓库中的内部战略文档 KIBA人工智能搜索引擎本地部署后端MCP 服务上一篇BLS12-381聚合签名在AMA Protocol中的完整应用从交易到共识下一篇免费开源的企业级解决方案Briefing视频聊天平台功能测评创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考