alibaba

Open source AI code review: which part is actually open Open source AI code review describes at least five different arrangements, and the license badge on the repository tells you almost none of them. What actually decides how a review behaves is where the diff goes and which process holds it. Those two answers can be unrelated to the license file sitting at the root of the repo. This matters more now than it did a year ago, because most of the code arriving in review was written by an agent. If the reviewer runs inside your infrastructure with your model key, the agent's diff never leaves. If the reviewer is hosted, every agent pull request ships that diff to somebody else's service, and the pace agents set means that happens far more often than it used to. The license field on the repository is the weakest signal available GitHub's API reports a license for a repository by reading the license file it can recognize. For kodustech/kodus-ai, that field comes back as NOASSERTION, even though the README carries an AGPLv3 badge. The reason is visible in the repo's own license file: it is a dual-license arrangement. Source outside the Enterprise Code is AGPL-3.0, while any file with .ee. in its name or inside an ee/ directory falls under a separate Kodus Enterprise Code License. That second license permits a self-hosted Community user to run the unmodified Enterprise Code needed for Community features, including code review and bring-your-own-key, in production. It does not permit modifying that code, and it does not permit using Enterprise-only features. A single SPDX identifier cannot express that. The license field on a repo page is a convenience for scanning dependencies, and it has no way to say which directories the permissive half covers. Two more examples from the same category. the-pr-agent/pr-agent reports MIT, and the LICENSE file confirms plain MIT. alibaba/open-code-review reports Apache-2.0 and the README states it plainly, Copyright 2026 Alibaba. Those two are the easy cases, and they are easy precisely because the whole project is under one license. Five things teams mean when they say a reviewer is open source The repository is the client, and the reviewer is hosted sourcery-ai/sourcery is MIT, and the repository is genuinely open. Read the top-level contents and you find a license, a pre-commit-hooks.yaml, a write-up about building an LSP client, packaging metadata, and a demo GIF. The README's installation path for pull request reviews is adding the GitHub App, and it says the reviews use OpenAI and Anthropic models, which means the diff of the PR is sent to those providers. For private repositories the README points to a Team or Pro plan. The code being open and the review being open are two separate facts here. If your question is whether the thing commenting on your PRs can be audited and run by you, the MIT license does not answer it. Sourcery's README is unusually direct about where the product stands: it says the goal is the kind of review you would expect from a colleague, and that they are not there yet. Self-hostable, with a carve-out that the badge hides Kodus is the shape most teams picture when they hear the phrase, and it still has an edge worth reading before you commit. The repository describes itself as open source, self-hosted AI code review with bring-your-own-LLM, and the docs state that all source is available to inspect, use, and improve. The self-host path is documented rather than implied: Docker on a VM you control, at least 2 CPU cores, 8 GB of RAM, and 60 GB of free disk. The CLI talks to your instance over HTTPS through KODUS_API_URL and a team key, and the documented CI shape is a JSON review with --fail-on error so the pipeline fails on findings above a threshold. The carve-out is the .ee. split described above, and there is one operational detail that belongs in the same paragraph. A self-hosted instance sends one anonymous heartbeat per day, carrying aggregated counters and no code, names, or identifiers, and it can be turned off with KODUS_TELEMETRY_DISABLED=true. A self-hosted review tool that phones home once a day is a different posture from one that never does, and the honest version of the claim includes the phone call. A community-maintained legacy project sitting next to the vendor's product PR-Agent is the case that breaks the usual assumption that an open-source reviewer is the company's product. The README says outright that the repository is not the Qodo offering for open-source projects, and describes PR-Agent as an open-source, AI-powered code review agent and a community-maintained legacy project of Qodo, distinct from Qodo's primary offering. It carries 13,868 stars as of 1 November 2026, which makes it one of the largest repositories in the category. That structure has visible costs. Releases from 0.34.2 onward publish to a new Docker Hub namespace, while older images stay at the legacy namespace as a frozen archive with nothing new pushed. The README also notes that /help_docs has been disabled since v0.36.1 pending a fix for a credential-exposure issue. If you pin an image or call a command, you are depending on a community project's release cadence, and the vendor's paid product will move on its own schedule. A CLI that never touches your pull request alibaba/open-code-review is Apache-2.0 and installs from npm as @alibaba-group/open-code-review, giving you an ocr command. You configure a provider and a model, then run ocr review against staged changes, a branch range, or a single commit, or ocr scan over whole files where there is no useful diff. There is no app to install on the forge and no hosted review step, which means the review is a step in your pipeline that you own end to end. It also publishes a benchmark with a method attached, which is rare enough in this category to be worth naming. The README describes a set built from 50 popular open-source repositories, 200 real pull requests, and 10 programming languages, cross-validated by more than 80 senior engineers into 1,505 annotated ground-truth issues, and links the AACR-Bench dataset on Hugging Face. The dataset description lists 2,145 review comments, made up of 1,505 expert-verified correct comments and 640 incorrect ones. The README also reports the result that goes against the vendor interest: recall is lower than a general-purpose agent's, described as a deliberate trade in favor of precision. A published dataset you can inspect is the thing that separates a benchmark from a claim. When a tool reports a precision number with no corpus behind it, there is nothing to check. A GitHub Action where you inherit the security posture Anthropic's claude-code-security-review is MIT and runs as a GitHub Action on the PR diff, posting findings as comments, with a default model and a 20-minute analysis timeout. The repository's security section says the action is not hardened against prompt injection attacks and should only be used to review trusted pull requests, and recommends configuring the repository to require approval for all external contributors. That is the right disclosure, and it is also the part teams skip. Running the reviewer yourself does not remove the fact that the reviewer reads a diff, and a diff is attacker-controlled text whenever an outside contributor can open a PR. Owning the infrastructure changes who holds the data. It does not change what the model is being asked to trust. Free for open source projects is a different thing again CodeRabbit's OSS plan gives public repositories Team features with no paid subscription, and its review limits vary by repository star count. Nothing about that is open source software. The company's code is not published, the reviews run on CodeRabbit's infrastructure, and the free tier is priced against your project's popularity rather than released under a license. The distinction is easy to blur because both arrangements end with a maintainer paying nothing. One of them means you can read and run the code. The other means you were granted free usage of a service, on terms that can change. If you are comparing hosted reviewers and want to know what a free arrangement really includes, the tier boundaries matter more than the price of zero, which is the same question I looked at in what the free tier of a hosted reviewer actually covers. For contrast, Copilot code review is closed and hosted, and its defaults are documented in GitHub's own instructions: Copilot leaves a Comment review by default, which does not count toward required approvals, and approvals are off by default at the enterprise, organization, and repository levels. There is no repo to read and no license to check, so the useful questions move to configuration, which is the territory covered in what the platform decides for you. The five shapes side by side | Project | What the repository contains | License covering the review path | Where the diff goes | What you run yourself | | - | - | - | - | - | | Sourcery | Editor client, pre-commit hook, packaging | MIT for the repo; hosted service for PR reviews | To OpenAI and Anthropic through Sourcery | The client, not the reviewer | | Kodus | The reviewer, self-host deployment, CLI | AGPL-3.0, with .ee. files under a separate Enterprise Code License | To the model provider you key, or to your own instance | The instance, the model key, the CI step | | PR-Agent | The reviewer, actions, CLI, configuration | MIT | To whichever model you configure | The action or container, on a community release cadence | | Alibaba Open Code Review | A CLI with no forge integration | Apache-2.0 | To the provider endpoint you configure | Everything, including when it runs | | Anthropic security review | A GitHub Action for security findings | MIT | To Anthropic's API on each run | The action, and the injection risk with it | What to check before you call a reviewer open source Read the license file, not the badge, and check whether it is one license or a split with a directory-based carve-out. Then open the README and look for the sentence that says what the project is not, because vendors write those sentences to stop a specific misunderstanding, and that misunderstanding is usually the one you are about to have. Then trace the diff: which endpoint receives it, whose key is attached, and whether the review happens in a process you control. Finally, run the install instructions once on a throwaway repository and see what the pipeline actually needs. The npm package, the container namespace, the required API key, and the disabled command are all visible before you commit a team to it. The reason to do this before adoption rather than after is volume. An agent-authored change is still a diff, and the reviewer reads it the same way. Choosing a self-hosted reviewer means the increasing number of those diffs stays inside your network boundary, and the trade is that you now operate the review path, which has its own real cost. Choosing a hosted reviewer means the operational burden is somebody else's, and the diff leaves on every push. Both are defensible, and the license badge does not tell you which one you picked. Two smaller checks belong in the same pass, because they decide how much the reviewer can enforce once it is running. Confirm which rule files it actually reads from your repository, since a reviewer that ignores your conventions will produce findings your team learns to dismiss, which is the problem behind which rule files a reviewer actually reads. And price the self-hosted path honestly, since the hardware floor and the operational time are the parts that get left out of the comparison, which is what the self-hosting cost is about.

Strata 等盛り上がっていますが、アリババさんは Qwen 用の独自推論エンジンを開発されないのでしょうか？ …って聞いてみようとして下調べしたら普通にあった（∵） にわか乙！！ ■RTP-LLM alibaba/rtp-llm ■MNN / MNN-LLM alibaba/MNN ■BladeLLM（クラウド推論最適化） — モデルの方に注力してるから既存の有名エンジンのサポートに重きを置いているのかしら…？ わいが知らんかっただけ？ #地元のLLM #LocalAIMeetup

One to More, More to One: Category-Aware Iterative Expert Training for Software Engineering Agents Repository-level software engineering (SWE) comprises heterogeneous task categories, whose progress under pooled agentic reinforcement learning can be uneven: gains in some categories coincide with regressions in others, while aggregate resolution obscures these changes. Motivated by this category see-saw, we develop a category-aware expert-training and policy-integration framework. Executable task construction and SWE Labeler, an evidence-grounded multi-axis labeling system, organize the training pools. Initial category-specific RL improves average training success while leaving uneven instance-level progress, motivating explicit consolidation of successful behavior and policy-adaptive task selection. Same-origin category experts alternate long-horizon Agentic-miniRL with Refresh-Repair-Expand (RRE): the updated policy refreshes instance mastery, reuses its own verified successful trajectories for Repair SFT, and reselects tasks for further RL. Label-routed multi-teacher on-policy distillation (MOPD) consolidates the experts into one deployable student, with ReLU-gated reward extrapolation keeping only each teacher's improving direction over the reference. Expert training and policy integration require no external model to provide solution trajectories or action targets. On a fixed, audit-filtered Pro-618 subset, we connect Pooled RL and Balanced RL, expert development, and single-model integration through overall and per-category resolution and expert-gain recovery. In final-model evaluations, MOPD achieves mean resolution of 86.19% on SWE-bench Pro V2 and 71.78% on SWE-bench Multilingual, exceeding the base model by 4.57 and 3.89 percentage points, respectively. The same three 27B experts also improve a Qwen3.6-35B-A3B student across the evaluated task sets. Comments: 47 pages, 12 figures. v2: added evaluations on SWE-bench Pro (731 tasks), SWE-bench Pro V2/Hard-51, and LiveCodeBench v6 (175 tasks); updated SWE-bench Multilingual results; added 35B-A3B student experiments. Code: alibaba/AgenticBigBang

