Nalyエンジニアリングノート：永続化されたソースによる検索拡張型の記事執筆

要約

検索拡張生成は、Nalyの記事パイプラインに、モデルの重みだけより新しく、監査しやすい調査記憶を与える。各エンジニアリングノートや市場インテリジェンス記事のジョブごとに、システムはWebとarXivを検索し、生成された成果物とともにソースURLを保持し、モデルにまず回答させ、その結果をHTMLとしてレンダリングできる。目的は自動化そのものではない。読者が追跡できる主張を公開することだ。

論点は単純だ。記事執筆のためのRAGは、チャットボットのパターンではなく、本番の証拠システムとして扱うべきである。チャットボットの弱い回答は許されることもあるが、公開記事は長く残る信頼の接点になる。したがってNalyの実装には、下書き前の検索、公開後も残るソース記録、読みやすいMarkdownを保ちながら安全でないHTMLを避けるレンダラーという3つの不変条件が必要になる。

Naly内での位置づけ

Nalyの記事ジョブは、調査の取得と公開の間に位置する。ジョブは選定されたトピックから始まり、検索意図を生成し、WebとarXivの資料を取得し、結果をソース記録に正規化し、その限定された証拠セットから回答先行の記事を書くようモデルに依頼する。出力は単なる文章ではない。Markdownコンテンツ、レンダリング済みHTML、ソースURL、ソースタイトル、ソース種別、そして各ソースが使われた理由を説明するのに十分なメタデータを含む束である。

これはNalyの信頼ループにとって重要だ。Nalyのより広い編集姿勢は、他者が隠すもの、つまり意思決定メモ、キャリブレーションの限界、失敗、主張の背後にある証拠を公開することにある。ソースに裏付けられた生成は、その姿勢を運用可能にする。読者は、ある記述がモデルの学習データ、公式文書、論文、あるいはオペレーターの主張のどこから来たのかを推測する必要があってはならない。

RAGレイヤーは下書きの後ではなく、前に置くべきである。事後的に引用を付ける方法は、モデルがすでに主張を形成しているため弱い。より強い設計では、検索が生成コンテキストを制約し、生成は検索済みセットに照らして確認できる主張を生む。読者に見える記事は簡潔でよいが、保存される成果物には調査の履歴を残すべきだ。

技術的な仕組み

記事執筆におけるNalyのRAGフローはバッチパイプラインである。

トピック選定は、検索拡張生成がソースに裏付けられた記事執筆をどのように根拠づけるか、といった限定された調査質問を作る。
クエリ計画は、その質問をWebクエリ、公式文書クエリ、arXivクエリへ展開する。
検索は、公式ドキュメント、一次論文、シグナルの強い解説ソースを収集する。
正規化は、タイトル、正規URL、ソース種別、入手可能な場合の公開または更新コンテキスト、関連スニペットや要約を抽出する。
ソース永続化は、後で記事を監査できるよう、生成前にURL台帳を保存する。
プロンプト組み立ては、トピック、Naly固有の実装事実、執筆制約、検索された証拠をモデルに渡す。
生成は、回答先行の要約、明示的な失敗モード、参考文献セクションを含むMarkdownを生成する。
検証は、レンダリングされた記事内のすべての参考文献が保存済みソースオブジェクトに対応していることを確認する。
レンダリングは、サニタイズと本番チェックを適用しながら、サイト用にMarkdownをHTMLへ変換する。

これはVercelのRAGガイドで説明されている検索と拡張生成のパターンに近い。まず関連コンテキストを検索し、その後、生成前にそれをユーザーまたはジョブの質問と組み合わせる。違いは、Nalyが会話型サポートに最適化していないことだ。Nalyは、ソースURLが記事のデータモデルの一部となる、永続的な公開に最適化している。

AI SDKは、この種のジョブに自然なオーケストレーションレイヤーである。テキスト生成インターフェースが、非対話型の自動化、ツール呼び出し、複数ステップの結果、そしてプロバイダーがURLソースを返す場合のソースメタデータをサポートするためだ。プロバイダーがネイティブのソースオブジェクトを返さない場合でも、Nalyは独自の検索済みソースリストを記事成果物に付与し、モデルネイティブのソースは権威あるものではなく補助的なものとして扱える。

文献が示すこと

Lewis et al.による最初のRAG定式化は、核心的な問題をよく捉えていた。パラメトリック言語モデルは事実を重みに保存するが、その知識を更新し、出所を示すことは依然として難しい。彼らの検索拡張モデルは系列モデルと密なベクトルインデックスを組み合わせ、知識集約型タスクにおいて、パラメータのみのベースラインより具体的で多様かつ事実性の高い生成を示した。

その後のGao et al.によるRAGサーベイは、この考え方をnaive RAG、advanced RAG、modular RAGという分類に一般化している。Nalyの記事パイプラインはモジュール型であるべきだ。検索、ランキング、ソース永続化、プロンプト構築、生成、参考文献検証、レンダリングは、それぞれ別個の失敗モードを持つ別個の単位である。これらを分けて扱うことで、記事が弱いソースを引用したり、より良いソースを見落としたりしたときに、システムをデバッグしやすくなる。

Self-RAGは重要な注意点を加えている。Asai et al.は、検索が必要かどうかにかかわらず固定数のパッセージを検索すると、出力品質が低下し得ると論じている。Nalyにとって、それはtop-k検索を儀式にしてはならないという意味だ。安定したフレームワーク機能に関する短い記事なら、公式ドキュメントと1本の論文で足りるかもしれない。文献色の強い記事なら、複数のarXivソースとサーベイが必要になるかもしれない。検索の深さは主張のリスクに従うべきである。

RAGCheckerは評価上の教訓を与える。Ru et al.は、RAGシステムには、特に長文回答において、検索と生成の両方にまたがる細粒度の診断が必要だと論じている。Nalyにとって評価単位は記事品質だけであってはならない。検索リコール、ソースの関連性、主張の裏付け、参考文献のカバレッジ、そして裏付けのない主張が最終Markdownに紛れ込んだかどうかを含めるべきだ。

設計上のトレードオフ

高いリコールと低いノイズの両立が中心的なトレードオフである。検索を増やすと正しいソースを見つける可能性は高まるが、弱いスニペットがプロンプトに入り、モデルを誘導する可能性も高まる。Nalyは、広く収集し、厳格にフィルタリングし、その後コンパクトなプロンプトコンテキストにする段階的なアプローチを好むべきだ。

ソースの永続化は監査可能性を高めるが、保存と保守の作業も生む。URLは変わり、論文は改訂され、ドキュメントページは移動する。永続的な記録には、正規URL、取得タイムスタンプ、タイトル、ソース種別、理想的にはコンテンツダイジェストまたは抜粋範囲を含めるべきだ。これによりNalyは、モデルの誤りとソースの変更を区別できる。

回答先行の文章は読者価値を高めるが、不確実性を過度に圧縮してしまうことがある。記事は結論から始めつつ、後続セクションで失敗モードと注意点を残すべきだ。回答先行の要約は入口であり、証拠を平板化する免許ではない。

レンダリング済みHTMLは配信と読書体験を改善するが、セキュリティ境界も作る。MarkedはMarkdown解析に高速で有用だが、そのドキュメントは出力HTMLをサニタイズしないと明示的に警告している。Nalyの記事レンダラーは生成HTMLをサニタイズし、再生用に信頼されたMarkdownソースを利用可能な状態に保つべきである。

失敗モード

検索ミス：検索ステップがもっともらしいが不完全なソースを見つける。これは通常、クエリプランナーが狭すぎる場合や、文献で使われる用語と異なるプロダクト用語を使う場合に起きる。緩和策：複数のクエリスタイルを使い、公式ドキュメントを含め、記事が研究上の主張を行う場合は少なくとも2つの一次ソースまたはarXivソースを要求する。