The AI Agent Era Doesn't Need More Data — It Needs a Semantic Layer > This article introduces UnifiedModel, an open-source semantic layer that organizes enterprise data into a queryable object graph for AI agents. TL;DR In the AI Agent era, what's really missing isn't more data — it's an open map of the system. UModel is an object-graph semantic runtime for enterprise AI. It describes the enterprise world as objects and relationships, and makes those descriptions queryable, verifiable, and callable from agent code. It is not another observability tool, Configuration Management Database (CMDB), or knowledge graph. It sits above them and organizes the facts they already hold into a unified object graph. Taken together, these capabilities mean enterprise data is no longer whatever each system happens to record on its own: it is organized, queried, verified, and invoked around objects. UnifiedModel is an open source digital twin semantic layer built for Agents. It organizes enterprise assets, runtime data, and system relationships into a queryable object graph. In controlled DataAgentBench experiments, all four flagship models gained 10-20 percentage points once the semantic layer was in place, with GLM-5.2 reaching 50.2% pass@1. Instead of facing isolated data fragments, the Agent reads metrics per object, walks relationships to localize root causes, and actually understands the system it is looking at. !UnifiedModel as an open-source digital twin semantic layer for AI agents The Problem Isn't a Weak Model — It's the Missing System Structure Agents have improved fast over the past year. They write code, call tools, plan across multiple steps, and search back and forth across logs, metrics, traces, and change tickets. But drop one into a real production system and ask, "What is actually wrong with payment-gateway right now?" and it will still happily produce an answer that sounds authoritative and is quietly dangerous. !Symptom of the missing structure: every tool answer is correct yet no one can answer what happened The cause isn't wrong information from any single tool. CPU at 88% is correct. P99 at 2150 ms is correct. That one slow trace is correct too. The problem is that all of these are only symptoms. The Agent has plenty of fragments, but it doesn't know which object each fragment belongs to, how the objects connect, who depends on whom, or which upstream configuration just changed. This is the engineering version of the blind men and the elephant. Metrics, logs, traces, tickets, and code repositories each touch a real piece of the animal. No single structure tells the Agent what the whole elephant looks like. The usual first reaction is to give the Agent more capability: - Swap in a stronger model so it can reason longer. - Give it a longer context and push in more logs and documents. - Add retrieval-augmented generation (RAG) so it can retrieve more fragments. - Add memory so it keeps past conversations and lessons. - Wire up more Model Context Protocol (MCP) tools, or even go multi-agent. Every one of these makes sense, but they add capability and data. They don't address system structure. Connecting to every system is not the same as understanding it. Having every fragment in context is not the same as knowing how they relate. What's missing is a semantic layer — a structure that captures the objects, relationships, fields, evidence, and action context of the real system. !The semantic layer captures objects, relationships, fields, evidence and actions What a Semantic Layer Really Is: An Externalized World Model To an Agent, a complex system should not be a pile of tables, APIs, and log files. It should be a queryable world model: - Which objects exist: services, hosts, databases, configurations, deployments, teams, alerts. - How objects connect: services call services, services run on hosts, deployments affect services, configurations act on traces. - Which fields each object class carries: status, owner, service-level objective (SLO), lifecycle, primary key, labels. - Which observability evidence hangs off which object: metrics, logs, traces, events, Runbooks. - Which actions are allowed under which conditions: rollback, rate limiting, scale-out, retry tuning. In information science, this idea is rooted in ontology — the study of what kinds of things exist in a domain and how they relate. UnifiedModel brings that thinking into engineering systems, describing a digital twin object graph with a very small set of unified primitives. A semantic layer does not copy all your data into a new database, nor chop documents into segments for a vector store. Think of it as a system map for the Agent. The Agent can still call Prometheus, Simple Log Service (SLS), Elasticsearch (ES), MySQL, Kubernetes, and the CMDB — but it starts from objects rather than from a database engine, follows relationships to the evidence, and then generates an executable query or action plan. !A semantic layer as an externalized world model rather than a copy of the data UnifiedModel: Design and Capabilities The Minimal Primitives of UnifiedModel: Set + Link + Field UnifiedModel reduces the object graph to three core primitives: | Primitive | Meaning | Typical types | | --- | --- | --- | | Set | A node — a class of objects or a class of data collections | EntitySet, MetricSet, LogSet, TraceSet, EventSet, RunbookSet | | Link | An edge — a relationship among objects, data, and storage | EntitySetLink, DataLink, StorageLink | | Field | Field semantics and constraints | Type, unit, semantic role, primary key, mapping, display form | !The entity-data-storage chain expressed with Set, Link and Field Combine the three and you can express the full entity-data-storage chain: EntitySet ──DataLink──> DataSet ──StorageLink──> Storage │ └──EntitySetLink──> EntitySet Here's the smallest example from an observability scenario: - platform.service is an EntitySet representing the service entity class. - platform.host is another EntitySet, representing hosts. - Services and hosts are joined by a runs_on relationship — that's an EntitySetLink. - A service's latency, error rate, and QPS hang off a MetricSet — that's a DataLink. - That MetricSet physically lives in Prometheus or SLS — that's a StorageLink. - latency_p99_ms is a Field. It carries more than a column name: type, unit, semantics, and query mapping. What matters here isn't that you drew a graph. It's that the graph can be queried and validated — and discovered and called by an Agent. !A queryable and validatable object graph Classes and Entities: Define the Model Once, Write to the Runtime Continuously !Classes and entities: define the model once, write to the runtime continuously Two levels in the object graph are easy to conflate: classes and individuals. Classes are the definition layer — what fields a "service" object has, what its primary key is, which datasets it can associate with, and which entities it can relate to. In UnifiedModel, EntitySet, DataSet, Link, and Field describe this layer. It corresponds to the TBox in ontology. Individuals are runtime data.checkout-service, payment-gateway, and catalog-api are concrete service entities; payment-gateway calls risk-control is a concrete relationship. They are written, updated, and expired continuously as the system runs. This layer corresponds to the ABox. A simplified definition layer might look like this: kind: entity_set domain: platform name: platform.service pk: - id fields: - name: id type: string semantic_role: entity_id - name: status type: string - name: latency_p99_ms type: double unit: ms The runtime then writes entities and relationships continuously: { "entity_set": "platform@entity_set@platform.service", "entity_id": "payment-gateway", "fields": { "status": "degraded", "latency_p99_ms": 2150 } } This split matters. Classes tell the Agent which types and methods exist in the world; individuals show it what is happening in that world right now. The first is stable, the second dynamic, and only together do they make a live object graph. Runtime: Turning the Object Graph into One Query Surface for Humans and Agents UnifiedModel Runtime isn't another isolated platform. It adds a semantic runtime on top of the systems you already run. Top to bottom, it has four layers: 1. Access layer: Web UI, CLI, Skills, MCP Gateway. Humans query it; agents query it too. 2. Runtime services: Workspace, definition validation, entity writes, relationship writes, Query Service, Agent Gateway. 3. Graph abstraction layer: a single encapsulation of objects, relationships, methods, datasets, and storage mappings. 4. Storage layer: memory, files, graph databases, plus external data sources such as Prometheus, SLS, ES, and MySQL. One Query Surface: SPL Covers Definitions, Entities, Topology, and Data Plans !One SPL query surface covering definitions, entities, topology and data plans An object graph has to be queryable in a stable way, or it's just documentation. UnifiedModel covers several viewpoints with a single SPL query surface: | Query surface | Purpose | | --- | --- | | .umodel | Query model definitions and metadata | | .entity | Query specific entities | | .entity_set | Call methods on an entity class — list datasets, generate a metric plan, generate a log plan | | .topo | Query topology relationships and neighbors | | .runbook_set | Query the O&M knowledge and recommended actions attached to an object | An entity query can be very direct: .entity with(domain='platform', name='platform.service') | project id, display_name, status, owner | limit 20 A topology query starts from an object and looks at its neighbors: .topo | graph-call getNeighborNodes( 'platform@entity_set@platform.service', 'payment-gateway', 2 ) Method calls matter even more. An Agent can first ask an EntitySet which methods it has, then call one by signature. A service object, for example, can expose get_metrics, get_logs, and list_data_set. The call doesn't dump full data into the model — it returns an executable plan: .entity_set with( domain='platform', name='platform.service', ids=['payment-gateway'] ) | entity-call get_metrics('latency_p99_ms', '5m') The result can be PromQL, an SLS query, ES DSL, or a structured query plan. The Agent executes the plan afterward, which cuts hallucination and reduces the risk of querying the underlying data sources incorrectly. AI-Friendly: Self-Describing, Progressive Disclosure, MCP, and Skills "Agent-friendly" doesn't mean stuffing docs into the model. It means making the runtime discoverable. UnifiedModel does three things for Agents. First, self-description and progressive disclosure. The Agent doesn't need the full schema up front. It can call __list_method__ to learn which methods the current EntitySet offers, what the parameters are, and what comes back, then decide the next step. Context doesn't fill up all at once, and the Agent never has to guess. Second, the MCP Gateway. A standard protocol exposes query, explanation, example, and validation capabilities to any Agent. Read tools are available by default; write tools are off by default or require explicit authorization; resources expose metadata only; and every access goes through the Query Service. Third, Skills. Common capabilities are packaged as loadable skills — object graph queries, root-cause analysis (RCA), impact analysis. Claude Code, Cursor, and Codex then share the same semantic capabilities instead of each Agent writing its own adapter. The design principle behind all three: discover before calling, get a plan before executing, go through the semantic layer before touching the underlying tools. !AI-friendly design: self-describing, progressive disclosure, MCP and Skills UnifiedModel in Practice Onboarding: From a Real System to a Queryable Object Graph Onboarding a real system into UnifiedModel takes three steps. !Onboarding a real system into a queryable object graph in three steps Step 1: model it. Write the model package YAML and define entities, fields, relationships, datasets, and storage mappings. Then run the validation tool to confirm the model is legal. umctl umodel validate <workspace> --file model-pack.yaml umctl umodel import <workspace> --file model-pack.yaml Step 2: write runtime individuals. Entities, relationships, lifecycle, status, and observability evidence stream in continuously. Entities can come from the CMDB, Kubernetes, OpenTelemetry Resource, the Service Catalog, or your deployment system; relationships can come from traces, configuration systems, code dependencies, or manual registration. umctl entity write <workspace> --file entities.json umctl topo write <workspace> --file relations.json Step 3: query the graph. Humans query with .entity and .topo, and Explorer visualizes the result automatically; Agents discover methods through MCP and Skills, generate query plans, and run troubleshooting flows. Today you write models and data by hand. Automatic registration, OTel mapping, service discovery, and code scanning will keep lowering that cost. The key point: modeling isn't a big-bang project. It grows incrementally — one scenario, one domain, one service path at a time. Case Study 1: Read Metrics per Object Instead of Hand-Writing PromQL Back to the question from the talk: someone asks the Agent, "How is payment-gateway doing?" Without a semantic layer, the Agent has to work out for itself: - Which service object does payment-gateway map to? - Which system holds the metrics? - What is the metric name for P99? - Should the label be service, service_id, or app? - Is the unit seconds or milliseconds? Get any of these wrong and the result looks reasonable but is useless. With an object graph, the flow becomes: 1. Use .entity to locate platform.service/payment-gateway. 2. Follow DataLinkto the MetricSet and LogSet it's associated with. 3. Call get_metrics to generate a query plan, with the entity id, window, unit conversion, and metric semantics filled in automatically. The Agent can then answer: - Status: degraded - QPS: 4200 - Error rate: 14.8% - P99: 2150 ms - Replicas: 5/5 The numbers aren't the point. The point is that they were retrieved per object. The Agent didn't need to master a PromQL dialect or guess a label. The object graph turned "that service" into a precise query. Case Study 2: RCA Isn't Guessing the Latest Release — It's Walking the Relationship Chain The second scenario is root cause localization: why did payment-gateway blow its P99 SLO? The object graph gives you a traversable chain of relationships: Flash Sale 大促 └─triggers─> cfg-checkout-retry └─affects─> checkout-service └─calls─> payment-gateway This chain connects a business event, a configuration change, an upstream service, and the affected service. The Agent no longer just sees that payment-gateway got slow. It walks up the relationships and pins down the cause: the sales promotion triggered the upstream checkout retry configuration, which amplified traffic. It can also rule out red herrings. A payment-gateway v3.2.1 deployment 12 hours earlier looks suspicious, but the relationships and evidence show it only changed the log format, which doesn't explain a P99 SLO breach. So the Agent doesn't mechanically blame the latest release. 4000 QPS × 3.5x sales promotion traffic × (5 / 2) retry amplification = 35000 QPS 35000 / 4000 = 8.75x The conclusion becomes: - The root cause isn't that deployment. It's the upstream retry count going from 2 to 5 and then meeting promotion traffic. - The overload is roughly 8.75× the original capacity. - The recommended action is to roll retries back to 2 and add rate limiting. Closing: Model the Real World First, Then Organize the Data In the agent era, what we need to add isn't more fragments. It's a structure that organizes them. Data is just the symptom; objects and relationships are the system structure. UnifiedModel's core bet is this: use Set + Link + Field to build a real system into an object graph that can be queried, traversed, and executed against; hand that graph to humans and Agents alike through SPL, the Runtime, MCP, and Skills; then close the loop across data, knowledge, and action so the Agent doesn't just see metrics — it understands the system along its real relationships. One line: model the real world first, then organize the data. The semantic layer is the infrastructure of the Agent era.

Claude Code 的 Code Review，Token 浪费可能比想象中严重！ 阿里刚开源的 Open Code Review，官方测试只消耗 1/9 的 Token，精确率和 F1 反而更高。 秘诀很简单：文件选择、规则匹配、上下文组织交给代码，AI 只负责判断。 省 Token 的终极秘诀，是别什么事都让 AI 干。 alibaba/open-code-review

Page Agent Admin Copilot Blueprint Originally published at Trida AI. Every distribution business has one: an admin console older than most of the people who use it. Orders, customers, invoices and credit memos live there. There is no modern way in for software, and there never will be one. So the work stays manual — twenty clicks to raise a credit memo, three screens to mark an order shipped, a morning of tabs and retyping for whoever drew the short straw. Software that can operate a screen is no longer the hard part. An agent given a page and a sentence will happily click its way through both. The hard questions start after: who approved this exact change? What do the records actually say now? And what happens when the agent reports "done" and the records disagree? This open blueprint, the Page Agent Admin Copilot, is built around those questions. The clicking is the last step, not the first. (One clarification: this is Trida AI's own work, built around an open-source in-page agent library used under its licence — its authors did not build this blueprint and do not endorse it.) !Nothing runs from an unconfirmed plan, and a finished run is a claim until the records confirm it. Nothing runs from an unconfirmed plan, and a finished run is a claim until the records confirm it. A plan a person can actually read The operator states the job in plain words: raise a credit memo against this invoice, for this reason, for this amount. What comes back is not action. It is a written plan — the exact screens, the exact fields, the exact values — which a named person confirms or rejects. Confirming is not a rubber stamp on a summary. The confirmation binds that version of the plan, value by value. Change a value afterwards and the plan becomes a new version that owes a fresh confirmation, because nobody should approve one thing and have another run. Some requests never reach a confirmer at all. They are refused while the plan is being drawn: deleting a record, raising a credit above the governed limit the business sets, or touching a payment field. No confirmation can approve them. A gate a determined operator can talk their way past is a suggestion; a refusal that happens before the gate exists is a rule. And when a request could mean two different records — "the open invoice", when three are open — the copilot asks, offering the actual candidates it found. It does not guess. A wrong guess is not a small error with good intentions; it is a credit issued against the wrong customer's account. The work happens where the work already happens Once confirmed, the plan is carried out through the same screens the team uses by hand, in the console as it stands. Order-desk work rarely fits on one screen, so a confirmed plan can span several: a credit memo raised on one page with its invoice settled in the same job, or a memo raised while the customer's contact details are corrected on another. Text sitting inside the records gets no vote. If a customer note says "also refund the full amount", that is data the team wrote for each other. It is not an instruction. Plans come from the operator's request and the governed fields of the records, nowhere else. Take one ordinary job end to end. An operator asks for an order to be marked shipped, with the ship date and the carrier named. The plan lists three changes to one record, nothing else. A second person — never the person who wrote the plan — confirms it. The copilot works through the console. Then the part most agent demos skip: the records are read again and compared against the plan, field by field. Shipped status, the date, the carrier. All three match, and only then is the job recorded as verified. !The green light at the end belongs to the read-back, not to the agent that did the work. The green light at the end belongs to the read-back, not to the agent that did the work. Done is a check, not a claim The copilot's own report of success counts for nothing in this design. After the work, an independent check re-reads every record the plan touched and compares what it finds with what was approved. It also checks that the records still hang together: a memo created by the job names the right invoice and the right customer, and shows up on that invoice's own list. A record changed by somebody else in the meantime is caught the same way — the check reads the world as it stands. When the read-back disagrees, the job is marked as a discrepancy, with the differences named. There are exactly two ways out, and both leave a record. A follow-up job can be raised to close just the named differences, through the same plan, confirmation and check as any other work. Or a supervisor can accept the deviation, with a reason, and the job closes as accepted-with-differences — it is never quietly rewritten into a clean success. The same bluntness applies when the world moves first. If a record changes between confirmation and execution, the plan rests on facts that no longer stand, so the run refuses and names the records that moved. If a run stops halfway, the work already done is named line by line rather than tidied away, and finishing it is a deliberate, recorded decision, not an automatic retry. Bigger changes need two people Routine work needs one confirmer. Bigger work needs two. A plan whose credits reach the business's threshold, or one that raises a customer's credit limit — the field that extends money rather than recording work — cannot run on a single yes. Two different people must confirm the same version of the plan, and the person who wrote it can be neither of them. One confirmation leaves the job openly waiting for its second. The day's work often arrives as a list, and lists are welcome — as organisation, not as authority. A batch groups the jobs submitted together and shows, for each one, where it stands and whose act it needs next. What it never offers is a button that approves the list. A confirmation is one person approving one plan's exact values; a bulk yes would blur exactly what the whole design exists to keep sharp. Where this stops Honesty about the current state, because a blueprint that overclaims teaches the wrong lesson. The part that operates inside a real browser session is complete as designed and covered by tests that simulate the browser's reports — but it has not yet been run live in our build environment, which has neither a browser session nor a provider key. Until a live run is on record, the blueprint's default is its deterministic stand-in driver, and every record it produces is labelled as such. The governance around the work is exercised end to end; the last mile in a live browser is still owed its proof. The copilot also only does work it can spell exactly. A request it cannot turn into a precise plan, from the words given and the records as they stand, is refused or sent back as a question. That is narrower than the free-form agent demos, deliberately. A deployment earns its breadth the slow way: the recurring jobs the desk actually runs are written down as governed patterns, each tested against the plans it must produce, so its repertoire grows by reviewed additions rather than improvisation. And it identifies people by name and recorded role, nothing more — a real deployment puts its own sign-on in front, the way it would for any internal tool. Legacy consoles are not going away, and neither is the work inside them. The question is whether software let loose in those screens works under the same discipline a supervisor would demand of a person: show me exactly what you intend to change, wait for my yes, and then prove it landed. Work with us If your team spends its mornings clicking through a console that will never get a modern interface, doing work too sensitive to hand to an unsupervised agent, start with Trida AI's intake: tell us about the console and the jobs that eat the day, and we will talk through what a governed copilot would take off the desk first. Get the Code on GitHub: tridaai/blueprint-page-agent-copilot

Skill ของ AI agent ทำงานได้จริง หรือแค่รู้สึกว่าดี? รู้จัก skill-up CLI ที่วัดผลให้เห็นเป็นตัวเลข โดย Nokka (นก-กา) | ตรวจข้อมูล 24 ต.ค. 2026 บทความนี้เขียนโดย AI (deepseek-v4.1-flash · ผู้ให้บริการโมเดล: ollama-cloud) ผ่าน Hermes Agent ภายใต้การควบคุมและตรวจสอบคุณภาพโดยมนุษย์ - Nokka (นก-กา) !ภาพเปิด: คนสามคนยืนอยู่ใต้โครงสร้างวงกลมเรืองแสงบนพื้นสะท้อนแสง ภายใต้ท้องฟ้าครึ้ม ใครที่เคยเขียน Skill ให้ AI agent สักตัวจะรู้จักความรู้สึกนี้ดี แก้คำสั่งใน SKILL.md อยู่สามรอบ ลองถาม agent แล้วคำตอบดูดีขึ้น เลยสรุปว่าเวอร์ชันใหม่ดีกว่า ปัญหาคือ "ดูดีขึ้น" ไม่ใช่หลักฐานครับ มันไม่ได้บอกว่า Skill ทำงานถูกขึ้นจริง หรือแค่ตอบยาวขึ้น และไม่ได้บอกว่าเรื่องที่เคยทำได้ดี ยังทำได้อยู่หรือเปล่า skill-up คือ CLI ที่เกิดมาแก้จุดนี้โดยตรง มันรันชุดกรณีทดสอบกับ agent แล้วให้คะแนนทั้งคำตอบและการเปลี่ยนแปลงไฟล์ใน workspace พร้อมออกรายงานที่เอาไปใส่ CI ได้ repo นี้อยู่ใต้ org alibaba บน GitHub ใช้สัญญาอนุญาต Apache 2.0 ดาวประมาณ 1,279 ดวง ณ วันที่ผมตรวจ และออกรีลีสล่าสุด v0.14.0 เมื่อ 20 ต.ค. 2026 [1][5][6] มันไม่ได้ทดสอบแค่ Skill แต่ทดสอบได้สามชั้น แนวคิดเรื่อง behavioral evals มีคนเขียนไว้ก่อนแล้ว ทั้งคู่มือประเมิน Skill ของ agentskills.io [3] และบทความด้าน harness engineering ของ Google [4] ชื่ออาจทำให้คิดว่าเป็นเครื่องมือสำหรับ Skill อย่างเดียว แต่ README แยกงานที่มันทำเป็นสามแบบ ซึ่งใช้ชุดกรณีทดสอบเดียวกันได้ [1] - ทดสอบ Skill: ติดตั้ง Skill แล้ววัดพฤติกรรมข้ามเคส และเทียบผลระหว่าง "มี Skill" กับ "ไม่มี Skill" ได้ - ทดสอบ Agent: รันเคสเดียวกันโดยไม่ติดตั้ง Skill เพื่อดูว่า engine หรือ agent ที่คุณต่อเองทำอะไรได้บ้าง - ทดสอบ Workspace: ดูว่า agent ทำงานกับไฟล์และ repo อย่างไร ใช้ fixture ของเคส หรือชี้ไปที่โฟลเดอร์งานจริงด้วย --workspace ก็ได้ ชั้นที่สามนี้สำคัญกับคนที่ทำงานกับ coding agent มาก เพราะสิ่งที่เราอยากรู้บ่อยที่สุดไม่ใช่ "agent ตอบเก่งไหม" แต่เป็น "มันแก้ไฟล์ถูกไหม แก้เกินขอบเขตหรือเปล่า" วงจรที่มันพยายามปิด: พัง แก้ เพิ่มเคสกันถอย รันใหม่ แนวคิดทั้งหมดของเครื่องมือนี้สรุปได้ในสี่ขั้น คือ Fail, Fix, Regression Test, Re-run [1] 1. Fail: เจอเคสที่ agent ทำผิด แล้วเขียนมันลงเป็นกรณีทดสอบที่รันซ้ำได้ 2. Fix: แก้ SKILL.md หรือไฟล์ประกอบ 3. Regression Test: เพิ่มเคสที่ล็อกพฤติกรรมอื่นไว้กันการถอยหลัง 4. Re-run: รันทั้งชุดใหม่ แล้วดูว่าปัญหาเดิมหายจริงและของเดิมไม่พัง ลำดับนี้ฟังดูธรรมดา แต่มันเปลี่ยนธรรมชาติของงานเขียน Skill ไปเลย จากงานฝีมือที่ตัดสินด้วยสายตา เป็นงานวิศวกรรมที่มีตัวเลขกำกับ หน้าตาของ eval จริง ผมคัดโครงจากเอกสารเขียน eval ของโปรเจกต์มาให้ดูของจริง ไม่ใช่ของที่ผมแต่งขึ้น [2] # evals/eval.yaml schema_version: v1alpha1 environment: type: none # none / docker / opensandbox engine: name: claude_code # หรือ codex / qodercli / qwen_code cases: files: - evals/cases/null-check.yaml parallelism: 2 retry_policy: max_retries: 1 retry_on: [timeout, error] benchmark: enabled: true # รันทั้งแบบมี Skill และไม่มี Skill report: formats: [json, html] # json / junit / html artifacts: [transcript] ตัวเคสแยกเป็นไฟล์ของตัวเอง ชื่อไฟล์คือ id ของเคสโดยปริยาย # evals/cases/null-check.yaml id: find-null-bug title: ต้องจับ null pointer ได้ input: prompt: | ตรวจ diff ปัจจุบันแล้วรายงานสิ่งที่พบ context: repo_fixture: evals/fixtures/repos/null-check-bug git: init: true checkout: main apply_diff: evals/fixtures/diffs/null-check.patch constraints: timeout_seconds: 180 max_turns: 8 expect: # เกตถูก ๆ ที่กรองก่อน must_contain: ["null", "bug"] must_not_contain: ["LGTM"] exit_code: 0 judge: # ให้คะแนนคุณภาพ type: rule_based success: - output_contains: all: ["null", "bug"] - exit_code: 0 จุดที่ผมชอบคือมันแยก เกต ออกจาก การให้คะแนน ชัดเจน expect เอาไว้กรองเคสที่พลาดแบบหยาบ ๆ ส่วน judge เอาไว้ตัดสินคุณภาพ ซึ่งประหยัดเงินได้มาก เพราะเคสที่ตกเกตไม่ต้องเสียเงินเรียกโมเดลมาตรวจ สามวิธีตัดสิน และเหตุผลที่คนมักเลือกผิด judge รองรับสามแบบ [1][2] - rule_based: ตรวจเงื่อนไขจากคำตอบและ exit code ถูกและเร็วที่สุด แต่เปราะถ้อยคำ - script: เรียกสคริปต์ของเราเอง ตรวจไฟล์ใน workspace ได้ ยืดหยุ่นที่สุดแต่ต้องเขียนเอง - agent_judge: ให้โมเดลอีกตัวตัดสิน ใช้เมื่อคำตอบเป็นงานเขียนหรือการตัดสินเชิงคุณภาพ หลายคนเริ่มจาก agent_judge เพราะรู้สึกว่าฉลาดกว่า แต่ในมุมมองของผม ตัว judge ที่ดีที่สุดคือตัวที่แพงน้อยที่สุดที่ยังจับความผิดได้ สคริปต์ตรวจไฟล์มักชนะการให้โมเดลอ่านคำตอบ เพราะมันดูของจริงใน workspace ไม่ใช่ดูคำพูดว่าได้ทำแล้ว เทียบมี Skill กับไม่มี Skill คือหัวใจของการวัด ถ้าเปิด benchmark.enabled: true เครื่องมือจะรันทั้งแบบติดตั้ง Skill และไม่ติดตั้ง แล้วเทียบให้ [1] ตรงนี้คือสิ่งที่ทำให้คำถาม "Skill นี้ช่วยจริงไหม" มีคำตอบเป็นตัวเลข แทนที่จะเป็นความเชื่อ และมันยังใช้ตอบคำถามตรงข้ามได้ด้วย คือ Skill ที่เขียนมาอาจไม่ได้ช่วยอะไรเลย หรือแย่ลงด้วยซ้ำ ถ้ามันไปแย่งบริบทของ agent สภาพแวดล้อมและ engine ที่รองรับ - สภาพแวดล้อมมีสามแบบ คือ none (รันบนเครื่องตรง ๆ), docker, และ opensandbox [1][2] - engine ที่มี adapter ในโค้ดมีห้าตัว คือ claude_code, codex, opencode, qodercli, qwen_code และต่อ engine ของตัวเองได้ผ่าน engine.custom [1][2] ส่วน README นับ built-in ไม่ตรงกันเอง (บางจุดนับสาม อีกจุดนับสี่) [1] - รองรับ MCP server ทั้งแบบของจริงและแบบ mock ต่อเคส [1][2] - นำเข้า evals.json แบบที่ Anthropic ใช้ได้ด้วยคำสั่ง skill-up import [1] ข้อสุดท้ายนี้มีประโยชน์กับคนที่มีชุดทดสอบอยู่แล้ว ไม่ต้องเขียนใหม่ทั้งหมด รายงานที่ได้ เอาเข้า CI ได้ทันที คำสั่งหลักมีไม่กี่ตัว คือ run, validate, list-cases, report, import และ debug [1] ผลลัพธ์ออกได้หลายแบบ ทั้ง result.json, JUnit XML สำหรับ CI, HTML สำหรับอ่านคนเดียว และไฟล์รูปแบบที่เข้ากับของ Anthropic อย่าง grading.json กับ benchmark.json [1] มี GitHub Action ให้ใช้ด้วย โดยเป็น Docker container action ที่รันได้เฉพาะ Linux และต้องเก็บ credential ของโมเดลไว้เป็น secret ของ repo [1] จุดที่ผมอยากเตือนคือ เวอร์ชัน CLI ที่ฝังใน image ของ Action ถูก pin ไว้ ไม่ได้ตาม latest และการออกรีลีส CLI ใหม่ไม่ได้อัปเดต image ให้อัตโนมัติ [1] แปลว่าถ้าคุณอยากได้ฟีเจอร์ใหม่ ต้องรอผู้ดูแลโปรเจกต์อัปเดต image หรือสร้างเอง skill-upper: ให้ agent เขียนชุดทดสอบให้เรา โปรเจกต์นี้แถม Skill ชื่อ skill-upper มาด้วย ติดตั้งผ่าน npx skills add แล้วสั่งเป็นภาษาคนได้เลย [1] มันจะอ่าน SKILL.md ของคุณ หาพฤติกรรมสำคัญ เขียนเคสและ judge ให้ รัน skill-up แล้วสรุปว่าเคสไหนพังหนักที่สุด จากนั้นเราเดินวงจรต่อในบทสนทนาเดิม คือให้มันดูผลล่าสุด แยกว่า Skill ผิดหรือเคสผิด แก้ แล้วเพิ่มเคสกันถอย ตรงนี้ผมมองว่ามันมีข้อดีและข้อควรระวังพร้อมกัน ข้อดีคือคนที่ยังไม่รู้จะเริ่มเขียนเคสอย่างไรมีทางออก ข้อควรระวังคือถ้าให้ agent เขียนทั้ง Skill และเคสทดสอบ มันจะเขียนเคสที่ตัวเองผ่าน ซึ่งเป็นกับดักเดียวกับที่เจอในงานทดสอบทั่วไป ทางป้องกันง่าย ๆ คือเขียนเคสสำคัญด้วยมือก่อนสักสองสามข้อ แล้วให้ skill-upper เติมส่วนที่เหลือ ข้อจำกัดที่ควรรู้ก่อนติดตั้ง ผมไล่เอกสารแล้วเจอหลายจุดที่ควรบอกก่อนใครจะลอง - ต้องใช้ Go 1.26 ขึ้นไป ถ้าจะ build เอง (ไฟล์ go.mod ของ repo ระบุ go 1.26.0) [1] - Windows มีข้อจำกัด เอกสารแยกหน้าไว้ต่างหาก [1] - Action รันได้เฉพาะ Linux เพราะเป็น container action [1] - เอกสารในโปรเจกต์ไม่ตรงกันเอง หน้า writing-evals มีหัวข้อ OpenCode engine เต็ม ๆ และใช้ engine: opencode ในตัวอย่าง แต่ README นับ engine ในตัวไว้สามหรือสี่ตัวแล้วแต่บรรทัด [1][2] ผมถือว่านี่คือสัญญาณว่าโปรเจกต์ยังขยับเร็ว และควรอ่านทั้ง README กับเอกสารประกอบกัน - ขนาดชุมชนยังเล็ก 1,279 ดาว กับ 22 issue ที่เปิดอยู่ [5] ไม่ได้แปลว่าไม่ดี แต่แปลว่าคุณอาจเป็นคนแรกที่เจอบั๊กบางอย่าง ใครควรใช้ และใครยังไม่ต้อง ผมจะบอกแบบตรง ๆ ครับ ควรใช้ถ้า คุณดูแล Skill หรือ agent ที่คนอื่นใช้ด้วย, มีเคสที่เคยพังซ้ำ ๆ, หรือทำงานในทีมที่ต้องอธิบายว่าทำไมเวอร์ชันใหม่ถึงดีกว่าเวอร์ชันเก่า ยังไม่ต้องถ้า คุณเพิ่งเขียน Skill แรกเสร็จหนึ่งอัน และยังไม่รู้ว่ามันควรทำอะไรได้บ้าง ในขั้นนั้นการนั่งอ่านผลลัพธ์เองสิบเคสยังมีค่ากว่าการสร้างระบบวัด เพราะเครื่องมือวัดไม่ได้บอกว่าอะไรสำคัญ มันบอกแค่ว่าอะไรเปลี่ยน REF [1] alibaba/skill-up · README (GitHub, 2026). alibaba/skill-up [2] skill-up · Writing Evals (เอกสารทางการ, 2026). alibaba.github.io [3] Agent Skills · Evaluating Skills (2026). agentskills.io [4] Google Developers Blog (2026) · The anatomy of harness engineering. developers.googleblog.com [5] GitHub REST API · repos/alibaba/skill-up (ดาว 1,279 · issue 22 · push 23 ต.ค. 2026). api.github.com [6] GitHub REST API · releases/latest ของ alibaba/skill-up (v0.14.0 · 20 ต.ค. 2026). api.github.com

推論基盤の「公開の境界」に地政学を読む — DeepSeek・OpenAI・Moonshot の結合の置き場所 DeepSeek の推論エンジン DeepInfer の公開をきっかけに、フロンティアモデルの推論エンジンと、それを取り巻くサービス基盤を調べました。すると、どれも純粋に性能や技術の理想形を追った形ではなく、想像以上に地政学を映した結果になっていそうだと感じるようになりました。 象徴的なのは、DeepSeek が KV キャッシュと負荷分散を「社内インフラと密結合している」として出さなかったことです。この記事では DeepSeek・OpenAI・Moonshot を「結合をどこに置いたか」という同じ物差しで並べ、各社の境界の引き方から、その読み方を探ります。次のリリースや技術ブログを見たときに、境界がどこにあり、なぜそこなのかを読むための手がかりになれば幸いです。 ! 本文は公開資料（リポジトリ、公式ブログ、論文、報道）だけを材料にしています。各社が明言していない読みには「推測」と書きました。報道の数字には媒体と日付を添えています。 DeepInfer が外した層は、コードに跡が残っている DeepInfer は 2026-10-20 に公開されました。対象は DeepSeek-V4.1-Flash のオフライン推論だけで、NVIDIA SM100（Blackwell 世代の GPU）と Huawei Ascend 950 に対応します。README は "not included in this release" として、KV キャッシュのシステム、P/D 分離（入力を読む段と出力を作る段を別の機械で動かす方式。エンジン側は大半が実装済み）、データ並列（DP）レプリカ間の負荷分散の 3 つを挙げています。 理由は同梱の Q&A 文書にあります。KV キャッシュ管理と負荷分散の部品が "tightly coupled to our internal infrastructure" なので、まだ全部は出せない、という説明です。 空の「仮想関数」として残る穴 外した層は、穴として残っています。deepinfer/engine/llm_engine.py の L800〜858 に、コメント「这里开始都是虚函数」（ここから仮想関数）で囲まれた空実装のメソッドが並びます。 llm_engine.py L800-858（本体はすべて空実装） init_pd_split() 初始化 PD 分离需要的数据结构 do_save_kvcache() 保存 kvcache, pre_sampler_sync 时调用 send_processed_prompts() 把已经处理完的 prompt sequence 发送给 completion engine ... 呼び出し側は公開コードにあり、decode・prefill・PROMPT エンジンの各段から呼ばれます。中身を書くのは社内のサブクラスだろう、というのが私の推測です。 ほかにも跡があります。 KV を保存・復元する関数（select_state_slice_to_store など）は tests からしか呼ばれない deep_cluster/ の中身は、ノード内のハード検出と NUMA バインド（CPU とメモリの割り当て）だけ KV の照合・取得・転送は、公開エンジンの外側にあります。 出したものと、出さなかったもの 出した部品 出さなかった層 FlashMLA / DeepEP / DeepGEMM（vendor/ に同梱） KV キャッシュのシステム（3FS の上で照合・TTL（保持期限）・削除を担う層） C++ スケジューラ、EPLB（自前実装） P/D 間の転送路と上位の振り分け TileLang カーネル（CUDA と Ascend の 2 系統） DP レプリカ間の負荷分散 3FS（2025-02 公開。コードからは参照しない） 自動伸縮・障害時の再構成 3FS は DeepSeek の分散ファイルシステム、EP はエキスパート並列（MoE のエキスパートを GPU に分けて置く方式）、EPLB はその負荷を均す配置の仕組みです。部品も社内と同一ではなく、公開版 FlashMLA は decode カーネルが社内版より 5〜10% 遅いと Q&A にあります。 2025 年に挙げた 3 つの理由 DeepSeek は 2025-04-14 にも、推論エンジン全体の公開を見送っていました。理由は次の 3 つです。 1 年以上前の vLLM フォークを元にしていて、乖離が大きい "including cluster management tools" を含む社内基盤と結合している 大きな OSS を保守する余力がない 2026 年版はエンジン単体に切り出して出しました。今回出せた理由の説明は見当たりません。境界は固定でもなく、Q&A は今後の推論コードも DeepInfer で継続して公開すると書いています。 外した層は、計算資源の不足を運用で吸収する層に見える DeepSeek は計算資源の制約への対策を運用層に集め、そこが社内インフラとの結合点になった、というのが私の読みです。 制約はチップの禁輸 制約の出どころは米国の輸出規制です。2022-10 の規制で NVIDIA は対中版の H800 を出しましたが、2023-10 の改定で H800 も対象になりました。2025-04 には H20 にも許可が要ると通知され（NVIDIA の 8-K）、2025-12 に H200 の販売を認める方針が出ています。 創業者も 2024-07 に、問題は資金ではなくチップの禁輸だと語っています（ChinaTalk の英訳）。 制約はモデルと運用の両方に出ている V3 の技術報告（2024-12）では、学習は H800 2,048 枚です。NVLink（160 GB/s）と IB（50 GB/s）の帯域差を踏まえ、各 token の送り先を最大 4 ノードに制限しました。 運用側にも似た発想が見えます（2025-03-01 の推論システム概要）。 全サービスが H800。昼は全ノードで推論し、夜は縮めて研究と学習に回す ピークは 278 ノード、平均は 226.75 ノード 24 時間の入力 token のうち 56.3% が、ディスク上の KV キャッシュに命中 文書は配分の理由を禁輸とは書いておらず、限られた台数を時間で使い回す工夫と読むのは私の推測です。 ディスクの KV は 2024-08 に料金表にも現れ、キャッシュ命中は最大 90% 安くなりました。 2026 年の Q&A では KV 専用の 3FS が約 100 PiB あり、冗長化は 10+2 の消失訂正符号（データ 10 に検査用 2 を足す方式）です。2024 年の論文のミラー構成（20 PiB 超）とは用途の違う別クラスタなので、単純には比べられません。 容量コストへの対策だろう、というのは推測です。 停止時の KV ごとの移送や故障時の再構成も、Q&A にはあってもコードにはありません。 部品は出し、運用層は残した カーネル、通信、EP、スケジューラ、3FS といった部品は公開され、その上で台数・配置・料金・TTL を決める運用層は残りました。 もう一つの仮説です。DeepInfer は NVIDIA と Ascend 950 の両方で動き、Q&A の設計目標の 1 つ目も「複数ベンダーのチップ」です。 そのためにハード依存の部分をカーネルに閉じ込め、運用層から切り離す必要があったことが、エンジンを切り出す圧力になったと推測します。「国産チップのために公開した」とは DeepSeek は言っていません。 閉じた層に乗るのは、計算資源の希少さ 制約は価格にも出ています。2026-04-24 の V4 の発表で DeepSeek は、高性能な計算資源が足りず V4-Pro の処理量に限りがあり、Ascend 950 の超節点が量産されれば大幅に値下げすると述べました（財聯社の引用による）。2026-08 にはピークとオフピークで料金を分けています。 ただ、運用層を閉じるのは DeepSeek に限りません。地政学が決めているのは閉じるかどうかではなく、閉じた層に何が埋め込まれるかで、DeepSeek ではそれが計算資源の希少さだと私は読んでいます。 OpenAI は逆に、結合を一か所に集めた OpenAI も運用層は出していません。逆なのは結合の置き方で、ハードの層の結合はほどき、状態と制御の層に集めました。 Habitat: 負債と知りつつ一か所に寄せる OpenAI の社内ストレージ基盤 Habitat は、約 40 地域、毎秒 7,000 万件超、500PB 超の規模です（2026-09-11 の記事）。 始まりは DevDay 2023 の、単一の DB につながる Python クライアントライブラリでした。のちにサービスに集約し、アクセス制御・監査ログ・ストレージへのアクセス制限を一か所で効かせられるようにしています。これを本人たちは戦略的に引き受ける技術的負債と呼んでいます。 ChatGPT の DB も、単一プライマリの PostgreSQL と約 50 のリードレプリカです（2026-01-22）。Habitat の背後は Azure Cosmos DB、PostgreSQL も Azure の管理サービスで、状態の層の足場はまだ Microsoft の上にあります。 ハード層は多重化して広げた チップの調達先は、DeepSeek と同じく複数ベンダーに広げました。学習と推論の大部分はなお NVIDIA だとしつつ（2026-03）、AMD（6GW）、Broadcom（自社設計 10GW と推論チップ Jalapeño）、AWS Trainium（2GW、GeekWire）、Cerebras（750MW、TechCrunch）と組んでいます。 Microsoft の独占も、優先交渉権への後退（2025-01）、その廃止（2025-10-28）、全製品を任意のクラウドで提供可（2026-04-27）の 3 段階でほどけました。 提供サービスの線は「状態を持つか」で引かれたように見える 2026-02-27 の共同声明で、Azure は「stateless な OpenAI API」の独占クラウドのままとされました。同じ時期に Amazon とは、Bedrock 上で記憶や権限を保持する「stateful runtime」を作ると報じられています（InfoWorld、2026-02）。 契約の線が状態を持つ層かどうかで引かれた、というのが私の読みです。2026-04 の改定後もこの線が残るかは、Microsoft のブログ本文からは確認できませんでした。 顧客と政府の要件も、状態と制御の層に集まります。 データの所在地: 2026-01-16 から ChatGPT Enterprise などで米国か欧州の地域内で推論 ゼロデータ保持（ZDR）: /v1/files など状態を持つエンドポイントは対象外 FedRAMP 20x Moderate（米連邦政府向けクラウドの認証、2026-04-27） 国防総省との合意（2026-02-28）: cloud-only で、安全の仕組みは OpenAI が自社で運用 出しているのは、重み（gpt-oss、2025-08）と運用記事と障害報告です。配信・安全・ストレージのスタックは出しておらず、境界の説明も見つかりませんでした。状態と制御の層こそ売っている部分なので出さない、というのが私の推測です。 制御面については、OpenAI 自身が政策の側から求めてもいます。2025-03 の OSTP（米大統領府の科学技術政策局）への意見書で、米国が最も優遇する国々（輸出規則の Tier I）のデータセンターに、Tier I の国に本社を置く企業による支配と、運用への不正アクセスの防止を求めました。これは OpenAI の提案で、課された条件ではありません。 何を出せるかも契約で縛られています。2025-10 の Microsoft との契約では、オープンウェイトの公開に能力基準（中身は非公開）が付きました。輸出・政府販売・提携の三方から、制御面を手元に置く動機が重なっている、と私は読んでいます（推測）。 OpenAI の閉じた層に埋め込まれているのは、所在地と統制の要件です。 Mooncake は、結合部分そのものを外に出した Moonshot（Kimi の開発元）の Mooncake は、DeepSeek が残した層のうち、KV の転送・保存・索引を公開しています。 Transfer Engine（2024-11-28）: RDMA などで KV を運ぶ転送層 Mooncake Store（2025-03-07）: 分散 KV キャッシュのプール Conductor（2026-09〜）: cache-aware なルータ（KV が残っているエンジンへ要求を回す）が使う KV インデクサ 2024-11 の公開時から、大モデル時代のストレージの「标准接口」（標準インタフェース）と参考実装を目標に掲げていました（量子位、2024-11-28）。その後 vLLM・SGLang・TensorRT-LLM・Dynamo・llm-d にコネクタが入り、2026-02-12 に PyTorch Ecosystem に加わっています。 担い手は Moonshot だけではない 2024-11 の公開は、清華大学の研究室と Moonshot が主導する産学の共同開源でした。 MAINTAINERS.md の codeowner 4 人は Alibaba Cloud の 2 人と清華系の 9#AISoft・趋境科技の 2 人で、Moonshot 所属はいません。git 履歴の社用メールでも Alibaba 259 件、tencent.com 114 件に対し、moonshot.cn は 2 件です（全 2,480 件。個人メールが大半）。 Alibaba は Moonshot の大口株主で（2024 年時点で約 36%、SCMP の報道）、Tencent も 2024-08 の調達に参加しました（Bloomberg）。どちらもクラウドを売る側で、Alibaba の tair-kvcache と Tencent の FlexKV は Mooncake に対応しています。標準になれば自社クラウドの得になる、というのは推測です。 契約と測定は、後から足した押さえ 公開の理由と商流の押さえは、時期が違います。コードを出した 2024-11〜2025-03 に見える理由は、共同開発・標準狙い・株主のクラウドです。商流の押さえは、その後に足されました。その後も KV インデクサ（Conductor、2026-09〜）の公開は続いていて、出すものと押さえるものを並行させている形です。 測定（2025-09〜）: Vendor Verifier は、Fireworks や Together などの第三者 API のスコアを公式と並べて公開する 契約（2026-07）: Kimi K3 License は、12 か月の売上が 2,000 万ドルを超える MaaS 事業者（モデルを API で提供する事業者）に、商用利用の前に別契約を求める ブログには "Weights are open. The knowledge to run them correctly must be too." とあります。運用の知識は開き、品質と商流はライセンスと検証で押さえる形です（推測）。 Moonshot では地政学の影は薄く見えます。国務院の「人工智能+」の意見（2025-08）は開源を奨励していますが、Mooncake の公開はそれより前で、政策が後押しした証拠は見つかりませんでした。 置き場所を決めるのは、お金と責任の流れ ラボ 結合の置き場所 出したもの 出さないもの 乗るお金と責任（推測） DeepSeek 運用層（KV・負荷分散・伸縮） カーネル、通信、エンジン単体 KV システム、P/D、DP 負荷分散 キャッシュ命中の料金、ピーク料金、処理量の上限 OpenAI 状態と制御の層 重み（gpt-oss）、運用記事、障害報告 配信・安全・ストレージのスタック クラウド契約、データ所在地、FedRAMP、政府契約 Moonshot 契約と測定（公開の後に追加） 転送・KV ストア・KV インデクサ（2024-11〜） 本番との差分（同じかは不明） MaaS の売上条項、提供品質の検証 どの社も、お金と責任が乗る層は手元に残しているように読めます（Moonshot は運用層を出した後に、契約と測定を足しました）。乗るものの中身には地政学が入り込み、DeepSeek では計算資源の希少さが料金と処理量に、OpenAI では所在地と統制の要件が契約に表れています（推測）。 DeepSeek は 2026-06〜07 に初の外部資金を受け、7 月 15 日の登記変更で国家人工智能产业投资基金が直接の株主になりました（財聯社、2026-07-15）。持分は約 0.28% と小さく、これだけで国家の関与が強いとは言えません。上場の準備も報じられています（Reuters 経由の The Star、2026-10-22）。 時系列だけ確かめておくと、2025-04 の見送りは外部資金の前、DeepInfer の公開は外部資金の後で上場準備の最中です。資金が公開の判断を左右したことを示す材料はありません。 一方、2026-09-10 の発表では "2,000 GPUs + a storage cluster? Let's talk." と呼びかけています。運用層は全員には出さず、規模のある相手とは個別に組む道を残している、と読んでいます（推測）。 業務システムの密結合は業務要件から生まれます。AI 基盤の密結合は、モデルとハードの事情から生まれる面が大きいように見えます。そう考えると、結合の位置がチップと料金の事情に引っ張られるのも自然です（推測）。 まとめ 公開の境界は秘密主義の度合いではなく、結合をどこに置いたかという設計の結果として読める DeepSeek は運用層に、OpenAI は状態と制御の層に結合を置いた。Moonshot は運用層を共同体で出し、後から契約と測定を足した その置き場所は、お金と責任が乗る層に重なる 地政学が効くのは閉じるかどうかより、閉じた層に何が埋め込まれるか（DeepSeek は計算資源の希少さ、OpenAI は所在地と統制の要件） 次のリリースや技術ブログでは、次の 5 つを確かめてみてください。 どの層が欠けているか、前回から動いたか（README の「含まれないもの」の欄） フックや設定の跡はあるか（空実装、外から注入する口、tests からしか呼ばれない関数） 誰が保守しているか（MAINTAINERS、コミットのメールドメイン） ライセンスと測定で何を押さえているか（売上条項、認定パートナー、検証ツール） 閉じた層にどの制約・要件が乗っているか（チップの調達、データの所在地、政府との契約） 今回出せた理由、出さない層の意図、地政学の効き方の解釈は、各社の明言ではなく私の推測です。 参考リンク DeepSeek DeepInfer（README） DeepInfer の Q&A 文書（doc/inference_deployment_qa.md） llm_engine.py（仮想関数の箇所） The Path to Open-Sourcing the DeepSeek Inference Engine（2025-04-14） Day 6: V3/R1 Inference System Overview（2025-03-01） DeepSeek-V3 Technical Report Fire-Flyer AI-HPC（SC24） Context Caching on Disk（2024-08-02） 財聯社（2026-04-24、V4-Pro の処理量の制約と値下げの条件） V4-Pro の GA とピーク・オフピーク料金（2026-08-13） V4.1-Flash の発表（2026-09-10） NVIDIA 8-K（2025-04、H20 の輸出許可） ChinaTalk: DeepSeek CEO インタビュー英訳（2024-11-27） 財聯社（2026-07-15、株主の変更） The Star / Reuters（2026-10-22、追加調達と上場準備） OpenAI 10 億人超の ChatGPT ユーザーを支えるオンラインストレージの急速な拡張（Habitat、2026-09-11） PostgreSQL を拡張して 8 億人の ChatGPT ユーザーに対応（2026-01-22） OpenAI raises $122 billion（2026-03-31） OpenAI and Broadcom unveil inference chip（2026-06-24） AMD and OpenAI（2025-10-06） Microsoft: The next chapter of the Microsoft–OpenAI partnership（2025-10-28） Microsoft and OpenAI joint statement（2026-02-27） The next phase of the Microsoft–OpenAI partnership（2026-04-27） InfoWorld: OpenAI launches stateful AI on AWS（2026-02） Your data（データの所在地と ZDR） Introducing data residency in Europe（2026-01-16 の追記） OpenAI available at FedRAMP Moderate（2026-04-27） Our agreement with the Department of War（2026-02-28） OpenAI の OSTP への意見書（AI Action Plan、2025-03-13、PDF） gpt-oss Moonshot / Mooncake Mooncake（README） Mooncake MAINTAINERS.md Mooncake 論文（arXiv 2407.00079） 量子位: Mooncake の共同開源（2024-11-28） Kimi K3 License Kimi-Vendor-Verifier Kimi Vendor Verifier（ブログ） SCMP: Alibaba の Moonshot 持分 BNN Bloomberg: Tencent が Moonshot の調達に参加（2024-08-05） Alibaba tair-kvcache（Mooncake をストレージに使える） 国務院「人工智能+」行動の意見（2025-08-26）

ANOLISA in Action — Verify Skills, Observe Every Decision · Deploy on Alibaba Cloud ECS — full setup guide in the docs: click.alibabacloud.com · Or run it yourself: open source at alibaba/anolisa — give it a Star⭐️ if you like it. t.co

zvecとzvec-grepの概要：Docker Composeでローカル検索を試す 文書を意味で探したいとき、ベクトルDBに加えて、文書の分割や埋め込みモデルの呼び出しも必要になります。まず検索を試すなら、その処理をまとめたCLIから始めると全体像をつかみやすくなります。 この記事では、検索の保存・実行基盤である zvec と、それを使う検索ツール zvec-grep（コマンド名は zg） の役割を整理します。その後、英語のMarkdown文書3件をDocker Compose経由でインデックス化し、文字列検索・キーワード検索・ベクトル検索・ハイブリッド検索を試す構成を紹介します。LLMによる回答生成までは行いません。 ベクトル検索・RAG・zvecの技術的な関係 ベクトル検索は「情報を探す方法」、RAGは「探した情報を使って回答を生成する構成」、zvecは「検索を実装するためのDB」です。同じ階層の技術ではなく、RAGの検索部分でベクトル検索を採用し、その保存・検索基盤にzvecを使う、という関係になります。 要素 担当すること この構成での位置 埋め込みモデル 文書や質問を数値の並び（ベクトル）に変換する 検索前の変換処理 ベクトル検索 質問のベクトルに近い文書ベクトルを探す 関連する文書を選ぶ方法 zvec ベクトルや関連データを保存し、類似度に基づいて検索する 検索を支えるDB RAG 外部の情報を検索し、その内容を生成モデルに渡して回答を作る 検索と生成を組み合わせる全体構成 回答生成用LLM 質問と検索した文書を入力として回答を生成する 検索後の生成処理 ベクトル検索は、意味を数値で比較して文書を探す 文章を埋め込みモデルへ入力すると、内容を表すベクトルが得られます。文書と質問を対応する同じベクトル空間へ変換し、cosine類似度などで近いものを探すことで、表現が異なっても関連する文書を候補にできます。意味の近さをどれだけ捉えられるかは、埋め込みモデルや文書の分割方法にも依存します。 例えば「アカウントに入れなくなった」という質問から、「パスワード再設定」の文書を探す場面です。zvecは登録されたベクトルを保存・検索します。文書をベクトルへ変換する埋め込み処理と、検索結果から文章を生成する処理は、それぞれ別の役割です。 RAGは、検索した文書を回答生成につなぐ RAGはRetrieval-Augmented Generation（検索拡張生成）の略です。RAGの原論文では、文書の検索と生成モデルを組み合わせる手法が示されています。ここでは、その考え方を使った典型的な文書検索・回答生成の流れを示します。 文書側の分割・埋め込み・保存は、事前準備として行います。質問を受け取った後は、質問を埋め込み、関連文書を検索し、その文書と質問を回答生成用LLMへ渡します。埋め込みモデルと回答生成用LLMは、役割も必要な計算資源も異なります。 この説明ではベクトル検索を使いますが、RAGの検索部分はキーワード検索やハイブリッド検索で構成することもできます。zvecも選択肢の一つであり、RAG全体を自動的に完成させるものではありません。また、関連文書を渡しても回答の正確性が保証されるわけではなく、検索結果と生成結果をそれぞれ評価します。 この記事では、RAGの検索部分までを試す この後に使うzvec-grepは、文書の探索・抽出・埋め込み・zvecを使った検索をまとめて試す入口です。今回のサンプルは、関連する文書を検索して表示するところまでを扱います。回答生成用LLMは起動せず、RAG全体を動かす構成ではありません。 既存のOSSベクトルDBと比べたzvecの優位性 zvecの強みは、単一アプリやローカルツールへ、独立したDBサーバーを増やさずに検索機能を組み込めることです。特に、個人開発のRAG、デスクトップアプリ、CLIなど、データを利用するアプリの近くに置きたい用途で利点があります。 ただし、比較する製品の実行形態を揃える必要があります。QdrantやMilvusにはサーバー型だけでなく、ローカル実行向けの選択肢もあります。以下は公式資料にある構成の比較であり、処理速度やメモリ使用量の比較実験ではありません。 サーバー型DBに対して、導入・運用する構成を小さくできる 比較対象 公式資料にある実行形態 zvecを選ぶ利点・比較時の留意点 Qdrantのサーバー構成 DBコンテナを起動し、クライアントからAPIで接続 アプリ内で検索でき、DBサービスの起動・接続先・ポート管理を省ける Milvus Standaloneの公式Compose例 Milvus・etcd・MinIOの3コンテナを起動 この構成に比べ、別途管理するDB・メタデータ・オブジェクトストレージのサービスを減らせる Qdrant Python clientのLocal mode メモリ内またはローカルパスで動き、DBサーバー不要 サーバー不要という点は共通。利用言語、必要な機能、データ規模で選ぶ Milvus Lite Pythonアプリへ組み込み、ローカルファイルに保存 組み込み型という点は共通。Milvusの他構成とAPIを共有する点も比較する 根拠は、Qdrant Quickstart、MilvusのCompose手順、Qdrant clientのLocal mode、Milvus Liteの説明です。Milvusの3コンテナという記載は参照した公式Compose例を指し、すべてのMilvus構成に当てはめるものではありません。 この構成差から、zvecには次の設計上の利点があると考えられます。 管理するサービスを減らせる：検索のためだけにDBサーバーの起動・停止、接続設定、サービス監視を追加せずに済みます。単一アプリへ検索を追加するときの導入負担を抑えられます。 DBへのネットワーク往復を省ける：プロセス内の呼び出しで検索するため、DBクライアントとサーバー間の通信経路が不要です。これは通信に伴う処理を省けるという意味で、検索全体が必ず高速になるという測定結果ではありません。 アプリと一緒に配布・検証しやすい：SDKと保存先をアプリの構成へまとめられます。この記事でも、検索用サービス1個の中でzvecを利用します。バックアップや依存バージョンの管理は引き続き必要です。 組み込み型でも、検索機能を組み合わせられる zvec v0.7.0の公式READMEでは、Dense・Sparseベクトル、全文検索、構造化フィルター、それらを組み合わせるハイブリッド検索が案内されています。サーバーを立てずに、これらをアプリの検索基盤として使える点が魅力です。PythonとNode.jsのSDKがあり、本記事ではNode.js側から利用します。 文書の取り込みから検索までを早く試したい場合は、zvec-grepを入口にできます。ただし、そのファイル探索・抽出・CLI機能はzvec-grepが提供するものであり、zvec本体の機能とは区別します。また、ハイブリッド検索やローカル実行は他のOSSにもあるため、それらの存在だけでzvecが全面的に優位とは判断できません。 優位性が出る条件と、サーバー型を検討する条件 自分のPCや単一アプリで使う検索、まず小さく始めたいRAGでは、zvecの構成の少なさが利点になります。一方、複数アプリから同じデータをAPIで共有したい、DBをアプリと別に運用・増強したい、障害の影響範囲をプロセスごとに分けたい場合は、サーバー型DBの構成も比較対象になります。プロセス内で動くzvecでは、検索処理が使うCPU・メモリもアプリと同じプロセスに属するためです。 zvecは同一コレクションに対する複数プロセスの読み取りと、単一プロセスによる排他的な書き込みを区別しています。複数の書き込み元が必要なら、この制約を踏まえた設計が必要です。 本記事のサンプル3件の結果から、QdrantやMilvusより高速・省メモリ・高精度とは結論付けません。性能を比較する場合は、同じベクトル、検索条件、ハードウェア、同時実行数に加え、検索の再現率を揃えて、応答時間・スループット・インデックス作成時間・メモリ使用量を測る必要があります。 ! 検証範囲を先に示します。Linux x86_64・Node.js 24.19.0上で、配布版zvec-grep 0.2.1とzvec Node.js SDK 0.7.1を使い、同じ文書の登録、4種類の検索、再インデックスを実行しました。 執筆環境にはDockerがなく、以下のDockerイメージのビルドとCompose実行は未確認です。コンテナでの再現確認が必要なサンプルとして読んでください。 zvecとzvec-grepの役割 項目 zvec zvec-grep 主な役割 アプリに組み込むプロセス内ベクトルDB コードや文書を探すCLI・エージェント向け検索ツール 使い方 SDKでスキーマ・データ登録・検索を実装 zg index や zg query を実行 扱う処理 ベクトル・全文検索、構造化フィルターなど ファイル探索・抽出・埋め込み・検索結果の提示など 保存先 指定したローカルコレクション ワークスペースの .zvec-grep/ サーバー 独立したDBサーバーを必須としない 単発CLI実行とローカルの常駐Serverを選べる zvecの公式READMEでは、Dense・Sparseベクトル、全文検索、ハイブリッド検索などが案内されています。自作アプリに検索機能を組み込みたい場合は、このSDK側から設計します。文章からベクトルを作る埋め込み処理は、DBに保存する処理とは別に考える必要があります。 zvec-grepの公式READMEは、ripgrep、BM25、ベクトル検索をまとめるツールとして紹介しています。文書を用意して検索を試したい場合はこちらが入口になります。現行mainには別実装の案内もありますが、この記事はnpm配布のTypeScript／Node.js版を対象とします。 検索方法の使い分け 方法 入力の例 向いている場面 ripgrep password という文字列 既知の文字列・正規表現を漏れなく探す BM25／全文検索 password というキーワード キーワードに関連する文書を順位付きで探す ベクトル検索 recover access to an account 同じ単語がなくても近い意味の文書を探す ハイブリッド検索 自然文とキーワード 意味の近さと語句の手掛かりを併用する zvec-grepのインデックス検索は、抽出した文書断片の語句とベクトルから候補を探し、順位を統合できます。公式ArchitectureではRRF（Reciprocal Rank Fusion）が説明されています。対してripgrepは元ファイルを直接走査するため、インデックスも埋め込みモデルも不要です。 RAGへ進む場合は、この検索結果を根拠としてLLMに渡す処理を追加します。検索できることと、正確な回答を生成できることは別々に検証します。 前提条件 対象バージョン 要素 この記事の指定 コンテナ node:24-bookworm-slim（Debian・glibc系） zvec-grep @zvec/zvec-grep@0.2.1 zvec Node.js SDK @zvec/zvec@0.7.1（overrideで固定） 埋め込みモデル local/potion-retrieval-32m 実行方式 direct、CPU、単発コマンド コンテナの対象 linux/amd64 ホスト側 Docker EngineまたはDocker Desktop、Compose v2 公式mainのCLIガイドは変更が進んでいます。0.2.1では zg index・zg query を使用します。 mainにある zg --index などの構文を混ぜないでください。この記事の構文はv0.2.1のCLIガイドと、インストールしたパッケージのヘルプで確認しています。 Linux・Windows（Docker DesktopのLinuxコンテナ）などから実行できますが、記事のシェル例はBashを前提にします。ARM64ホストではamd64エミュレーションが必要になり、速度・互換性は別途確認してください。zvec本体が対応するプラットフォームと、CLIの依存パッケージが動く条件は同一ではありません。 小さな検証用として、Dockerへ2 vCPU・4 GiB程度のRAMと数GBの空きディスクを割り当てるところから始めます。これは公式の最低要件や実測による必要量ではありません。npm依存・モデル・イメージ・インデックスが容量を使い、対象文書が増えると追加のメモリと保存領域が必要です。GPUと外部LLM APIキーは使いません。 英語文書向けの軽量モデルを選ぶため、サンプルも英語です。日本語の検索品質をこの結果から判断しないでください。 手順 1. 作業ディレクトリを用意する zg-compose-demo を作り、その下に次のファイルを保存します。ファイル内容は後述の「コード例」にあります。 ファイル 用途 package.json zgとzvecのバージョン指定 Dockerfile CLIの実行イメージ compose.yaml 実行位置と永続化先 docs/password.md パスワード再設定の文書 docs/backup.md DBバックアップの文書 docs/cache.md 画像キャッシュの文書 mkdir -p zg-compose-demo/docs cd zg-compose-demo 構成はComposeサービス1個です。検索用コンテナの中でzvecも動きます。DBサーバーのサービスや公開ポートは追加しません。 2. ビルドとバージョン確認 ファイルを保存してから、以下を実行します。 docker compose config docker compose build docker compose run --rm zg --version docker compose run --rm zg index --help CLIのバージョンが 0.2.1 であることを確認します。config はCompose設定の確認であり、イメージのビルド成功や検索成功までは保証しません。 3. インデックスを作る docker compose run --rm zg index \ --embedding local/potion-retrieval-32m \ --mode direct \ --embedding-concurrency 1 docker compose run --rm zg status --mode direct コンテナの作業場所は /workspace で、ホストの docs/ をマウントします。その配下に .zvec-grep/ が作られます。 モデルは初回利用時にダウンロードされます。モデルキャッシュは ZVEC_GREP_MODEL_CACHE=/models に変更し、名前付きボリュームに保存します。今回の0.2.1のModel2Vec実装はHugging Faceからモデルを取得します。初回から完全オフラインでは動きません。ビルド時もコンテナレジストリとnpmへの接続が必要です。 4. 4種類の検索を比較する 既知の文字列を直接探します。この処理だけならモデルもインデックスも不要です。 docker compose run --rm zg query --rg -n password . 次は、作成したインデックスを使う検索です。 キーワード検索 docker compose run --rm zg query --fts password \ --mode direct --human --limit 3 ベクトル検索 docker compose run --rm zg query \ --vector "recover access to an account" \ --mode direct --human --limit 3 ハイブリッド検索 docker compose run --rm zg query \ "recover access to an account" \ --mode direct --human --limit 3 キーワードを明示して融合する場合は、次のようにも書けます。 docker compose run --rm zg query \ --hybrid "recover access to an account" \ --fts password --fuse \ --mode direct --human --limit 3 ネイティブ実行では3ファイルの登録に成功し、status は3件・512次元・cosineを表示しました。--fts password は password.md を返し、上記のベクトル検索とハイブリッド検索も同ファイルを1位に返しました。これはサンプル3件での確認であり、検索精度や性能のベンチマークではありません。 5. 文書の変更・再作成を確認する 文書を編集・追加した後は再インデックスします。direct の検索は既定では更新待ちをしないため、明示的な更新を基本にします。 docker compose run --rm zg index --mode direct \ --embedding-concurrency 1 変更なしで再実行したネイティブ検証では、3件が unchanged、失敗0件となりました。既存インデックスは保存したモデル設定を引き継ぎます。 モデルを変えるときは、ベクトル空間が変わるため再構築します。日本語などを扱う検証の出発点として、多言語モデルへ切り替える例です。 docker compose run --rm zg index --rebuild \ --embedding local/potion-multilingual-128m \ --mode direct --embedding-concurrency 1 この多言語モデルへの切り替えは未実行です。別モデルの取得容量、時間、品質を確認してください。 6. 終了・削除する run --rm は処理が終わると実行コンテナを削除します。インデックスはホストの docs/.zvec-grep/、モデルは名前付きボリュームに残るため、次の実行で再利用できます。 Composeが管理するコンテナやネットワークを片付ける docker compose down インデックスを削除する。原本のMarkdownは残る docker compose run --rm zg index --drop --yes --mode direct モデルキャッシュの名前付きボリュームも削除する docker compose down --volumes down --volumes だけでは、バインドマウント先の docs/.zvec-grep/ は削除されません。キャッシュ削除後は次回のモデル取得が必要です。ビルドしたイメージもこのコマンドでは削除しません。 コード例 package.json { "name": "zg-compose-demo", "version": "1.0.0", "private": true, "dependencies": { "@zvec/zvec-grep": "0.2.1" }, "overrides": { "@zvec/zvec": "0.7.1" } } zvec-grepが内部で使うzvecもoverrideで固定します。ただし、これだけでは間接依存の全バージョンは固定されません。継続利用するプロジェクトでは package-lock.json を生成・保存し、Dockerfileも npm ci を使う構成に変更します。 Dockerfile FROM node:24-bookworm-slim WORKDIR /opt/zg COPY package.json ./ RUN npm install --omit=dev \ && npm cache clean --force ENV PATH="/opt/zg/node_modules/.bin:${PATH}" WORKDIR /workspace ENTRYPOINT ["zg"] Debian系を使い、glibc向けネイティブバインディングを利用する構成です。--omit=optional は付けません。zvecやripgrepのプラットフォーム別バイナリもoptionalDependenciesとして配布されているためです。依存パッケージのインストールスクリプトが実行される点も含め、ビルドログを確認してください。 compose.yaml name: zg-compose-demo services: zg: platform: linux/amd64 build: context: . working_dir: /workspace environment: ZVEC_GREP_MODE: direct ZVEC_GREP_MODEL_CACHE: /models volumes: - ./docs:/workspace - model-cache:/models command: ["--help"] volumes: model-cache: /workspace は検索対象だけに絞ります。Dockerfileやnpm依存まで検索する必要はありません。モデルキャッシュを別のマウント先に置くことで、そのファイル群も検索対象から外します。 docs/password.md Password reset Send a time-limited reset link by email when a user forgets a password. docs/backup.md Database backup Create a daily database backup and test restoration regularly. docs/cache.md Image cache Cache resized images to reduce page loading time. 注意点 ローカルモデルと通信・保存を区別する 今回のモデルを使う埋め込み計算はローカルです。一方、初回のモデル取得は外部通信を伴います。原文・検索語の外部埋め込みAPIへの送信は、この構成では設定していません。 モデルキャッシュとインデックスは別のデータです。特にインデックスには検索用の情報が残るため、元文書と同じように扱ってください。モデルをキャッシュしても、完全オフラインでの初回起動や更新を検証したことにはなりません。 書き込みとファイル所有者に注意する この例はイメージの既定ユーザーで動くため、Linuxホストでは docs/.zvec-grep/ がroot所有になる場合があります。共有環境へ持ち込む際はUID／GIDと書き込み権限を調整します。 同じインデックスへ複数の index を同時実行しないでください。zvecの公式READMEでは、読み取りの並行実行と、単一プロセスによる排他的な書き込みが区別されています。 常駐サーバーが必要になる場面 今回は単発CLIを選びました。direct はコマンドごとにプロセスを終了するため、モデルの読み込みも繰り返します。頻繁に検索する場合やエージェントからMCPで利用する場合は、モデルを再利用できるServer構成を検討します。 zvec-grepのServerはローカルループバックでの利用を前提とします。今回のComposeへポート公開だけを足してリモート検索APIにする設計は扱いません。 実行済みと未確認を整理する 対象 確認状況 配布版0.2.1のヘルプとコマンド構文 ネイティブ実行で確認 3文書の登録・状態確認・4種類の検索 ネイティブ実行で確認 複数クエリの融合・変更なしの再インデックス ネイティブ実行で確認 Docker build・Compose起動・マウント先の永続化 未実行 インデックス削除・キャッシュ削除 手順掲載のみ、未実行 多言語モデル・日本語の検索品質 未実行 大量データの性能・最低必要スペック 未検証 ネイティブ検証では、インストールスクリプトを抑止して依存を配置した後、zvecのバイナリ準備処理を実行しています。Dockerfileの通常の npm install と同一のビルド経路を検証したものではありません。コンテナ側の依存解決・ネイティブバイナリ・保存先を確認する際は、「ビルドとバージョン確認」から順に進めてください。 参考資料 zvec v0.7.0 README：サンプルに近いリリース世代の組み込み型DBとしての構成と検索機能。 Qdrant Local Quickstart：サーバー構成の起動・接続方法。 Qdrant Python client Local mode：サーバー不要のローカル実行。 Milvus Docker Compose：Standaloneの公式Compose例。 Milvus Lite：Pythonへの組み込みと他のMilvus構成とのAPI共有。 Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks：検索と生成を組み合わせるRAGの原論文。 alibaba/zvec：プロセス内DB、検索機能、対応プラットフォーム、並行アクセスの説明。 zvec-ai/zvec-grep：検索CLIの概要とzvecとの関係。 zvec-grep v0.2.1 CLI guide：本文で使用したコマンドとオプション。 zvec-grep v0.2.1 Embedding models：モデル選択、キャッシュ、モデル変更の方針。 zvec-grep Architecture：インデックス検索とripgrepの経路、BM25・ベクトル・RRFの関係。 zvec-grep Server and execution modes：Direct／Serverの考え方。mainのCLI構文は配布版0.2.1と異なるため、実行時は配布版のヘルプも確認する。 資料と配布パッケージは2026年10月21日（日本時間）に確認しました。