引用ロンダリング：ソースは参考文献に現れるが、その近くの文を実際には裏付けていない。これは誤った自信を生むため、引用がない場合より悪い。緩和策：主張をソーススニペットに照らして検証し、参考文献が単にトピック的なだけの記事は却下する。

古いソースのドリフト：公式ドキュメントページが公開後に変更される。緩和策：生成時点のソースメタデータを永続化し、日付ラベルを記録する。主要な主張を支えるソースについては、ライセンスが許す範囲でスナップショットまたはダイジェストを保存する。

過剰検索：チャンクが多すぎると、モデルは記事の論旨に答えるのではなく、コンテキストを要約してしまう。緩和策：ソースランキングを使い、ほぼ同一の文書を重複排除し、生の件数ではなく主張との関連性によってプロンプト証拠に上限を設ける。

コンテキスト汚染：スパムページ、生成されたSEOページ、低品質な要約が一次資料より上位に来る。緩和策：記事が業界の受け止め方を明示的に扱う場合を除き、公式ドキュメント、arXiv、標準、ソースリポジトリを二次的な論評より高くランク付けする。

レンダラーリスク：生成されたMarkdownには、生HTML、安全でないリンク、不正な形式の表が含まれることがある。緩和策：レンダリングされたHTMLをサニタイズし、リンクを正規化し、スクリプト実行可能なコンテンツを拒否し、パフォーマンス、セキュリティ、メタデータ、アクセシビリティに関するNext.jsのガイダンスと整合する本番チェックを実行する。

実装メモ

Nalyの現在のランタイム上の前提を踏まえると、明快なアーキテクチャは、モデルオーケストレーションに ai@6.0.0-beta.105 を使い、証拠収集にWebおよびarXiv検索ツールを、記事とソース記録にNeon上のDrizzle ORMを、 marked@17.0.1 をMarkdownからHTMLへのレンダリングに使い、公開面にNext.js 16を使うTypeScriptジョブである。

データベースは、ソースをMarkdownテキストの塊ではなく、第一級の行として扱うべきだ。実用的なスキーマには、記事テーブル、記事とソースの結合テーブル、そしてURL、タイトル、ソース種別、取得タイムスタンプ、利用可能な場合のarXiv IDのような正規識別子、抽出ステータスのためのソースフィールドがある。記事レコードはその後、Markdown、レンダリング済みHTML、要約、キーポイント、公開メタデータを指すことができる。

Vercel Blobはより大きな成果物や不変のレンダリング出力に有用であり、一方でPostgresはソースと記事メタデータのクエリ可能な台帳としてより適している。この分離により監査クエリは軽く保てる。あるソースを使ったすべての記事、ある記事で使われたすべてのソース、ソース抽出に失敗したすべての記事を一覧できる。

生成器のプロンプトは、出力の形にソース規律を要求すべきだ。裏付けのない主張をしない、URLを捏造しない、リンクが永続化されたソースリストと一致しなければならない参考文献セクションを含める。モデルは流れるような文章を書けるが、ジョブがソースの真実を所有すべきである。モデルが検索されていない参考文献を出力した場合、バリデーターは静かに公開するのではなく、その記事を失敗させるべきだ。

最後に、本番での振る舞いが重要である。Next.jsはすでにサーバーコンポーネント、コード分割、プリレンダリング、キャッシュのデフォルトを提供しているが、生成コンテンツのパイプラインには、それでも明示的なエラーハンドリング、セキュリティチェック、メタデータ、Core Web Vitalsへの意識が必要だ。RAGはNalyが証拠に基づいて書くことを助ける。本番エンジニアリングは、その証拠が読者に素早く、安全に、繰り返し届くようにする。

要約